Enterprise custody architecture

Treasury follows two goals to ensure proper safeguarding of digital assets.

1. Protecting key access. Keys must not be copied or taken out of a secure premises.

2. Protecting key use. Keys are not be used to sign something unauthorized.

Ensuring these goals are met is critical to giving teams safe and full custody of their assets.

Other Custody Scenarios

Consider the following scenarios of how custody commonly for organizations (without Cordial Treasury).

Assets on an exchange

A user or organization has no custody. The exchange is in full control of the keys use to hold assets, and how those keys get used.

Assets on a hardware wallet

It's easy to have custody of the keys, but hard for teams of people to manage as they have to share physical devices.

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

Assets on a 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 one key share for the organization to custody.

In this model, the organization has some custody and in theory can prevent unauthorized use from their MPC SaaS partner by turning off their client key share.

While this generally solves (1) key access, and allows teams to share access effectively, it does not fully solve (2). Any policies on key use is fully in control by the vendor, or even the authentication provider used by the vendor.

Assets on Cordial Treasury

Treasury provides MPC with integrated policies and gives organizations the full flexibility to decide how they want to deploy out of the box. Organizations can self host multiple Treasury nodes, or co-host with a trusted operating partner.

Co-hosting

By co-hosting with an operating partner, they share a similar operating model to SaaS providers, but get to own and control the policies. Treasury ensures a strong BFT consensus between nodes. If there is any tampering with keys or policies from any single party, it will be rejected.

By allowing the organization to take custody of MPC shares combined with the policies, they maintain very strong control and custody of their own assets.

Any transaction or request to modify the policy of the Treasury instance is validated by every node. So even if the operating partner is compromised, they can neither compromise (1) key access, or (2) key use.

Fully on-prem

This is just one example of treasury deployment. There is no reason to prevent 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 any partner.
• Using a single node in a secure machine, similar to HSM's in traditional finance networks.

Any custody operating model can be achieved with treasury.

Treasury overview

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

Authentication

All requests to treasury must be signed by registered credentials which are associated to specific user identities.

Credentials are typically WebAuthn keys (hardware security keys, Yubikeys, FaceID, TPMs). Signatures made with these secure credentials are validated by the policy engine integrated to every treasury node.

If a user, jane@example.com, makes a request to allowlist sending USDC from X to Y, they will have to sign it with their webauthn credential. Treasury will make a number of assertions 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 need any quorom, or additional approvals? If so, put request in approving state.

The specific users, roles, quorum rules are all configurable -- either via an UI interface, CLI, or declarative configuration.

Approvals

Every operation in treasury can be placed into an authorizing state. This depends on the policies affecting the operation requiring additional approvers from another user or role. Treasury maintains the list of all of the authorizing operations and will execute them once sufficient approvals & conditions have been met.

This native handling of operations allows pending operations to be viewed & managed on a simple UI or CLI interface. It also allows external policies to be connected by configuring them to be service accounts that submit their own approvals. External policies can drive automated checks or transfers (AML check, compliance, etc).

The on-going operations cannot be tampered with as it's protected by the threshold gauruntee of Treasury. All nodes come to BFT consenus 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's no technical hurdle to adding more.

Due to how treasury cleanly separate signing from blockchain drivers + 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.

For ECDSA, Treasury currently uses a SPDZ construction with Beaver Triples. Beaver triples greatly simplifies the protocol, and requires no complex operations like zero knowledge proofs. However, it requires treasury to have semi-trusted initial setup.

In the near future we plan to support dkls23, the state of the art MPC protocol for ECDSA signatures.

Transaction lifecycle

This will illustrate in detail how a transaction comes to life on treasury.

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

Now treasury nodes will all validate that:

2. Signature is valid and jane@example.com is authorized.

3. The transfer request is valid.

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

5. If approvals are needed, or if there enough approvals already.

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

Once all steps are satisfied then:

• Treasury will automatically fetch the necessary inputs needed to create the transaction. Usually this is the account nonce, gas fees, and other non-sensitive 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 it's co-located policy engine for any signing requests, and sign them.
• Treasury will broadcast signed transactions and update them until they are in a confirmed state.

Each Treasury node essentially is a composition of two core functions:

• A policy engine that maintains a byzantine fault tolerance with other nodes.
• A MPC signer that only signs requests deemed approved by the policy engine.