Enterprise custody architecture

Treasury has two goals for safeguarding digital assets.

1. Protecting key access. Keys must not be copied or removed from a secure environment.

2. Protecting key use. Keys must not be used to sign unauthorized requests.

Meeting these goals is critical to giving teams secure, complete custody of their assets.

Other custody scenarios

Consider the following common approaches to organizational custody without Cordial Treasury.

Assets on an exchange

A user or organization has no custody. The exchange fully controls the keys used to hold assets and how those keys are used.

Assets on a hardware wallet

It's easy to maintain custody of the keys, but difficult for teams to manage them because team members must share physical devices.

Policies are not easy to enforce—it's up to the individual using the hardware wallet to verify each transaction manually.

Assets on an MPC provider

MPC is a technology used to split private keys into separate key shares. MPC SaaS providers custody one or more key shares and give the organization custody of another share.

In this model, the organization has partial custody and, in theory, can prevent unauthorized use by its MPC SaaS partner by deactivating its client key share.

While this generally solves (1) key access and allows teams to share access effectively, it does not fully solve (2) key use. Any policies governing key use are fully controlled by the vendor or even by the vendor's authentication provider.

Assets on Cordial Treasury

Treasury provides MPC with integrated policies and gives organizations complete flexibility in how they deploy it. Organizations can self-host multiple Treasury nodes or co-host them with a trusted operating partner such as Cordial Systems.

Full hosting

Cordial Systems can host the entire solution for you and spin it up on demand. You can try it out right now; it takes only one minute. This model should be familiar to users of other providers, except Cordial is the only provider whose solution is fully TEE-based and distributes both MPC and policy evaluation. If you change your mind later, you can always switch to a co-hosted or self-hosted instance.

Co-hosting

Organizations that co-host with Cordial Systems use an operating model similar to that of SaaS providers but retain ownership and control of their policies. Treasury ensures strong BFT consensus among nodes. Any attempt by a single party to tamper with keys or policies will be rejected.

By taking custody of MPC shares and controlling the associated policies, an organization maintains strong control and custody of its own assets.

Every node validates each transaction and each request to modify the Treasury instance's policy. Even if Cordial Systems is compromised, it can compromise neither (1) key access nor (2) key use.

Fully on-prem

This is just one example of a Treasury deployment. Nothing prevents an organization from:

• Using multiple operating partners with a target threshold (e.g., 3-of-4 instead of 2-of-2).
• Self-hosting instances in-house without relying on a partner.
• Running a single node on a secure machine, similar to the use of HSMs in traditional financial networks.

Any custody operating model can be achieved with Treasury.

Treasury overview

Treasury is not specific to any chain or MPC protocol. It supports self-hosted models, allowing defense-in-depth or zero-trust configurations suitable for enterprises.

Authentication

All requests to Treasury must be signed with registered credentials associated with specific user identities.

Credentials are typically WebAuthn keys (hardware security keys, YubiKeys, Face ID, or TPMs). Signatures created with these secure credentials are validated by the policy engine integrated into every Treasury node.

If a user, jane@example.com, requests an allowlist rule permitting USDC from X to Y, they must sign the request with their WebAuthn credential. Treasury will evaluate several conditions before allowing the request.

• Is this signature valid?
• Is the user allowed to update a rule? Do they have the correct role?
• Does this request require a quorum or additional approvals? If so, put the request in a pending approval state.

The specific users, roles, and quorum rules are all configurable through a UI, CLI, or declarative configuration.

Approvals

Every operation in Treasury can be placed in an authorizing state if the policies affecting it require additional approval from another user or role. Treasury maintains a list of all authorizing operations and executes them once sufficient approvals have been granted and all conditions have been met.

This native handling allows pending operations to be viewed and managed through a simple UI or CLI. It also allows external policy systems to be connected through service accounts that submit their own approvals. These systems can drive automated checks (AML, compliance, etc.) or transfers.

Ongoing operations cannot be tampered with because they are protected by Treasury's threshold guarantees. All nodes reach BFT consensus on the state, operations, and policies.

Transaction signing

At the end of the day, Treasury is a secure way for teams to generate authorized transactions on public blockchains.

Treasury supports a variety of chains (over 30), and generally there is no technical hurdle to adding more.

Because Treasury cleanly separates signing from blockchain drivers and policy, we can readily add support for any chain compatible with ECDSA and Ed25519 signing protocols.

MPC protocols

Treasury uses FROST to create Ed25519 signatures. We use a construction of DKLs23 for ECDSA. Source code of Treasury (including all MPC) is provided to customers.

Transaction lifecycle

The following example illustrates in detail how a transaction comes to life in Treasury.

1. jane@example.com submits a request to transfer 1 ETH from x to y.

All Treasury nodes then perform the following validations:

2. Confirm that the signature is valid and jane@example.com is authorized.

3. Confirm that the transfer request is valid.

4. Confirm that the rules governing transfers permit the request. At the very least, there must be an allow rule permitting ETH from x to y.

5. Determine whether approvals are needed and, if so, whether enough approvals have already been granted.

If (2), (3), or (4) fails, the request will be rejected outright and no state change is possible. If (5) determines that approval is needed, the request is left in a pending state that other users must approve by signing with their WebAuthn credentials. Automated transfers may require approval from service accounts.

Once all steps are satisfied:

• Treasury will automatically fetch the inputs needed to create the transaction. These usually include the account nonce, gas fees, and other nonsensitive, transient information.
• Treasury will serialize a transaction (in this case an EVM transaction) for sending ETH from x to y. Treasury will request a signature from the MPC processes.
• Each MPC signer will check its co-located policy engine for signing requests and sign them.
• Treasury will broadcast signed transactions and update their status until they are confirmed.

Each Treasury node consists of two core functions:

• A policy engine that maintains Byzantine fault-tolerant consensus with other nodes.
• An MPC signer that signs only requests approved by the policy engine.