Security Model

Kairo's security isn't a single feature—it's a layered architecture where multiple protections work together. This document explains each layer, how they interact, and why this design keeps your assets safe.

Security Layers

Kairo provides three distinct layers of protection:

Layer 3: Audit Trail
    ↑ Records every action permanently
Layer 2: Policy Enforcement  
    ↑ Controls what can be signed
Layer 1: Key Protection
    ↑ Prevents unauthorized access to signing capability

An attacker would need to defeat ALL layers to steal your funds. Let's examine each one.

Layer 1: Key Protection (2PC-MPC)

The foundation of Kairo's security is that your complete private key never exists in any single location.

How Key Splitting Works

When you create a Kairo wallet:

Key material is generated in a distributed way
Your device keeps one piece (the "user share")
Kairo's network keeps another piece (the "network share")
Neither piece alone can sign anything

This is called Two-Party Computation Multi-Party Computation (2PC-MPC).

Why This Is Secure

Traditional wallet:

Private Key (one location)
     ↓
Attacker steals it → Funds gone

Kairo wallet:

User Share (your device) + Network Share (Kairo network)
           ↓                         ↓
     Both required to sign
           ↓
Attacker steals one → Still can't sign

For an attacker to sign transactions, they would need to:

Compromise your device AND
Compromise Kairo's distributed network

This is dramatically harder than traditional single-key attacks.

User Share Protection

Your share is protected by multiple mechanisms:

| Protection | What It Does | |------------|--------------| | Passkey encryption | Key share encrypted with hardware-backed credential | | Biometric requirement | Fingerprint/face required to decrypt | | Secure enclave | Key never leaves device's secure hardware | | No network export | Share never transmitted unencrypted |

Network Share Protection

Kairo's network share is protected by:

| Protection | What It Does | |------------|--------------| | Distributed nodes | Share split across multiple servers | | Geographic distribution | Nodes in different jurisdictions | | Threshold cryptography | Multiple nodes must cooperate | | Continuous rotation | Key shares refreshed regularly |

Layer 2: Policy Enforcement

Even if an attacker somehow obtained both key shares, they still couldn't sign arbitrary transactions. Every signature requires a valid policy receipt.

On-Chain Enforcement

Your policy lives on Sui blockchain as a smart contract. The enforcement happens on-chain, not on your device:

Transaction Request
       ↓
Policy Engine (Sui blockchain)
       ↓
   Checks:
   ✓ Destination in allowlist?
   ✓ Amount within limits?
   ✓ Contract function allowed?
   ✓ Chain permitted?
   ✓ Policy not expired?
       ↓
If all pass → PolicyReceipt minted
       ↓
Receipt required for signing

Why On-Chain Matters

If policy enforcement only happened on your device:

Malware could bypass the checks
A compromised browser extension could skip validation
Attackers could modify the code

With on-chain enforcement:

Code is immutable and public
Anyone can verify the enforcement logic
Device compromise doesn't bypass policy

Receipt Consumption

Policy receipts are one-time use:

Receipt minted when policy approves transaction
Signing uses and consumes the receipt
Receipt is deleted from blockchain
Same receipt can never be reused

This prevents replay attacks where an attacker tries to reuse an old authorization.

The PolicyVault

The PolicyVault is the ultimate gatekeeper. It's a smart contract that:

Validates the receipt matches the signing request
Verifies the receipt is for the correct policy version
Records the intent to prevent double-signing
Only then authorizes the MPC network to sign

No transaction can be signed without passing through the PolicyVault.

Layer 3: Audit Trail

Every signing action creates a permanent, tamper-proof record.

Custody Events

When you sign a transaction, a CustodyEvent is recorded with:

What was signed (transaction details)
When it was signed (timestamp)
Which policy authorized it (receipt reference)
The previous event's hash (creates chain)

Hash-Linked Chain

Each event references the previous one through cryptographic hashing:

Event 0 → Event 1 → Event 2 → Event 3
   hash   ←   hash   ←   hash   ←   hash

This means:

Events can't be modified (would break the hash chain)
Events can't be inserted (would require modifying subsequent hashes)
Events can't be deleted (missing link would be obvious)
Any tampering is immediately detectable

Verification

Anyone can verify the custody trail:

Fetch the event from Sui
Recompute the hash from event fields
Compare to stored hash
Verify it links to previous event
Continue backwards to verify entire chain

Trust Boundaries

Understanding where you need to trust what:

Fully Trusted

Things that must be secure for the system to work:

| Component | Why You Trust It | |-----------|------------------| | Your device | You physically control it | | Your passkey | Biometric-protected | | Sui blockchain | Byzantine fault tolerant | | Ika MPC network | Threshold cryptography |

Semi-Trusted

Components where on-chain verification provides safety:

| Component | Verification | |-----------|--------------| | Kairo backend | All actions verified on-chain | | Policy evaluation | Results minted as receipts | | Signing authorization | Vault enforces requirements |

Trustless

No trust required—anyone can verify:

| Component | How to Verify | |-----------|---------------| | Policy rules | Read the policy object on Sui | | Receipt validity | Check on-chain state | | Custody trail | Recompute hashes yourself | | Transaction history | Public blockchain data |

What Kairo Does NOT Protect Against

Transparency requires acknowledging limitations:

Device + Passkey Compromise

If an attacker has:

Physical access to your device
Your biometric (or device PIN)

They can sign transactions that match your policy. Kairo's policy limits the damage, but can't prevent all authorized actions.

Mitigation: Strong biometrics, don't share device PIN, use device lock timeouts.

Policy Misconfiguration

If your policy allows transactions you didn't intend:

Overly broad allowlist
No spending limits
Dangerous selectors allowed

Kairo will approve transactions matching that policy.

Mitigation: Start restrictive, test your policy, review regularly.

User Approval of Malicious Transactions

If you approve a transaction to a malicious address:

Even if address is in your allowlist
Kairo will sign it

Mitigation: Carefully review transactions, use meaningful names for addresses.

Blockchain-Level Attacks

Kairo can't protect against:

Smart contract bugs in protocols you interact with
Blockchain consensus failures
Oracle manipulation

Mitigation: Only interact with audited protocols, diversify across platforms.

Comparison with Alternatives

How Kairo compares to other security approaches:

vs. Seed Phrase Only

| Aspect | Seed Phrase | Kairo | |--------|-------------|-------| | Key storage | One location | Split between two | | Theft via phishing | Complete loss | Policy limits damage | | Recovery | Hope you backed up | Multiple options | | Audit trail | None | Complete |

vs. Hardware Wallets

| Aspect | Hardware Wallet | Kairo | |--------|-----------------|-------| | Key protection | Hardware isolation | 2PC-MPC split | | Policy enforcement | None | On-chain | | Multi-chain | Often limited | Unified | | Recovery | Seed phrase | Multiple options |

vs. Multi-Signature

| Aspect | Multi-Sig | Kairo | |--------|-----------|-------| | Multiple keys | Yes (multiple locations) | Yes (distributed) | | Policy flexibility | Limited | Extensive | | Chain support | Varies | Unified | | User experience | Coordinate signers | Single approval |

Security Guarantees Summary

Kairo provides these guarantees:

| If This Happens... | You're Protected Because... | |-------------------|----------------------------| | Device stolen | Attacker doesn't have network share | | Kairo servers compromised | Attacker doesn't have your share | | Phishing tricks you | Policy blocks unauthorized destinations | | Malware on device | On-chain policy still enforces rules | | Old receipt reused | Receipts are consumed after use | | Policy tampered | Policy is immutable on-chain | | History questioned | Hash-chain proves integrity |

Next Steps

Custody Verification — How to verify your audit trail
Threat Model — Specific attacks Kairo defends against
Creating Policies — Configure your protection rules