How Kairo Works

Kairo adds security without changing how you interact with crypto. This page explains what happens behind the scenes when you make a transaction—and why it makes your wallet significantly more secure.

The Simple Version

When you sign a transaction with Kairo:

You initiate a transaction in any dApp (Uniswap, OpenSea, etc.)
Kairo checks the transaction against your personal policy
If approved, the signature is created and the transaction proceeds
If blocked, you see exactly why and can adjust if needed
A record is created on-chain for verification

That's it from your perspective. The security happens automatically.

The Technology Behind It

Three key innovations make Kairo possible:

Split-Key Signing (2PC-MPC)

Traditional wallets store your entire private key in one place. If that place is compromised, your funds are gone.

Kairo splits your key into two pieces:

Your piece stays encrypted on your device
Kairo's piece is held across a distributed network

To sign any transaction, both pieces must cooperate. This means:

An attacker who steals your device can't sign (they don't have Kairo's piece)
A compromise of Kairo's network can't sign (they don't have your piece)
Only when both parties agree does a signature get created

The magic? Your blockchain address stays exactly the same. Other apps and contracts can't tell the difference—they just see a normal signature.

On-Chain Policy Enforcement

Your policy rules are enforced on Sui blockchain, not just on your device. Here's why that matters:

Device-only enforcement is weak. If someone compromises your browser extension, they could bypass local checks. But they can't modify code running on a blockchain.

When you try to sign a transaction:

Kairo's policy engine on Sui evaluates your request
If it matches your policy, a receipt is created as proof
The receipt is required before any signature can happen
After signing, the receipt is consumed (can't be reused)

This means even if an attacker somehow got access to both key pieces, they still couldn't sign a transaction that violates your policy. The blockchain itself enforces your rules.

Immutable Audit Trail

Every signing action creates a permanent record called a custody event. These records are:

Hash-linked — Each event references the previous one, creating a tamper-proof chain
On-chain — Stored on Sui where they can't be modified or deleted
Verifiable — Anyone can check that a transaction was properly authorized

This isn't just for compliance. If you ever question whether a transaction was legitimate, you can trace exactly:

Which policy version authorized it
When the approval happened
What the intended destination and amount were

The Flow in Detail

Here's what happens when you swap tokens on a DEX:

You click "Swap" on Uniswap
        ↓
Uniswap asks your wallet to sign the transaction
        ↓
Kairo Extension intercepts the request
        ↓
Extension computes a unique fingerprint (hash) of the transaction
        ↓
Request sent to Sui: "Does this match the user's policy?"
        ↓
Policy Engine checks:
  ✓ Is the destination (Uniswap Router) allowed?
  ✓ Is the amount within limits?
  ✓ Is this chain allowed?
  ✓ Is the policy still valid (not expired)?
        ↓
If all checks pass, a PolicyReceipt is created on-chain
        ↓
Your device and Kairo's network each compute their part of the signature
        ↓
The partial signatures combine into a complete signature
        ↓
CustodyEvent is recorded on-chain
        ↓
Signed transaction is broadcast to Ethereum
        ↓
Swap completes normally

All of this happens in seconds. Most of the time, you won't notice any delay.

What Gets Checked

Every transaction is evaluated against your policy. Here's what Kairo can check:

Destination

Allowlist: Only these specific addresses can receive funds
Denylist: These addresses are blocked, everything else is allowed

Amount

Maximum amount per transaction
Different limits for different tokens
Daily or weekly caps (coming soon)

Contract Interactions

Which contract functions are allowed
Which are explicitly blocked (like unlimited token approvals)
Raw data validation for advanced users

Chain

Which blockchains you're willing to use
Prevent accidental transactions on the wrong network

Time

Policy expiration dates
Future: Time-delayed transactions for large amounts

Multiple Chains, One Policy

Kairo works across:

Ethereum and EVM chains (Base, Arbitrum, Optimism, Polygon, etc.)
Bitcoin (PSBT signing)
Solana (transaction signing)

Your policy is defined once and applies everywhere. The same allowlisted address works whether you're on Ethereum mainnet or Base—because Kairo understands how addresses map across chains.

What If I Need to Override?

Policies aren't prisons. If you need to send to a new address:

The transaction will be blocked with an explanation
You can choose to add the address to your allowlist
Re-try the transaction—it will now succeed

For high-security setups, you can configure policies to require a time delay before changes take effect. This prevents an attacker from quickly modifying your policy to bypass protections.

Security Guarantees

Kairo's architecture provides these guarantees:

| Threat | How Kairo Protects | |--------|-------------------| | Phishing site tricks you into signing | Policy blocks transactions to unknown addresses | | Malware on your device | Both key pieces needed; attacker only has one | | Kairo's servers compromised | Attackers don't have your local key piece | | Replay attacks | Each receipt is consumed after use | | Fake receipts | Receipts are minted on-chain, cryptographically verified |

Want to Go Deeper?

Security Model — Technical details of how protection works
Threat Model — What attacks Kairo defends against
Creating Policies — Advanced policy configuration