Contents

05Architecture

One NFT, One Smart Account

NFT-bound ownership, programmable validation, and six invariants that do not move.

The account design combines an NFT-bound ownership reference with programmable transaction validation.

ERC-6551 is the natural reference for token-bound accounts. ERC-4337 provides an account-abstraction transaction model. Modular account interfaces such as ERC-7579 can organise policy validators and executors. These are design inputs, not a claim that a deployed Motes contract stack already implements every standard.

Core invariants

  1. Each NFT resolves to one canonical account identity at a time.
  2. The account's funds are never held in the AI provider's ordinary operating wallet.
  3. The AI signer cannot grant itself broader permissions than the owner approved.
  4. Risk limits are enforced by a trusted policy path at transaction execution, not only in a server interface.
  5. Recovery and owner withdrawal never depend solely on the Motes website staying online.
  6. Account upgrades and any administrative powers have published boundaries.

Transaction authorisation model

  1. Owner signs policytargets, assets, spending, lifetime
  2. Agent constructs candidate actiontyped payload and expected effects
  3. Off-chain risk screeningsimulation and current exposure
  4. Account validatorsignature, nonce, limits, destination
  5. Protocol adapterbounded call to an approved contract
  6. Chain receiptaccounting and monitoring

Owner keys and session keys

The owner key is high authority. It can change strategy permissions, stop the service and initiate owner-authorised withdrawals. The agent session key is constrained: it can call only approved functions, on approved contracts, within time and spending limits. Session keys are rotatable and revocable, and they are invalidated when ownership changes according to the deployed transfer policy.

Upgrade safety

Upgradeable contracts add operational flexibility and governance risk. Sensitive upgrades should pass independent review, multisignature authorisation, time delays where viable, and visible upgrade events. Recovery authority and upgrade authority must never quietly become unrestricted withdrawal rights.