Hard limits
What the contract enforces whatever the model says.
The wallet contract enforces these on every execute, after the verdict. The model can only make a payment stricter than they allow, never looser.
| Limit | What it does | Set by |
|---|---|---|
| Per payment | the most one payment may send, per token, and in NEAR | owner: set_token, set_near_caps |
| Per day | the most all payments may send in one UTC day, per token, and in NEAR | owner, same calls |
| Receiver allowlist | which contracts the agent may call, such as wrap.testnet for wNEAR | owner: allow_receiver, disallow_receiver |
| Allowlisted signers | which TEE signing addresses the wallet accepts verdicts from | owner: register_signer, revoke_signer |
| Freeze | stops every payment until the owner unfreezes | owner: freeze, unfreeze |
| Cross-chain switch and recipients | payments through 1Click are off by default; when on, an optional list of Base addresses | owner: set_cross_chain, allow_cross_chain_recipient |
A token payment needs caps set for that token. Without them, the wallet refuses with "no caps set for this token".
On every proposal
- Expiry: an action expires at most an hour after it's proposed. An expired one can't execute.
- Nonce: each nonce executes at most once.
- At most 32 pending proposals. Expired ones are cleared with
prune. - Size:
args_jsonat most 2,048 bytes, a method name at most 64 characters, and never a call to the wallet itself.
What a wrong ALLOW can cost
If the model is fooled, the most one bad payment can send is the per-payment cap, and the most in a day is the daily cap, to a contract on the allowlist. Set the caps to what you'd accept losing in a day.
Changing them
The owner changes the limits by signing the setters with their own NEAR account; the web app's wallet page shows the current ones under Hard limits. See Manage the wallet and the contract reference.