Within the Wallet structure, there is the ability to set specific standard and custom rules. These rules can be used to set policies on when to sign transactions. Read on for details on how this works.

For each organisation using TrustVault, there are up to 2 Wallets by default (this number can be upgraded based on organisational need). Inside the Wallet, you can have as many Sub-Wallets as you want, depending on your organisation’s tier in our pricing plan. The Sub-Wallet is chain-specific, so each Sub-Wallet created is for a specific blockchain, such as Bitcoin or Ethereum, which you can select in the dropdown menu when creating the Sub-Wallet in TrustVaultWeb.

An example use case as shown in the figure above, could be that Wallet 1 is utilised for client accounts and each respective sub-wallet within that wallet is a client’s assets. Wallet 2 could be the organisation's Treasury wallet. As TrustVault only ever uses segregated accounts, this is an ideal set-up for ensuring the segregation of funds and better organisation for businesses.

For more details on Wallet structures, read this help article.

The Policy associated with a TrustVault Wallet determines who needs to sign a transaction. This Policy can be a complex structure of AND and OR combinations of quorum groups, where each quorum group specifies a minimum number of signers from a group of keys. For example you could have a policy that specifies:

(2 of 5 ops users AND 1 of 3 admin users) OR (2 of 3 admin users)

In this scenario the "ops users" and "admin users" are just arbitrary groups and your organisational structure may be simpler or possibly even more complex. Our Policy language enables us to match your organisational structure.

The keys referred to above generally correspond to the key held in a user's iPhone Secure Enclave (often called the device publicKey) and our automatically accessed via the TrustVault app.

However, in some scenarios, for added flexibility and control, the key may be managed by a computer system. We call this API based signing (or external signing). Bitpanda Custody uses this functionality to provide our co-signing service to extend the Policy language to include features like Threshold and Allow List functionality. A policy that incorporates these features might be written as:

(2 of 3 users) OR (1 of 3 users AND threshold < $10000 AND recipient in allow list)

The ability to set complex policies is available on our TrustVault Tiered plans from Tier 3 and above.

Briefly, the co-signing service is a Bitpanda Custody operated service that is given permission within a wallet Policy to sign a transactions. The beauty of the co-signing service is that it can sign (or not sign) based on rules allowing the flexibility of Policies to be expanded further.

The ability to add a set of rules via the co-signing service gives TrustVault institutional users flexibility and control over their spending rules. This additional security allows you to control things like:

We continue to expand the set of policy rules that are available "out of the box" (you can view them here), but for bespoke situations where our rules do not suit your use case you can utilise the API based signing functionality and our example co-signing-service code to implement your own custom rules or talk to us about implementing them for you.

Learn more about our API integrations here.