Sammendrag
In distributed financial systems, custody architecture defines the boundary of asset authority. While ledger systems preserve transactional invariants and ensure conservation of value, custody systems determine which entities are cryptographically capable of producing valid asset transfers. A failure in ledger logic may result in reconciliation complexity; a failure in custody design results in irreversible loss.
This article presents a technical and architectural analysis of custody systems built on threshold cryptography and Multi-Party Computation (MPC), focusing on formal security properties, Byzantine adversary assumptions, distributed signing protocols, crash safety, correlated failure domains, and practical implementations using FROST-based threshold signatures.
Custody is not key storage. It is adversarial distributed systems engineering.
From Centralized Keys to Distributed Authority
Let be a private signing key used to authorize asset transfers in an elliptic curve system such as ECDSA or Ed25519.
In a centralized model:
Where:
- is the transaction message.
- is a valid signature.
Security reduces entirely to the secrecy of .
If an attacker extracts , control over assets is permanently lost. Because blockchain-based transfers are irreversible, there is no rollback mechanism capable of undoing a malicious signature.
Distributed systems engineering operates under a different assumption: compromise is eventual.
Therefore, custody must satisfy:
This transforms custody from secret storage into distributed trust enforcement. In this model, the centralized baseline in Eq. (1) is intentionally replaced by the distributed authority condition in Eq. (2).
Threshold Cryptography and Secret Fragmentation
Instead of storing private key scalar directly, we distribute it using Shamir Secret Sharing.
Construct polynomial of degree such that:
Each participant receives:
No individual share reveals .
A threshold -of- system ensures:
- Any subset of size can collaboratively produce a valid signature.
- Any subset of size less than cannot reconstruct nor produce .
Security condition:
Threshold selection encodes tradeoffs directly into system design.
Lower improves availability but weakens compromise resistance. Higher strengthens security but increases operational fragility.
This is risk modeling expressed mathematically.
Formal Adversary Model (Byzantine)
Assume a Byzantine adversary capable of:
- Arbitrary message manipulation.
- Adaptive node compromise.
- Network delay and reordering.
- Collusion among compromised nodes.
Let:
Security condition:
If , signing authority is compromised.
Additionally, the signing protocol must ensure:
- Robustness under up to malicious nodes.
- Unforgeability under partial compromise.
- Bias-resistance in nonce generation.
Custody becomes a Byzantine fault-tolerant distributed protocol layered over cryptographic primitives.
The Signing Protocol as a Distributed State Machine
Distributed signing is interactive.
Each participant generates ephemeral nonce shares and contributes to a coordinated signing round.
Conceptually:
- Nonce-forpliktelser utvekslet.
- Aggregert nonce beregnet.
- Partielle signaturer produsert.
- Signaturandeler aggregert.
Final signature:
The protocol must satisfy:
- Concurrency safety.
- Replay protection.
- Crash atomicity.
- Idempotency.
The signing protocol itself becomes a distributed state machine.
FROST: Efficient Threshold Schnorr Signatures
Modern custody systems frequently adopt Schnorr-based threshold schemes due to efficiency and simplicity.
FROST (Flexible Round-Optimized Schnorr Threshold Signatures) provides:
- Two-round signing protocol.
- Communication-efficient nonce commitment.
- Bias-resistant nonce generation.
- Provable security under discrete logarithm assumptions.
In Schnorr systems:
Verification condition:
Operational verification should remain traceable to Eq. (10) and Eq. (11) during runtime validation and incident review.
FROST produces signatures indistinguishable from centralized Schnorr signatures, ensuring blockchain compatibility.
Practical Example: frost-ed25519 (Rust)
Below is a simplified illustration using a FROST-compatible Rust library.
use frost_ed25519 as frost;
use rand::thread_rng;
fn threshold_sign(message: &[u8]) -> Result<frost::Signature, frost::Error> {
let mut rng = thread_rng();
let key_package = load_key_package();
let pubkey_package = load_public_package();
let (nonces, commitments) =
frost::round1::commit(key_package.signing_share(), &mut rng);
broadcast_commitments(commitments);
let signing_package =
frost::SigningPackage::new(commitments, message);
let signature_share =
frost::round2::sign(&signing_package, &nonces, &key_package)?;
collect_signature_share(signature_share);
let signature =
frost::aggregate(&signing_package, collected_signature_shares, &pubkey_package)?;
Ok(signature)
}
No full private key reconstruction occurs. Each node holds only its share. Final signature remains standard Ed25519-compatible.
Crash Safety and Atomic Signing
Consider node crash during signing round.
System must guarantee:
Intermediate nonce values must be ephemeral. Partial signatures must not be durable in reconstructible form. Retry must not reduce threshold requirement.
Custody must be crash-consistent by design.
Concurrency and Replay Safety
Custody must coordinate with ledger state.
Example validation:
fn validate_before_sign(tx: &Transaction, ledger: &Ledger) -> Result<(), Error> {
if ledger.nonce_used(tx.account, tx.nonce) {
return Err(Error::ReplayDetected);
}
if !ledger.balance_sufficient(tx.account, tx.amount) {
return Err(Error::InsufficientFunds);
}
Ok(())
}
Ledger preserves value invariants:
In practice, custody pipelines should validate this ledger invariant against Eq. (13) before issuing final signature broadcast.
Custody preserves authorization boundaries. Security is compositional.
Correlated Failure Domains
Threshold cryptography assumes independent shares. Operational correlation invalidates this assumption.
If shares reside in:
- Same cloud account.
- Same IAM boundary.
- Same CI/CD pipeline.
- Same secrets manager.
Compromise may become correlated.
Security principle:
Infrastructure separation, access isolation, and deployment segregation are mandatory.
Conceptual Signing Architecture
The custody signing flow can be visualized as:
+----------------------+
| Transaction Proposal |
+----------+-----------+
|
v
+----------------------+
| Ledger Validation |
+----------+-----------+
|
v
+----------------------+
| Risk Engine |
+----------+-----------+
|
v
+----------------------+
| Custody Coordinator |
+----+--------+--------+
| | |
v v v
+--------+ +--------+ +--------+
| Node 1 | | Node 2 | | Node 3 |
| Share | | Share | | Share |
+----+---+ +----+---+ +----+---+
\ | /
\ | /
\ | /
v v v
+----------------------+
| Signature Aggregation |
+----------+-----------+
|
v
+----------------------+
| Broadcast Transaction |
+----------------------+
Ledger validation precedes custody signing. Risk policy constrains signing eligibility. Custody nodes collaboratively produce final signature.
Konklusjon
Threshold cryptography transforms custody from centralized secret storage into distributed authority enforcement. FROST-based schemes provide efficient, bias-resistant threshold Schnorr signatures suitable for modern blockchain ecosystems. However, cryptographic guarantees alone are insufficient.
Custody must be analyzed under Byzantine adversary assumptions, implemented with crash-consistent protocols, and deployed across operationally independent failure domains. Ledger correctness preserves value invariants. Custody architecture preserves authority boundaries.
In distributed financial systems, control and correctness are inseparable. Without distributed custody, any system is ultimately controlled by whoever controls a single key.
Custody is where mathematics meets adversarial distributed systems engineering.