Skip to main content

Product Specification

Treasury is an MPC-based custody solution that can be fully self-hosted, or co-hosted with secure operating partner(s).

MPC​

MPC is used to guarantee no single point of compromise in the system.

Keys are generated or signed with using disjoint key shares. This is done for multiple signing protocols to be able to support a wide range of blockchains.

  • ECDSA: Treasury uses a generic SPDZ construction with Beaver Triples optimization. In the near future, dkls23 will be used.
  • EdDSA: Treasury use FROST.
  • Schnorr: Treasury use FROST.

MPC is also used to ensure that policies pass with the same result on all participants of the instance. A BFT consensus implementation is used, cometbft, the same used by many public blockchains today.

MPC policy ensures no 'illegal' transaction gets signed due to a single compromise.

Thresholding​

Treasury can be deployed with a target threshold. A participant runs a treasury node but cannot by themselves compromise a key or take an action leading to an 'illegal' signing.

  • (2, 2)
  • (3, 4)
  • Custom (t, n)

A (2, 2) deployment ensures no single point of failure but both participants must be up. A (3, 4) deployment furthermore would allow 1 participant to be down. Other combinations are also possible.

Blockchains​

Treasury supports a wide range of blockchains and more are being added regularly. Contact us to get an updated list or to see how soon we can add support for your chain.

Architectures​

  • Aptos
  • Bitcoin
  • Cosmos
  • EVM
  • Solana
  • Substrate
  • Sui
  • Tron

Chains​

  • Acala
  • Aptos
  • Arbitrum
  • ATOM
  • Aurora
  • Avalanche
  • Bitcoin Cash
  • Binance Smart Chain
  • Bitcoin
  • Celo
  • Chiliz + Chiliz 2.0
  • Dogecoin
  • Polkadot
  • Ethereum
  • Ethereum Classic
  • Ethereum PoW
  • Fantom
  • Provenance
  • Injective
  • Terra, Terra Classic
  • Karura
  • Klaytn
  • Polygon
  • Oasys
  • Optimism
  • Emerald Oasis
  • Solana
  • Sui
  • XPLA
  • Celestia
  • Sei

Tokens​

Tokens are supported on all relevant chains. Tokens can be added directly by the user by importing the contract address and decimals.

Custom symbols may be added to tokens to make referencing them easier. All assets can be referenced by their chain and contract address, or they can be referenced by a symbol that the user creates.

For example, USDC on Solana can be referenced by the name chains/SOL/assets/EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v. You could create a symbol 'myUSDC' and reference it also by chains/SOL/symbols/myUSDC.

Policy​

Users have full control over their policies. Policies can be set in the UI, via CLI, or controlled declaratively using Cordial Script Language (CSL) files.

An operation in treasury can be governed by policy. Operations can also be in an authorizing state, where Treasury defers executing them until certain conditions are met later, like additional approvers signing off on the operation, or AML checks passing.

Access Rules​

Access rules govern who is allowed to use which endpoints. Access rules may also govern how many approvers need to sign off on a request before it actually executes.

Access rules can reference specific users, or can reference roles or allowed credentials to be used.

For example, the "Create Address" endpoint may be sensitive and you can limit who is allowed to use it, or require a certain number of approvals to sign off on the operation.

Every operation in Treasury is default-deny, and requires some access-rule to permit it.

Transfer Rules​

Transfer rules have additional fields to pertain to the source, destination, and asset of transfers.

Any transfer in Treasury is default-deny, and requires some transfer-rule to permit it.

Transfer rules may have notional limits attached.

External Policies​

Policies in Treasury can be exported and signed to be used by other external applications.

Custom Policies​

For policies that can't be expressed natively in Treasury, there is a way to integrate your own custom policies to treasury. All policy rules can be configured to require external signer(s) in order to pass. You can then run your program using service credentials that can run your policy check and sign off on pending operations.

Custom Signing and DeFi​

Treasury supports "raw" signing operations which can be used to sign custom transactions or other certificates. Policies can be bound to these operations or to specific keys.

Deployment requirements​

Each Treasury node requires 2-4 CPU and 4-8GB of RAM. Docker is required to run Treasury.

Treasury nodes are securely updated using a supervisor process that ensures that the update was approved by the user and signed by Cordial Systems.

Data reporting and RPC​

For all supported chains, Cordial Systems provides a universal RPC API, the Connector API. This is used to power transactions made in Treasury. Users may opt of using our API and instead configure their Treasury instances to use user-provided RPC nodes.

For indexed data, like balances and transaction history, Cordial Systems also provides APIs. These are used to see enriched information about addresses managed in Treasury. Some chains do not have full support for reading balances and transaction history. To see full support, check the /v1/chains endpoint on the Oracle API.