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