DOCSEARCHbyAlgolia
Submit Docs

Cordial Systems Treasury Documentation

website·Indexed 33 days ago

https://docs.cordialsystems.com

Documentation for Treasury, an MPC-based custody solution for blockchain assets. Includes guides on deployment, the Cordial Scripting Language (CSL), Treasury CLI, Oracle API, and native support for staking and Bitcoin Taproot.

Tokens
33.5K
Snippets
181
Records
289
Agent score
56%

What's inside Cordial Systems

  1. Overview of Cordial Treasury custody architecture

    Cordial Treasury is designed to safeguard digital assets by addressing two primary goals: protecting key access (ensuring keys cannot be copied or removed from secure environments) and protecting key use (ensuring keys only sign authorized requests). It achieves this by combining MPC (Multi-Party Computation) with integrated policy engines and BFT (Byzantine Fault Tolerant) consensus across nodes. Treasury is chain-agnostic, supporting over 30 chains and any chain compatible with ECDSA and Ed25519 signing protocols.

  2. Overview of Treasury Staking

    Treasury provides a uniform interface for delegated staking across supported chains, including Solana, Cosmos, and Ethereum. It uses native staking transactions to ensure clear signing, avoiding the security risks associated with blind signing. Staking typically involves moving assets into a locked state to accrue rewards, with state transitions often subject to bonding and unbonding periods (e.g., moving from activating to active or deactivating to inactive).

  3. Overview of Treasury MPC Custody Solution

    Treasury is an MPC-based (Multi-Party Computation) custody solution designed to eliminate single points of compromise. It can be fully self-hosted or co-hosted with secure operating partners. To ensure consistency across participants and prevent illegal transactions, it utilizes a BFT consensus implementation via cometbft.

  4. Get started with Cordial Treasury using the treasury CLI

    To interact with a Cordial Treasury deployment, use the treasury command line tool and the Cordial Scripting Language (CSL). The treasury script command provides an interactive interpreter for executing operations against a treasury instance.
    treasury script

  5. Understand Transfer Rule evaluation logic

    Every Transfer operation requires a matching transfer rule to be permitted. If no matching allow rule exists, the transfer is rejected by default. For a transfer to be successful, the following conditions must be met:

    1. At least one matching allow rule must exist.
    2. No matching deny rules must exist (deny rules always take precedence).
    3. All matching require rules must evaluate to true.

  6. Treasury production hardware requirements

    For each Treasury node in a production instance, the following hardware specifications are recommended:

    • CPU: 2x CPU (AMD64 or ARM64 architecture)
    • RAM: 8 GB
    • Disk: 50 GB SSD

  7. Get details for a specific transaction

    Retrieve detailed information about a specific transaction using its transaction hash, including amount, fees, sender, and recipient.
    curl --request GET \
  --url "$BASE_URL/v1/chains/ETH/transactions/0xa52c92804ec2bd2436cc048d663e2d916e0433f009e75df8b1084356177de713" \
  -u $API_ID:$API_SECRET

  8. Understand Cordial Systems Encryption at Rest (EAR)

    When Encryption at Rest (EAR) is configured, all data is encrypted using the AES-128-GCM-SIV authenticated cipher. This ensures that the integrity of the data is verified during decryption; if the decryption is incorrect or the data has been tampered with, the process will fail.

  9. Understand Cordial API resource naming conventions

    Every resource in the system is uniquely identified by a name that is immutable and URL-safe (no percent encoding required). A resource's current representation can be retrieved via an HTTP GET request using its name as the path. Names are composed of ID segments alternating between collection IDs and resource IDs. Basic IDs must be non-zero length and consist of alphanumeric characters, dashes, or underscores (matching the regex [A-Za-z0-9_-]+).

  10. Understand the Treasury transaction lifecycle

    Treasury uses an intent-based API where a resource (like a Transfer) is created first. The system then follows these steps to execute the transaction:

    1. Intent Creation: A resource (e.g., Transfer) is created to define the goal (e.g., "move Bitcoin from A to B").
    2. Policy Check: The request is validated against policies. It is either rejected or moved to an authorizing state if additional approvals are needed.
    3. Input Fetching: A "connecting" node fetches blockchain-specific inputs (fees, sequence numbers, UTXOs) via the Connector API or a custom RPC endpoint.
    4. Serialization: The transaction is serialized for the specific blockchain and a signature request is generated.
    5. Signing: The serialized transaction is signed by the signing service.
    6. Broadcasting: The signed transaction is broadcast to the blockchain via the connecting node.
    7. Confirmation: The transaction is polled on-chain and updated in Treasury until it reaches sufficient confirmations.

  11. Understand the Cordial universal transaction schema

    Cordial reports transactions in a universal format regardless of the underlying blockchain. The schema is hierarchical:

    1. Transaction: The top-level object.
    2. Movements: A transaction can contain multiple movements.
    3. Balance Changes: Each movement contains an array of balance changes, where each change specifies an asset and the address affected.

    Chain-specific modeling:

    • Account-based chains (e.g., Solana, EVM): Transfers are modeled as multiple movements, each containing two balance changes (one for the sender and one for the receiver).
    • UTXO-based chains (e.g., Sui, Bitcoin): Transfers are modeled as a single movement per asset, containing balance changes for all involved senders and receivers.

  12. Understand Cordial Treasury API architecture

    The Cordial Treasury API is a collaborative, permissioned, resource-oriented REST API. All client-visible state is modeled as resources. Key characteristics include:

    • Collaborative: Requests are signed by a user and may require additional signatures from other users for approval.
    • Permissioned: Access is controlled by a granular policy consisting of rules (which are themselves resources).
    • Resource-Oriented: State is managed via CRUD operations on uniquely named resources.