Name the spender.
Permission belongs to one identity. A different requester fails the same test, even for a small amount.
A LITTLE PERMISSION GOES A LONG WAY.
Give permission.
Keep control.
Your agent needs a budget.
It does not need the whole treasury.
An interactive concept for scoped on-chain spending.
CHOOSE AN EXAMPLE MANDATE
Local scenarios. No active permissions.
SMALLER SCOPE.CLEARER AUTHORITY.DEFINE → TEST → INSPECT
01 / THE PERMISSION LAB
How much room
does the task need?
Set the rules. Try to cross them.
Local simulation · no wallet connection.
02 / TEST THE OPENINGACTIVE IN SIMULATION
REMAINING LOCAL BUDGET
1,000USDC
A boundary is only useful if you test it.
Run a request to inspect all five conditions.
LOCAL REQUEST LOG0 REQUESTS
Your test requests will appear here. Nothing has been submitted on-chain.
This lab tests a proposed rule set, not your wallet approvals or contract security. Example spender names are local identities, not verified addresses. Each permitted request consumes the simulated budget.
02 / AUTHORITY, MEASURED
An opening.
Not an open door.
The task gets enough room to work.
You define where that room ends.
Limit the exposure.
A total budget and a per-request cap answer different questions. The lab checks both.
Close on time.
A request at the expiry hour fails. An unused budget is not a reason to keep permission alive.
Keep the evidence.
Inspect every condition. Export the policy and request history before considering an on-chain integration.
03 / EVERY CONDITION HAS A SAY
“Allowed” should
come with a reason.
One failed condition closes the opening.
The rest of your budget stays where it is.
NARROW PASS / POLICY RECORDFIVE CONDITIONS. ONE DECISION.
PermissionMust be active
IdentityMust match
TimeBefore expiry
Per requestWithin cap
Total spendWithin budget
ENOUGH ROOM TO WORK.