The three-tier identity model

AGENSAI splits identity into three tiers. Each tier has a distinct security profile, a distinct biometric requirement, and a distinct lifetime. This is the architectural anchor for everything else: spawning, recovery, retiring, scoping.

                HUMAN
                  │ passkey, hardware-protected
                  ▼
        MAIN ACCOUNT, yourname.agensai.eth
                  │ JAW smart account, passkey-rooted
                  │ Your bank. Recoverable from any device.
                  │
                  │ co-owner of every orchestrator you spawn agents under
                  ▼
        ORCHESTRATOR, yourname-orc.agensai.eth
                  │ JAW smart account, multi-owner
                  │ Owner #1: local key on this device (fast path for chat)
                  │ Owner #2: your main account (recovery + retire authority)
                  │ Holds the working float
                  │
       Agents spend from the orchestrator's pool via ERC-7715 grants
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
    dca-bot   subs-payer   trader
   .yourname  .yourname  .yourname
   -orc       -orc        -orc
   .agensai   .agensai   .agensai
    .eth       .eth       .eth

Tier 1: main account

Your main account is your bank. It holds value you don't want exposed to a device compromise.

• Type: JAW smart account, passkey-rooted.
• Storage: key lives in your hardware (Secure Enclave, TPM, Android Keystore). Managed by JAW via keys.jaw.id.
• Recovery: automatic on any device via your passkey + JAW's recovery flow.
• Biometric: required for orchestrator setup, retire, and any direct on-chain action by main.
• ENS: yourname.agensai.eth.

This is the only tier that requires biometric in normal operation, and only at orchestrator-lifecycle moments. Day-to-day agent work is signed by the orchestrator's local key without any biometric.

Tier 2: orchestrator

Your orchestrator is autonomous on this device, recoverable from any device.

• Type: JAW smart account, multi-owner. Owner #1 is a local ECDSA key on the device that paired. Owner #2 is your main account (auto-installed on first agent spawn).
• Storage: local key in plaintext file at ~/.agensai/orchestrator.key, mode 0600.
• Recovery: durable. The local key is a fast-path signer for chat-spawned UserOps on this device. If you lose the device, main is still a co-owner and signs from any other device.
• Biometric: none for chat-driven agent spawning (orchestrator's local key signs). One biometric for any main-signed action (top up flow, retire flow) initiated from the dashboard.
• ENS: yourname-orc.agensai.eth.

The orchestrator is autonomous and recoverable. The local key signs all day without bothering you. If the device is lost or the local key is compromised, your main passkey from any other device can drain the orch's balance back to main and revoke every agent under it in one ceremony.

Tier 3: agents

Each agent is a named, scoped spender on the orchestrator's pool.

• Type: JAW smart account, rooted in its own local ECDSA key. Permissioned by an ERC-7715 grant from the orchestrator.
• Storage: plaintext file at ~/.agensai/agents/<name>/, mode 0600.
• Recovery: none directly. Agents are tied to a specific orchestrator. If you retire the orchestrator, all agents under it are revoked and stop. If you only lose the device, agents continue working because their permissions reference the orchestrator address (which main still co-owns), not the device's keys.
• Biometric: never.
• Funding model: the agent does not hold operational balance. It's a session-key style spender against the orchestrator's pool, scoped by its ERC-7715 grant.
• ENS: <name>.yourname-orc.agensai.eth.

The grant carries the calls allowed (which contracts, which selectors), the spends allowed (which token, how much, what period), and an expiry. The on-chain validator enforces all of it. There's no AGENSAI middleware in the spending path.

Why three tiers and not one

A passkey-only model would mean every agent action requires biometric. Useless for autonomous agents.

A single hot-wallet model would mean a device compromise drains everything. Unacceptable.

The three-tier split:

• Main = sovereignty. Hardware-protected. Cloud-recoverable. Co-owner of every orchestrator you've used. The boundary between "my real money" and "the working float."
• Orchestrator = autonomy. A multi-owner smart wallet with one local key for fast signing and one durable owner (main) for recovery. Bounded by main's ability to drain or retire at any time.
• Agents = scope. Each agent is its own scoped spender, so a compromise of one agent doesn't compromise the others. The grant is on-chain and validator-enforced, there's no AGENSAI permission engine that could fail open.

Funding the orchestrator

Send USDC or ETH to your orchestrator address. JAW supports ERC-20 gas natively, so you don't need to hold ETH for gas if you have USDC. Pick the gas token in the wallet dialog at signing time. AGENSAI ships zero paymaster, zero sponsorship, zero gas infrastructure. You pay your own gas in whatever token you funded with.

This is non-negotiable architecture: AGENSAI runs zero gas infrastructure, has zero gas liability, and never holds a sponsorship relationship.

Lifetime ops, by biometric cost

Most users: 2 lifetime taps plus 1 per occasional management event.