Umi Signer

Umi Signer is your on-chain security layer. It is a smart contract on Sui that holds your dWallet capabilities and enforces the rules you set - without trusting anyone.

​

What is Umi Signer

When you create a Umi account, a Umi Signer object is created on Sui. This object:

• Holds your dWallet capabilities (the ability to sign on each chain)
• Enforces policies you define using composable rules
• Authorizes DApps, agents, and services you approve
• Executes rules automatically, trustlessly, on-chain

Think of it as a programmable vault for your signing power. You set the rules, and the blockchain enforces them. No human in the loop. No trust required.

​

Why this matters

Before Umi Signer, you had two options:

1. Full control - You approve every transaction manually. Secure but not automated.
2. Give up control - Let a service or bot hold your keys. Automated but risky.

Umi Signer gives you a third option: programmable control. You define exactly what can happen, and the blockchain enforces it. Automation without sacrificing security. This lets Umi recreate features that were only possible on centralized exchanges - but without giving up your keys or trusting a company.

​

How Signing Policies Work

​

The Hot Potato Pattern

When something wants to sign using your dWallet, a SigningRequest is created. This request must collect “receipts” from all your configured rules before the wallet can be borrowed for signing. Once signing completes, the request is destroyed - it can never be reused.

​

Rule Composition

Rules can be combined in two ways: Main Rules (OR logic) - At least ONE main rule must be satisfied

• Authorization whitelist OR Beneficiary access

Stackable Rules (AND logic) - ALL stackable rules must be satisfied

• Timelock AND Spending limits AND 2FA

This composition lets you build complex authorization patterns:

• “My backend service OR my beneficiary (after 365 days inactive) can sign, but always with a 1-hour cooldown”
• “Only whitelisted addresses can sign, and all transactions need 2FA approval”

​

Available Rules

​

Authorization Rule (Main)

Whitelist-based authorization for wallet access. What you configure:

• List of addresses allowed to request signatures

How it works:

• Only addresses in the whitelist can initiate signing
• Owner can add/remove addresses at any time
• Perfect for backend services, agents, and automation

Use cases:

• Allow your trading agent’s address to sign
• Give team members signing access
• Authorize specific services

​

Beneficiary Rule (Main)

Emergency and inheritance access after owner inactivity. What you configure:

• Beneficiary address
• Inactivity period (in seconds)

How it works:

• If the owner doesn’t perform any wallet operations for the specified period, the beneficiary can sign
• Only owner actions reset the timer (placing wallets, withdrawing, registering shares)
• Signing by whitelisted services does NOT reset the timer
• Beneficiary never owns the wallet - they only gain signing rights

Use cases:

• Estate planning - assets transfer to heirs after 365 days of inactivity
• Corporate backup - deputy can act if CEO is unavailable for 30 days
• Emergency recovery - trusted friend can help after 90 days

​

Spending Limit Rule (Stackable)

Enforce maximum spending amounts validated by a Trusted Execution Environment. What you configure:

• Per-transaction USD limit
• Time window (hourly, daily, weekly)
• Maximum USD spending per window
• Allowed recipient addresses (optional)
• Blocked recipient addresses (optional)

How it works:

• TEE parses the actual transaction bytes
• Extracts recipient address and amount
• Fetches real-time USD value
• Signs an attestation if within limits
• On-chain verification against TEE’s public key
• Spending tracked per time window

Use cases:

• Limit agents to $1,000 per transaction
• Cap daily spending at $10,000
• Block transfers to unknown addresses

​

Timelock Rule (Stackable)

Enforces a cooldown period between consecutive signatures. What you configure:

• Delay in seconds between signatures

How it works:

• Checks time since last signing activity
• All signing activity counts (not just owner)
• Prevents rapid consecutive signatures

Use cases:

• Give yourself time to notice unauthorized activity
• Prevent rapid drainage if something is compromised
• Rate limit burst attacks

​

Quota Rule (Stackable)

Rate limiting through request counting. What you configure:

• Global limits (apply to entire wallet):
  • Time window and max requests per window
  • Lifetime maximum requests
• Per-user limits (apply to individual addresses):
  • Time window and max requests per window
  • Lifetime maximum per user

How it works:

• Counts signing requests per time window
• Resets when window expires
• Total requests never reset

Use cases:

• “Wallet can sign max 100 times per day”
• “Agent X can sign max 10 times per hour”
• “Bot has lifetime limit of 1000 signatures”

​

Two-Factor Authentication Rule (Stackable)

Requires multiple parties to approve the same transaction. What you configure:

• List of factor addresses (the parties who must approve)

How it works:

1. User creates a transaction and computes its hash (intent_hash)
2. User shares intent_hash with all factors off-chain
3. Each factor calls the contract to approve that specific hash
4. User submits transaction - contract verifies all factors approved
5. Approvals are consumed and cannot be reused

Use cases:

• Corporate controls requiring CEO + CFO approval
• High-value transactions need board approval
• Multi-party authorization for sensitive operations

​

Lock Rule (Stackable)

Prevents wallet withdrawal - signing only through policy. What you configure:

• Permanent flag (if true, can never be removed)

How it works:

• Locked wallets cannot be withdrawn from Umi Signer
• They can only be used via policy-enforced signing
• Permanent locks cannot be undone

Use cases:

• Ensure wallet always goes through policy checks
• Create “signing only” wallets for maximum security
• Long-term storage with policy protection

​

TEE Enforcement

For spending limits and recipient validation, Umi uses Trusted Execution Environments (TEEs) based on AWS Nitro Enclaves. What the TEE does:

1. Receives raw transaction bytes (EVM, Solana, Sui, etc.)
2. Parses the transaction to extract recipient and amount
3. Fetches real-time USD value from price oracles
4. Validates against your configured limits
5. Signs an attestation if the transaction is allowed
6. On-chain contract verifies TEE signature

Security guarantees:

• TEE code is verified through Platform Configuration Registers (PCRs)
• Attestations expire after 5 minutes (no replay)
• TEE cannot be modified without changing PCRs
• Verification happens on-chain, trustlessly

​

Authorizing Agents

Umi Signer is how you give AI agents the ability to sign on your behalf - safely. How it works:

1. You add the agent’s address to your authorization whitelist
2. Configure spending limits and other stackable rules
3. The agent requests signatures through the Umi API
4. Umi Signer enforces all your rules on every request

Example configurations:

• Trading bot can swap tokens, max $5,000 per trade, max $25,000 per day
• Payment processor can send USDC to addresses on your payroll list
• Rebalancing agent can move funds between your own addresses

The agent never has your keys. It requests signatures, and Umi Signer decides whether to approve based on your policies.

​

Ownership and Control

Your Umi Signer is a Sui object, and you control who owns it.

​

zkLogin for Simplicity

By default, your zkLogin account (Google, Apple, Facebook, passkey) owns your Umi Signer. This gives you the streamlined experience - no seed phrases, no hardware devices, just log in and go.

​

Hardware Wallet for Maximum Security

Want even more control? You can transfer your Umi Signer ownership caps to a hardware wallet (Ledger, etc.) or any other Sui wallet. Your hardware wallet becomes the ultimate authority over your signing policies.

​

Multi-Wallet Authorization

You can authorize multiple wallets to interact with your Umi Signer:

• Your zkLogin for daily use
• Your hardware wallet for high-value approvals
• A trusted family member’s wallet for recovery

​

Transfer Ownership Anytime

Moving your Umi Signer caps is just a Sui transaction. Transfer from zkLogin to hardware wallet when you’re ready for maximum security. Or set up a multi-sig arrangement where both must approve major changes.

​

Rule Change Protection

For critical signing policies, you can enable rule change protection: Timelock on rule changes:

• Removing a rule requires proposing the removal first
• A configurable delay (e.g., 24 hours) must pass
• You can cancel the removal during the delay
• Only after the delay can the rule be removed

This gives you time to react if someone tries to weaken your security. Permanent rules:

• Some rules (like lock_rule) can be set as permanent
• Permanent rules can never be removed
• Use carefully - this is irreversible

​

On-Chain, Trustless, Yours

The key insight is that none of this requires trusting Umi:

• Policies are stored on Sui, not on our servers
• Enforcement happens in smart contracts, not in our code
• Rules execute even if Umi stops existing
• You can verify everything on-chain
• You can transfer ownership to any wallet you control

This is what decentralization actually means: you set your rules, and the system enforces them without any company having override power.

​

Managing Your Umi Signer

In the Umi app, you can:

• View all active policies
• Add or modify spending limits
• Configure timelock delays
• Set up beneficiary access
• Manage address whitelists
• Review agent permissions
• See audit logs of all policy checks

Your Umi Signer is as flexible or as locked-down as you want it to be.