Scaling is the name of the game in business, and automation is key to doing it effectively.
Banks and traditional financial institutions know this, and have long used automation to sharpen their competitive edge, maximize operational efficiency, and minimize the amount of manual intervention needed for day-to-day operations.
Digital assets, however, remain largely stuck in manual mode. Most transactions are still made with the point and click of a mouse or the tap of a finger, and scaling beyond a handful of transactions per minute is often impossible.
Qredo Computational Custody combines decentralized multi-party computation (dMPC) with automation to lift the ceiling on the scalability of digital asset operations — enabling your organization to support millions of transactions each day.
It's like having a trustless custody engine that automatically signs transactions on your behalf based on predetermined criteria.
But how does this engine work?
Computational Custody is underpinned by Qredo's powerful policy engine.
This policy engine enables you to build bespoke governance by selecting from the building blocks of different role types — including trader, administrator, and approver — which each have their own activity and access rights. In this way, you can create secure transaction workflows that reflect the specific structure of your team.
When a transaction is initiated, each assigned Approver in that governance policy must sign the transaction before it can be sent. This initiation and approval is accomplished via the Qredo Signing App.
To approve transactions, the Signing App authenticates the user biometrically via the touch of a fingerprint, and then authorizes the transaction with a digital signature.
In a nutshell, Computational Custody replaces the Qredo Signing App with a secure server (the Signing Agent).
Using Qredo's open source library, you can then configure the Signing Agent to govern the routing of transactions according to certain criteria — such as size, destination address, or originator.
This Signing Agent, which hosts your BLS keys to sign transactions, can be either hosted within your own infrastructure or initialized within managed services.
Qredo uses BLS (Boneh-Lynn-Shacham) signatures to implement a threshold signature scheme that immutably records governance policies on the Qredochain.
When a transaction is initiated, each approval creates a BLS (Boneh-Lynn-Shacham) digital signature. On receiving the necessary threshold of BLS signatures, Qredo completes the transaction.
Aside from relieving the signing fatigue created by manually approving dozens of transactions each day, programmatic digital asset management opens up multiple opportunities to strengthen governance policies and streamline operations:
Organizations can use Computational Custody to set whitelisting rules that automatically approve transactions if they meet certain criteria — for example, if the destination address matches that of a known counterparty.
Alternatively, a DeFi fund might use whitelisting to interact with dApps securely by granting automatic access to certain smart contracts within a dApp, while blocking other potentially malicious contracts.
In the fast-paced digital assets market, milliseconds can make the difference between successfully seizing an opportunity, and being left on the sidelines.
Pre-approving transactions can play a key role in minimizing delays. For example, a fund manager might give traders the ability to transact at will within certain limits. Any transactions that don't exceed these limits — which could be based on anything from individual transaction size to total volume traded within a specific period — are approved automatically.
Thus, when a market opportunity arises, the trader can quickly jump on it without being forced to wait for approvals.
By programming rules using the fundamental boolean operators ( and, or, and not) Computational Custody enables transactions to be routed between different teams and governance structures.
For example, your fund might construct a governance policy in which all transaction approvals below a certain amount are routed to policy group A, the operational team. Or, if the transaction is above a certain amount, it would automatically be routed for approval to group B, for the approval of the trading team.
Alternatively, the designated approvers might depend on who initiated the transaction; with transactions from junior traders having more oversight, and senior traders being automatically approved.
In another scenario, particularly large orders might be routed to more than one group — requiring approval from the operations team, for example, before final approval from the trading team. Each individual policy group would be constructed in the same way as normal, requiring a quorum of a certain number “Approvers” to approve transactions, but with additional tiers of governance added as transaction size increases.