Decentralised News Research · Agentic finance controls
A dashboard can show “100 per day” while leaving several questions unanswered: 100 of which asset, over which period, through which signer, and including which pending requests? The useful unit of review is one granted permission on one execution path.
This guide provides a DN Permission Evidence Worksheet, a copyable record and two synthetic budget exercises. It extends our agentic wallet security guide with a narrower task: document what a particular control actually covers. There is no wallet ranking or claim that DN connected to and tested these products.
1. Give the permission an exact identity
Start with the permission actually granted or installed. A request in application code, a product feature list and an enabled control on the intended account are different evidence. Preserve the returned permission identifier and the current configuration, with a verification time.
DN’s proposed record binds together the account, network, asset contract, units, spender or signer, permitted action, enforcement component and version. If a control is described as “daily,” record the start and end of its actual accounting period. A fixed calendar day and a rolling 24-hour window permit different spending patterns near midnight.
Also distinguish the transaction’s destination contract from the final beneficiary. For an ERC-20 transfer, the token contract receives the call and the transfer parameters identify the beneficiary. Record both when both are meant to be restricted. The standard’s separate transfer and approval interfaces are a reason to inspect the action being authorized, rather than only the transaction’s native-asset value.
2. Read the boundary of the documented mechanism
The following examples illustrate different enforcement boundaries. They are current documentation findings, not interchangeable implementations or DN-tested performance results. Check the relevant account type, network and configuration before applying a finding to a particular wallet.
| Mechanism | Documented boundary | Record before relying on it |
|---|---|---|
| Coinbase Spend Permissions | A designated spender, specified token, allowance and period, enforced through the onchain Spend Permission Manager. This is distinct from CDP’s offchain policy system. | The permission and network, smallest-unit allowance, current period and recorded spend. Its presence does not establish a merchant allowlist or a cap on every other account authority. |
| Privy stateful policies | Aggregations count configured request metrics over rolling windows. Current documentation warns that concurrent requests can pass before totals update; these are not strict real-time caps. | Which operations count, the grouping of counters and concurrency handling. Unmatched metrics can contribute zero; transfers and approvals require separate coverage. |
| Safe spending limits | An onchain allowance for one spender and token, optionally recurring. It does not restrict the destination. A displayed USD estimate is converted into a token amount at setup. | The enforced token amount, reset rule and recipient requirements. Removal is per token and takes effect when the Safe transaction executes; normal owner-authorized transactions remain a separate path. |
A precise conclusion might be: “This permission limits this spender’s token use during the returned period; recipient restrictions have not been established.” That is more useful than a broad “wallet protected” badge.
Costs and access are implementation-specific. The Coinbase guide documents gas-bearing permission operations; Safe documents signatures and gas for allowance setup/removal and current plan restrictions for adding limits in its wallet interface. Consult those linked guides for the selected route. This article does not promise free or universally available configuration.
3. A transfer limit may leave another signing path
Privy’s conditional-signer recipe illustrates restricted and permissive signers on the same wallet. Each signer’s override is evaluated independently; a denied request does not automatically fall back to another signer. The application chooses the authorization key. The practical review question is whether the agent can reach another credential or endpoint that grants broader authority.
Record who can edit the policy, replace the signer or enable another execution route. An emergency administrator may deliberately retain broader powers. That does not make the agent’s limit useless, but it changes the claim: the limit covers the restricted route, while the administrator remains a separate trust assumption.
Do not stop at direct transfers. An ordinary ERC-20 approval lets a spender use an allowance for that token and owner. The base interface supplies no automatic daily reset or expiry. DN’s implication is that disabling an agent’s signing service does not, by itself, clear every existing token approval.
Keep the emergency procedure in a separate operational record. Our kill-switch and revocation guide covers the wider containment problem. Here, identify precisely which permission would be removed and which related powers would require another check.
4. Write the accounting model before testing the cap
Everything in this section is synthetic. EXAMPLE is an invented token with six decimals. It has no stated market value. The proposed policy allows direct transfers to Merchant A, up to 25 tokens per request and 100 per fixed UTC calendar day, during a separate 09:00–17:00 UTC active session. These are illustrative rules, not a configuration supplied by any named provider.
For this exercise only, assume a system reserves accepted but unfinished payments against the same shared budget. Completed usage and reservations must be disjoint. Fees are excluded from the token cap and require a separate control for the fee asset. No approval, swap, permit or other signing action is authorized by the proposed example.
This is DN’s accounting model. A reservation requires implementation support; a token allowance read does not establish that such a reservation exists. A request must pass every other applicable rule as well as this amount check.
| Item | EXAMPLE tokens | Smallest units |
|---|---|---|
| Period cap | 100 | 100,000,000 |
| Completed usage | 55 | 55,000,000 |
| Outstanding reservations | 20 | 20,000,000 |
| Available before the next request | 25 | 25,000,000 |
| Proposed new request | 25 | 25,000,000 |
| Counted total after reservation | 100 | 100,000,000 |
The request meets both amount limits exactly. It is eligible under those amount rules if its beneficiary, asset, session and execution path also qualify. The remaining admission budget becomes zero. A later request for 0.000001 token would exceed the period cap even though it is well below the per-request cap.
When a reserved payment completes, move its amount from reserved to completed once. Do not add it to completed while keeping the same amount reserved. Conversely, a timeout is not evidence of cancellation: release a reservation only under the implementation’s documented final-state rules. A refund should restore spending capacity only if that is an explicit policy decision supported by reconciled evidence.
Synthetic exercise B: two requests read the same headroom
Start a separate example with 60 completed tokens and 20 reserved. There are 20 tokens left. Two workers each propose 15 tokens. Each request fits the 25-token per-request limit and appears to fit the same 20-token headroom.
If both are admitted against stale state, counted commitments become 60 + 20 + 15 + 15 = 110. In a hypothetical atomic reservation design, the first request raises commitments to 95 and leaves five available; the second is rejected. This comparison explains what evidence to request. It is not a measured result for Coinbase, Privy or Safe.
Admission and execution are different stages. An onchain mechanism that checks updated shared state may reject a later execution even if an application queued both requests. Record where the cap is enforced and what happens to the rejected request, its reservation and any costs. Do not infer inevitable onchain overspending from a queue race.
DN Permission Evidence Worksheet
Use one record for each permission and execution path. Mark each claim as documented, configuration inspected, controlled test observed or unknown. These describe evidence, not a cumulative security score. Documentation and an inspected setting do not establish an observed rejection.
| Record | Required evidence | Unresolved when… |
|---|---|---|
| Identity and actual grant | Account, network, asset contract and units, spender/signer, installed permission identifier and verification time. | You have only a feature page or the permission requested by the application. |
| Enforcement component | Service, validator, module or contract; version; execution entry point; stage at which it rejects. | The only evidence is a budget displayed in the agent interface. |
| Amounts and period | Per-request and cumulative caps, smallest-unit values, fixed/rolling period, boundaries, grouping and fee treatment. | “Daily” or “USD” is shown without the enforced unit and reset rule. |
| Allowed movement | Beneficiary, token contract, permitted methods and parameters; separate treatment of approvals and signed messages. | Only the native value or outer destination is checked. |
| Pending work and retries | Counter update stage, reservation support, concurrency behavior, distinct request identity and release rules. | A timeout or retry can change headroom without a reconciled outcome. |
| Other authority | Other signers/modules, policy administrators, existing approvals and outstanding signed permissions. | One restricted signer is presented as proof that the entire wallet is capped. |
| Observed rejection | Successful permitted control; violating case; policy-specific result; timestamp/block and redacted evidence reference. | The request failed because of balance, connectivity or malformed input. |
| Revocation and residual state | Exact grant removed, effective state/receipt, follow-up evidence and separate remaining authorities. | Only a “revoked” interface label or one zero allowance is available. |
Store evidence references in your own controlled records. Do not paste keys, seed phrases, live signatures, private customer data or internal account logs into a public worksheet. This page has no wallet connection or upload mechanism.
These checkboxes are a reading aid. They calculate no score, submit nothing and have no application-level saving or export. Keep your completed evidence record separately.
Boundary cases to put in the record
Use an isolated, authorized test environment with no valuable funds. Establish a permitted control first, change one relevant condition at a time where possible, and attribute the result to the intended rule. The expected outcomes below belong to DN’s synthetic policy; they are not test results.
Amount: test the exact boundary and one smallest unit above it
With sufficient period headroom, 25 EXAMPLE meets the per-request amount rule; 25.000001 exceeds it. After counted period usage reaches 100, a new 0.000001 request exceeds the cumulative cap. Record whether each rejection is attributable to the intended amount rule.
Scope: change the beneficiary, asset, network or action
A request to Merchant B or a different asset/network falls outside the synthetic grant. So does an approval or typed-data signature. Test only restrictions the implementation claims to enforce. If a mechanism has no recipient control, record that limitation instead of calling an allowed recipient change a failed promised feature.
Time: identify what expires and what resets
The illustrative session admits actions from 09:00 UTC inclusive to 17:00 UTC exclusive. Its fixed daily counter resets at 00:00 UTC, but a reset does not reactivate an expired session. Real implementations need their own exact boundaries and clock semantics recorded.
Concurrency and retries: preserve a shared accounting state
Use the two 15-token requests from exercise B to ask where shared state is checked. Record distinct reservations and executions. A retry identity should not be assumed to prevent duplicate execution unless the relevant service or contract enforces that behavior. Reconcile before releasing headroom after an uncertain outcome.
Causality: distinguish a policy rejection from another failure
Privy’s policy overview says simulation can fail before the policy is evaluated for operations that sign and broadcast. Insufficient funds or a simulation revert therefore does not prove the spending rule worked. Save the actual reason and the successful permitted control alongside the violating case.
Copyable proposed permission record
DN Proposed Permission Record v0.1. This is a documentation template, not an industry standard or executable wallet policy. Its identifiers are synthetic; blank and unknown fields deliberately remain unverified. Copy it into your own notes and replace the example constraints with the actual grant.
Open the synthetic JSON evidence record
{
"record_type": "DN proposed permission evidence record v0.1",
"example_only": true,
"executable_wallet_configuration": false,
"evidence_status": "NOT_TESTED",
"identity": {
"network": "SIMULATION_ONLY",
"account": "EXAMPLE_ACCOUNT",
"signer_or_spender": "EXAMPLE_AGENT",
"asset_contract": "EXAMPLE_TOKEN",
"asset_symbol": "EXAMPLE",
"asset_decimals": 6,
"permission_id": "EXAMPLE_PERMISSION",
"enforcer_and_version": "RECORD_REQUIRED"
},
"proposed_constraints": {
"operation": "direct_token_transfer",
"beneficiaries": [
"EXAMPLE_MERCHANT_A"
],
"per_request_base_units": "25000000",
"period_cap_base_units": "100000000",
"period_type": "fixed_calendar_day_UTC",
"period_reset": "00:00:00Z",
"active_from": "2026-10-19T09:00:00Z",
"active_until_exclusive": "2026-10-19T17:00:00Z",
"approvals_and_typed_data_signing": "NOT_AUTHORIZED_BY_THIS_RECORD",
"fees": "EXCLUDED_REQUIRES_SEPARATE_NATIVE_ASSET_CONTROL",
"portfolio_loss_limit": "NOT_PROVIDED"
},
"accounting_evidence": {
"shared_counter_scope": "RECORD_REQUIRED",
"pending_reservation_support": "UNVERIFIED",
"atomic_admission_or_execution": "UNVERIFIED",
"retry_and_release_rules": "RECORD_REQUIRED"
},
"authority_review": {
"other_signers_and_modules": "NOT_INSPECTED",
"existing_token_approvals": "NOT_INSPECTED",
"outstanding_signed_permits": "NOT_INSPECTED",
"who_can_change_this_policy": "RECORD_REQUIRED"
},
"verification": {
"configuration_evidence": null,
"allowed_control_result": null,
"rejection_reason_and_evidence": null,
"revocation_evidence": null,
"checked_at": null
}
}5. Write a conclusion that stays within the evidence
A useful completed record might say: “The configured signer is documented to reject this token transfer above this cap. The configuration was inspected on the stated date; controlled rejection testing remains outstanding. Other owner authority is outside this limit.” It tells the next reviewer exactly what is known and what work remains.
A spending ceiling also says little about the value received. Paying an allowed recipient within budget can still buy a useless service. Trading within a transfer allowance can still create price exposure, leverage or liquidation risk. Record loss and exposure controls separately, including their valuation source and enforcement point, or mark them unsupported.
For deciding how much authority a workflow needs in the first place, see DN’s AI Trading Authority Ladder. For payment negotiation and settlement architecture, use the agent payment protocol guide. Neither replaces a permission-specific evidence record.
DN Alpha Thesis
The practical advantage is a permission that another person can inspect: a precise grant, a named enforcer, attributable evidence and an honest boundary. Automating more financial actions makes that record more valuable, because it reduces the distance between a policy claim and the evidence needed to challenge it.
Frequently asked questions
Does a spending limit cover every route out of a wallet?
Only if the implementation and configuration establish that scope. Record other signers, owner authority, modules, approvals and signed permissions separately. One restricted route does not establish a wallet-wide cap.
Does a failed payment prove the spending policy worked?
No. A balance error, unavailable service or failed simulation can stop a request before the relevant policy is evaluated. Preserve the rejection reason and a successful permitted control for comparison.
Does a token spending cap limit investment losses?
No. It limits the specified token movement under its own rules. Price exposure, leverage, fees and the value of what is purchased need separate controls and evidence.
Does an ERC-2612 permit deadline make an allowance expire?
The deadline governs acceptance of the signed permit. It does not by itself impose expiry on the resulting ERC-20 allowance. Inspect current allowance and outstanding signed authority separately.
Is the DN JSON record a wallet configuration I can deploy?
No. It is a proposed evidence template with synthetic identifiers and unverified fields. It sends no transactions and creates no permissions. Use it to document the actual implementation and evidence.
Has DN tested these wallet controls with real funds?
No. This article is a review of primary documentation plus original synthetic exercises. It reports no live-wallet tests, provider benchmark results or security certification.
Methodology, limitations and disclosure
DN reviewed seven primary documents and compared their stated enforcement boundaries. The worksheet, evidence labels and example record are DN proposals. Both numerical exercises are invented accounting scenarios; no product is credited with their expected results. The record is not an executable implementation or a substitute for an implementation-specific security review.
Living documentation can change. Network support, account types, plans and deployed versions must be checked for the route in use. No operational uptime, independent security assurance or eligibility for a particular reader was verified. Links are neutral official references; this article contains no affiliate signup links or paid product recommendation. Commercial relationships elsewhere do not determine these findings.
Change log: 19 October 2026 — initial documentation review, proposed worksheet and synthetic examples. Corrections: press@decentralised.news; identify the section and public evidence without sending credentials, signatures or private account records.
Primary sources
- Coinbase Developer Documentation: Spend Permissions — token units, onchain scope, period state and revocation.
- Privy: Policies and controls overview — method-specific evaluation and simulation order.
- Privy: Stateful policies — cumulative metrics, grouping and concurrency caveats.
- Privy: Conditional policies per signer — signer-specific override policies.
- Safe: Spending limits and the Proposer role — token allowance, recipient scope, resets and removal.
- ERC-20: Token Standard — final specification; created 19 November 2015.
- ERC-2612: Permit Extension for EIP-20 Signed Approvals — final specification; created 13 April 2020.
