Skip to main content

​
The Login Experience

When you sign in with Google, Apple, Facebook, or a passkey, you’re using zkLogin - a Sui technology that creates a blockchain identity from your existing account. No seed phrases. No private keys to manage. Your social login becomes your crypto identity.

​
Zero-Trust Custody

This is the core innovation that makes Umi different. When you create your account, two “dWallets” are created using Ika’s Distributed Key Generation (DKG):
  1. Your key share - Encrypted with your passcode, stored in the Ika network
  2. Network key share - Held by Ika validators
To sign any transaction:
  • You provide your share (by entering your passcode)
  • The network provides its share
  • Together they produce a signature via Multi-Party Computation
  • Neither party ever sees the complete key
This means:
  • Umi can’t steal your funds - we never have the complete key
  • Ika can’t steal your funds - they only have half
  • You’re always in control - nothing happens without your passcode

​
Multi-Curve Support

Your dWallets use standard cryptographic curves to generate addresses on any chain: SECP256K1 dWallet:
  • Ethereum, Bitcoin, Zcash, Tezos
  • Arbitrum, Optimism, Base, Polygon, Avalanche
  • Any EVM-compatible chain
ED25519 dWallet:
  • Solana, Cardano, XRP, Sui, IKA
  • Any chain using Ed25519 signatures
One account creation gives you addresses on 14+ chains. The math is deterministic - your keys always produce the same addresses through standard derivation paths.

​
Sui as the Coordinator

Sui is the “brain” that coordinates everything:
  • Account state - Your Umi Signer lives on Sui
  • Policy enforcement - Signing rules execute as Sui smart contracts
  • Transaction coordination - Signing requests flow through Sui
  • Containers - Cross-chain asset claims are Sui objects
  • Verifiability - Everything is indexed and auditable
But Sui doesn’t control your keys. It’s the coordination layer, not the custody layer.

​
The Umi Signer

Your Umi Signer is a Sui object that:
  • Holds capabilities to request signatures from your dWallets
  • Enforces your configured signing policies
  • Manages which addresses/agents can request signatures

​
Signing Policy Rules

Your Umi Signer can enforce multiple rules. Here’s how they work: Main Rules (OR logic):
RulePurpose
AuthorizationWhitelist addresses that can request signatures
BeneficiaryEnable inheritance after inactivity period
LockCompletely disable signing (emergency)
Stackable Rules (AND logic with main rules):
RulePurpose
Spending LimitCap USD per transaction (TEE-enforced)
TimelockRequire cooldown between signatures
QuotaLimit signatures per time window
2FARequire second factor approval

​
Hot Potato Pattern

Signing requests use Sui’s “hot potato” pattern:
  1. Create a SigningRequest object
  2. Request must visit each configured rule
  3. Each rule adds a Receipt if conditions pass
  4. Only when all receipts are collected can the dWallet be borrowed
  5. The signing request must be consumed - it can’t be dropped or stored
This ensures policies are enforced atomically and can’t be bypassed.

​
Signing a Transaction

Here’s the complete flow when you send a transaction:

​
Step 1: Build Transaction

You specify what you want to do (swap, send, stake, etc.). Umi builds the raw transaction bytes for the target chain.

​
Step 2: Policy Enforcement

The signing request goes through your Umi Signer:
  1. Authorization rule checks if the requester is whitelisted
  2. Stackable rules validate their conditions:
    • Spending limit checks transaction value
    • Timelock checks time since last signature
    • Quota checks signature count in current window
    • 2FA checks for approval (if required)
  3. Each passing rule adds its receipt

​
Step 3: TEE Validation (for spending limits)

If you have spending limits configured, a Trusted Execution Environment:
  1. Receives the raw transaction bytes
  2. Parses the transaction (supports EVM, Solana, Sui, Bitcoin, etc.)
  3. Extracts actual recipient and amount
  4. Fetches USD value from price oracles
  5. Validates against your limit
  6. Signs an attestation with timestamp and nonce
The on-chain contract verifies this attestation before allowing the signature.

​
Step 4: Distributed Signing

With all receipts collected:
  1. Your key share is decrypted (using your passcode)
  2. Ika network’s share participates
  3. MPC produces the signature without combining shares
  4. The complete key never exists

​
Step 5: Broadcast

The signed transaction is submitted to the destination chain. Umi handles chain-specific formatting and submission. From your perspective: confirm, enter passcode (if needed), done.

​
Gas Abstraction

Every blockchain requires gas fees in its native token. Umi abstracts this away completely.

​
How Gas Credits Work

  1. Deposit - Send any supported token to your gas balance
  2. Convert - Your deposit is converted to USD-denominated credits
  3. Transact - When you send a transaction, Umi pays gas in native tokens
  4. Debit - Your credit balance is debited the USD equivalent

​
Umi’s Gas Infrastructure

Behind the scenes, Umi maintains:
  • Gas accounts - Secure keypairs for each supported chain
  • Auto-refill - Accounts refill from USDC treasury when low
  • Balance monitoring - Continuous checks ensure accounts stay funded
  • Cross-chain refills - Treasury on Solana bridges to other chains as needed
You never need to hold ETH, SOL, or any other gas token. One USD balance covers all 14+ chains.

​
What You Can Deposit

  • SUI or USDC directly on Sui
  • Any token from any chain (converted via cross-chain swap)
  • Other stablecoins at market rates

​
Cross-Chain Containers

Containers are Sui objects that wrap dWallet capabilities with asset claims: 
Container (Sui object)
├── dWallet signing capability
├── Asset claims (what's in the wallet)
├── Chain + address reference
└── Metadata
Containers enable:
  • Unified view - See all assets in one place
  • Composability - Containers can interact with Sui DeFi
  • Trading - Transfer ownership of multi-chain wallets
  • Programmability - Build logic around wallet access
When you transfer a container, you transfer control of the signing capability - and with it, control of assets on the target chain.

​
AI Agent Integration

AI agents can operate your wallets within strict boundaries:

​
Agent Architecture

Hosted Agents:
  • Umi generates a Sui keypair for the agent
  • Agent address is added to your authorization whitelist
  • All signing goes through Umi’s infrastructure
External Agents:
  • Agent has its own keypair
  • API returns unsigned transaction bytes
  • Agent signs and broadcasts independently

​
Agent Execution Flow

  1. Agent builds transaction parameters
  2. Transaction submitted to Umi execution service
  3. TEE validates against your policies
  4. If valid, TEE signs attestation
  5. On-chain contract verifies attestation
  6. dWallet produces signature
  7. Transaction broadcast to target chain

​
Agent Boundaries

Even a compromised agent cannot:
  • Exceed per-transaction spending limits
  • Exceed daily spending caps
  • Send to blocked addresses
  • Bypass approval thresholds
  • Modify its own permissions
Agents operate freely within your configured boundaries. Nothing more.

​
Technical Architecture

┌─────────────────────────────────────────────────────────────┐
│                        Your Account                          │
├─────────────────────────────────────────────────────────────┤
│  zkLogin Identity ──► Sui Address ──► Umi Signer            │
│                                           │                  │
│                                    ┌──────┴──────┐          │
│                                    │   Policies   │          │
│                                    └──────┬──────┘          │
│                                           │                  │
│                    ┌──────────────────────┼──────────────────┤
│                    │                      │                  │
│              ┌─────┴─────┐          ┌─────┴─────┐           │
│              │ SECP256K1 │          │  ED25519  │           │
│              │  dWallet  │          │  dWallet  │           │
│              └─────┬─────┘          └─────┬─────┘           │
│                    │                      │                  │
├────────────────────┼──────────────────────┼──────────────────┤
│         EVM Chains │            Non-EVM   │                  │
│  ┌────────────────┐│  ┌──────────────────┐│                  │
│  │ Ethereum       ││  │ Solana           ││                  │
│  │ Arbitrum       ││  │ Sui              ││                  │
│  │ Optimism       ││  │ XRP              ││                  │
│  │ Base           ││  │ Cardano          ││                  │
│  │ Polygon        ││  │ IKA              ││                  │
│  │ Avalanche      ││  └──────────────────┘│                  │
│  │ Bitcoin        ││                      │                  │
│  │ Zcash          ││                      │                  │
│  │ Tezos          ││                      │                  │
│  └────────────────┘│                      │                  │
└─────────────────────────────────────────────────────────────┘

​
Why This Architecture

Security through distribution:
  • No single point of failure
  • No single party with complete access
  • Policies enforced trustlessly on-chain
Usability through abstraction:
  • One login for everything
  • One balance for gas
  • Familiar social auth
Flexibility through programmability:
  • Custom policies per user
  • Agent automation within boundaries
  • Composable with Sui DeFi
This is the stack that enables safe, autonomous, cross-chain crypto - without the traditional tradeoffs.