Skip to content

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, kill-switching, scoping.

                HUMAN
                  │ passkey, hardware-protected

        MAIN ACCOUNT, adrian-main.agensai.eth
                  │ JAW smart account, passkey-rooted
                  │ Your bank. Recoverable from any device.

                  │ on-chain kill-switch grant: orchestrator → main

        ORCHESTRATOR, adrian-orc.agensai.eth
                  │ JAW smart account, local-key-rooted
                  │ Holds the working float ($50–$200 typical)
                  │ Spawns + scopes + revokes children (zero biometric)

       Children spend from orchestrator's pool via on-chain ERC-7715 grants

       ┌──────────┼──────────┐
       ▼          ▼          ▼
    alice      dca-bot    research
   .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, Account.create, 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 every direct main-account action (orchestrator setup, kill-switch sweep, recovery rehydration).
  • ENS: adrian-main.agensai.eth.

This is the only tier that requires biometric in normal operation, and only at infrequent lifecycle moments.

Tier 2, Orchestrator

Your orchestrator is autonomous. It's the wallet your AI uses to spawn and scope agents without asking you for a tap.

  • Type: JAW smart account, Account.fromLocalAccount, rooted in a local ECDSA key.
  • Storage: plaintext file at ~/.agensai/orchestrator.key, mode 0600. Same pattern JAW CLI uses.
  • Recovery: none directly. The orchestrator key is disposable. If your device is lost, your main account sweeps the orchestrator pool back via the on-chain kill-switch grant; you create a fresh orchestrator on a new device and rehydrate identity from ENS records.
  • Biometric: never. The orchestrator's local key signs everything it does.
  • ENS: adrian-orc.agensai.eth.

The orchestrator is autonomous and bounded. Anything it does is capped by the float you funded it with, typically $50 to $200. If it's compromised, your main passkey signs one transaction and the funds are home.

Tier 3, Agents

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

  • Type: JAW smart account, Account.fromLocalAccount, rooted in its own local ECDSA key.
  • Storage: plaintext file at ~/.agensai/agents/<name>.json, mode 0600.
  • Recovery: none directly. Rehydrated under a new orchestrator with the same name + scope from ENS records.
  • Biometric: never.
  • Funding model: Pattern B, the agent does not hold its own balance. It's an on-chain spender against the orchestrator's pool, scoped by an ERC-7715 grant.
  • ENS: <name>.agensai.eth.

This is the textbook ERC-7715 idiom. 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.

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. The boundary between "my real money" and "the working float."
  • Orchestrator = autonomy. A bounded, local key that can sign all day without bothering you. If it's lost or compromised, the kill-switch caps the damage.
  • 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, there's no AGENSAI policy engine sitting in the middle that could fail open.

Funding the orchestrator

Send USDC or ETH (or any ERC-20) to your orchestrator address. JAW supports ERC-20 gas natively, users select the gas token in the wallet dialog at signing time. AGENSAI ships no paymaster, no sponsorship, no gas infrastructure. You pay your own gas in whatever token you funded with.

TokenBehavior
ETHNative gas. Default if your orchestrator holds ETH.
USDCERC-20 gas, built-in to JAW. No configuration needed.
Other ERC-20Whatever JAW supports natively for ERC-20 gas.

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

ActionTaps
Spawn an agent0
Run an agent's task0
Top up the orchestrator (any wallet)0 from us
Revoke an agent0
Extend an agent's window (re-grant)0
Sweep one agent's permission and re-grant0
Delete the orchestrator (sweep all → main)1
Recover on a new device (rehydrate fleet)1

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