Sup Wallet's solution

Replace the signature button with a programmable boundary. A Sup Wallet is a smart-contract vault governed by typed, revocable, condition-gated allowances — so the wallet learns what to allow, and you stop being the bottleneck.

#Grant, not sign

You set a boundary once: who can spend, on which protocol, up to how much, under what conditions. Then services, family, and AI agents act inside the lines — and you step back. The boundary is:

Typed — per protocol and per coin. An agent allowed to swap SUI on Cetus can't touch your USDC or your NFTs.
Auditable — every grant, spend, debit, and revoke emits an on-chain event; indexers mirror your wallet's exact state for free.
Revocable — one transaction removes a delegate and clears its remaining allowance. No ghost approvals.

#Three roles, one trust path

   Owner grants  ──▶  Orchestrator plans  ──▶  Protocol tools draft
   (you, once)        (intent + policy)        (SDK-backed unsigned bytes)

Any number of steps run as one all-or-nothing PTB — swap → lend → log in a single transaction. If any step fails, nothing moves. (This atomicity is Sui-native.)

#Programmable authority — a proof, not a password

The boundary is only as good as how precisely you can shape it. So in Sup a delegate isn't an address — it's whatever can prove it's allowed. Funds don't unlock because someone holds a key; they unlock because a condition is provably true on-chain:

a ZK proof verifies,
an oracle says the price sits in a band,
an escrow job is marked delivered,
a timelock elapses, or another object reaches a state…

Mechanically, a delegated spend emits a SpendRequest hot potato that confirm_spend releases only once ≥ 1 auth rule (who) OR-passes and every caveat rule (conditions) AND-passes. A rule is a tiny Move package that reads the request and stamps or aborts — it can never change the amount or recipient, so even a hostile rule only blocks the people who opted into it.

#Strictly more general than EVM delegation

On EVM a delegate is an address with a signature. In Move, an arbitrary contract is a first-class delegate with no signature at all — it proves authority by constructing its own witness type (only its defining module can) and stamping the request, gating that stamp on any on-chain condition it likes. The wallet core stays deliberately dumb: it only checks "did the rules the owner trusts all sign off?" — so the space of conditions is unbounded and permissionless. Anyone can publish a new rule — ZK, oracle, KYC, quorum, velocity, escrow — to the rule marketplace, and any owner can opt in.

This mirrors three patterns Sup already follows: ERC-7710-style caveats for how an agent spends, ERC-8004 identity for who it is, and ERC-8183 escrow / assessors for agent commerce. The net: "this agent, ≤ 50 USDC/day, only to these addresses, only during market hours, and only once this ZK condition holds" is a single, enforceable on-chain policy — composed from small rules, none of which the wallet core had to know about.

#One extensible policy layer

The policy-rule marketplace remains the permissionless layer for conditions a delegate spends under. Protocol execution is not permissionless: Sup explicitly integrates and reviews protocol SDKs inside onchain-tools-service.

#Keyless by construction

Every helper — and the in-app AI CFO agent — returns data and unsigned transactions. Signing is always done by you (in your wallet). Policy-bounded TEE signing remains disabled until the signer and policy path are production-ready.

#Why it's safe by design

Hot-potato atomicity — released vault funds hand back a value Move won't let the transaction finish until it's settled, so a spend can't be left half-done.
Explicit protocol inventory — only reviewed, built-in integrations can draft transactions.
Sandboxed by policy — a buggy rule can only affect owners who explicitly opted into it, and owners can revoke authority.

Next: see it in action → Use cases, or go technical → Concepts · Quickstart.