Architecture & MPC
Multi-Party Computation (MPC)
MPC allows multiple parties to jointly produce a digital signature without any single party ever having access to the complete private key. The key is split into shares distributed across separate cosigners. Compromising one cosigner is not enough to steal funds — an attacker must breach multiple independent systems simultaneously.
Transaction Flow
A transaction passes through multiple independent control layers before reaching the blockchain. Each layer enforces its checks independently — bypassing one does not bypass the others.
What Each Layer Enforces
| Stage | What Happens | Who Controls It |
|---|---|---|
| Order creation | Transaction parameters are locked and immutable | You (via API or UI) |
| Quorum approval | M-of-N approvers cryptographically sign the order | Your designated approvers |
| Master approval | Binds the original order to the actual blockchain transaction — ensures what was approved is what gets signed | Platform + optional verifier |
| MPC signing | Each cosigner independently verifies all approvals before contributing its partial signature | Both cosigners independently |
| Post-sign verification | Assembled signature is verified against the public key before broadcast | Both cosigners independently |
Security Properties
- Approvals are cryptographic — each approval is a digital signature (RSA-PSS or Web3) that cannot be forged or repudiated
- Both cosigners verify independently — even if the platform is compromised, each cosigner rejects transactions without valid approvals
- Master approval prevents substitution — an attacker cannot swap a different blockchain transaction after approval
- No single point of bypass — compromising the platform or a single cosigner is insufficient to move funds
Signing Authority Guarantee
A complete private key is never instantiated — not in any cosigner's memory, not on any disk, and not anywhere in the platform. This is a mathematical property of the MPC protocol, not a policy control.
- No individual, system, or vendor component can reconstruct or export a complete key
- Transaction authorization requires participation from your signing components under your governance
- Carabaas acts solely as an ICT infrastructure provider — it cannot independently authorize, execute, or block transactions
Signing Algorithms
| Algorithm | Curve | Use Case |
|---|---|---|
| ECDSA | secp256k1 | Bitcoin, Ethereum, and compatible chains |
| ECDSA | secp256r1 (P-256) | Blockchains using the NIST P-256 curve |
| EdDSA | Ed25519 | Solana, Cardano, and compatible chains |
The cosigner implements CMP (Canetti-Maurer-Paillier) for ECDSA and an asymmetric protocol for EdDSA. Before signing, the cosigner independently verifies quorum approval signatures. After signing, it independently verifies the assembled signature using the derived public key — rejecting it if verification fails.
HD Key Derivation
Addresses are derived from the vault's master key using BIP-32 / BIP-44 hierarchical deterministic derivation with soft derivation paths:
m / 44 / coinType / accountIndex / change / addressIndex
This allows unlimited address generation from a single vault without additional MPC key ceremonies.