Signed permits: zero allowance does not prove zero authorization
A zero token allowance describes current contract state. It does not establish that nobody holds a valid, unsubmitted signature capable of changing that state. For ERC-2612 research, separate the allowance already recorded onchain from known signed permits and the wider set of signatures the public chain cannot enumerate.
The deliverable is an authorization-evidence ledger, not a transaction instruction. It records what is currently effective, which supplied signatures satisfy stated conditions and which potential authorizations remain unobservable. It should never invent a precise amount for an unknown signature population.
Identify the permit implementation first
ERC-2612, Specification, describes a signed permit that sets an owner’s allowance for a spender when its signature, domain, nonce and deadline conditions hold. A successful call increments the owner’s permit nonce. Its Rationale also explains that a relayer can receive a signature and choose whether to submit it.
Use the standard’s actual interface and semantics for the token under review. The Backwards Compatibility section describes other permit designs with different fields or meanings. A function named permit is not enough to establish compliance with this particular model.
Record network, token contract, owner and spender as separate identities. Preserve raw unit scale, applicable implementation and observation block. The permit nonce belongs to the token’s authorization mechanism; it is not necessarily the owner’s transaction nonce or another application’s nonce.
Establish three evidence populations
The first population is recorded allowance state. Query the relevant owner-token-spender relationship at the selected block and save the response. Approval events can help locate changes, but the current state is the quantity being described.
The second population is known signatures supplied for the research task. A private evidence packet can retain their exact typed fields and bytes, while the shared memo uses sanitized identifiers. Do not publish a usable signature merely to illustrate the worksheet.
The third population is unknown signatures that might exist offchain. An unused permit need not create a transaction or event. No complete list follows from an empty approval history, a zero allowance query or the absence of a familiar wallet-interface warning.
Write the population label beside every count. “Two supplied signatures reviewed” is supportable if two were inspected. “Only two signatures exist” needs a completeness argument that a normal public-chain query cannot provide.
A hypothetical zero-allowance observation
Assume fictional token T follows the stated ERC-2612 behavior. At observation H, owner A’s allowance for spender B is zero, and T’s permit nonce for A is 4. The observed block timestamp is 9000. A supplied signature S authorizes 100 raw token units to B, uses nonce 4 and has deadline 10000. Domain and signature verification are stipulated to pass for this example.
The relevant predicates are nonce-current = nonce-signed and timestamp ≤ deadline, together with the signature and domain checks. At H, 4 = 4 and 9000 ≤ 10000. The zero recorded allowance and a known currently eligible permit can coexist.
| Evidence layer | At H | Supported conclusion |
|---|---|---|
| Recorded allowance A→B | 0 | No allowance is recorded for that relationship now |
| Current permit nonce | 4 | S’s nonce matches this observation |
| Time condition | 9000 ≤ 10000 | S has not passed its submission deadline |
| Supplied signature | Value 100, matching domain | Eligible under the stipulated remaining checks |
| All other offchain signatures | Unknown | No complete potential-authorization total is available |
The permit’s 100 is an authorization value, not a transfer already completed. If the owner currently holds 40 units, that does not mean 100 units have left the wallet. Keep balances and executed transfers in their own records rather than treating signed capacity as realized movement.
Compare alternative states without rewriting history
Consider two alternative later situations, each compared with the original H. In one, the permit nonce has advanced to 5. S still carries 4, so it no longer matches. In the other, the nonce remains 4 but the block timestamp is 10001, so the deadline condition fails. These are separate scenarios, not a claim that a nonce normally decreases from 5 back to 4.
At timestamp exactly 10000, the stated deadline test is still satisfied. A research tool using a strict less-than comparison instead of less-than-or-equal would incorrectly reject the boundary case. Preserve the block timestamp, not the analyst’s local wall clock, when evaluating the historical condition.
If a source says S is invalid but does not provide a reason, do not collapse nonce mismatch, expired deadline, wrong domain and bad signature into one unexplained false flag. Those causes imply different changes to the evidence packet and different review triggers.
Two signatures do not necessarily add together
Suppose a second supplied permit S2 names another spender C and value 200, but also uses A’s nonce 4 in the same token. Under the stipulated model, a successful permit using that nonce advances the shared owner nonce. The other nonce-4 signature then fails its nonce check.
Adding 100 and 200 into 300 units of simultaneously effective new allowances would ignore that relationship. Preserve the alternative paths. Their effects also depend on the preexisting allowances they replace, rather than always adding to existing permission amounts.
If supplied signatures use different future nonces, analyze their possible processing order under the implementation instead of assuming the same mutual exclusion. Known signatures are a bounded input collection. They still cannot reveal every signature that another party might possess.
Different boundary: submission expiry is not allowance expiry
Assume S is successfully submitted at timestamp 9500, setting the allowance to 100 and moving the permit nonce to 5. Under the stated standard behavior, deadline 10000 limits acceptance of the permit; it does not automatically reset that resulting allowance to zero at timestamp 10001.
The later allowance needs a state query and the token’s actual rules. Treating the permit deadline as the spending permission’s automatic expiry would understate persistent authorization. A token implementing a different expiring-approval design requires different evidence, not the same worksheet with a renamed field.
Another boundary concerns an ordinary approval set to zero. If the implementation’s approve operation does not change the permit nonce, a zero allowance observation after that operation does not alone invalidate a previously signed matching permit. Verify the nonce transition instead of inferring it from the approval amount.
Make the verification packet reproducible
For each supplied signature, store a sanitized identifier connected privately to its exact bytes, typed message, domain, owner, spender, value, nonce and deadline. Save the digest reconstruction method and the token’s historical domain behavior. A readable wallet prompt is a useful lead but cannot replace those fields.
Distinguish signature recovery from complete permit eligibility. A correctly recovered signer can still be paired with a stale nonce or the wrong chain-contract domain. Conversely, a call failure caused by unavailable historical state is not evidence that the signature cryptographically fails.
When evidence conflicts, preserve both observations with their blocks. A current nonce of 5 and an older verified nonce of 4 may describe an ordinary transition. Only inconsistent claims for the same object and state create a direct conflict requiring resolution.
Keep the scope of an invalidation finding narrow
An observed nonce of 5 can rule out the supplied nonce-4 permit under the stipulated implementation. It cannot rule out a separate nonce-5 permit that the researcher has never received. Likewise, an expired deadline rules out that message’s acceptance after its boundary, not every other signed message. Record the exact object invalidated by each observation.
When comparing two reviewers’ inventories, distinguish a duplicated copy of S from another signature authorizing the same fields. The relevant signed-message identity includes its domain and typed content, while byte identity records the actual evidence file. Counting files is not counting independent permissions. Ask each source to describe its inventory scope and omissions rather than combining two incomplete lists into an apparently exhaustive register.
An actionable authorization ledger
| Action | Save | Limit of the conclusion |
|---|---|---|
| Confirm implementation | Contract, code version and permit semantics | Name matching does not establish compatibility |
| Read current state | Allowance, permit nonce and block | Describes the selected state only |
| Inspect supplied permits | Exact private bytes and typed fields | Covers supplied signatures, not every possible signature |
| Evaluate conditions | Domain, signature, nonce and deadline results | Eligibility is not completed transfer |
| Reconcile changes | Successful permit and subsequent state | Submission deadline is not automatic allowance expiry |
| Report unknown scope | Missing signature inventory and source coverage | No invented total for unobserved authorizations |
Reopen the ledger after a nonce change, deadline boundary, implementation change, newly supplied signature or changed domain evidence. Release current recorded permissions and the status of known permits separately. The strongest honest conclusion may be that no allowance is recorded now while the existence and amount of other unsubmitted authorizations remain unknown.
FAQ
Can public-chain data enumerate all unsubmitted permits?
No. An unused signed message can remain offchain. Public state can test conditions for a supplied signature but does not list every signature in existence.
Does the permit deadline erase an allowance created before that deadline?
Not under the standard behavior described here. It limits permit acceptance. Check the actual token and subsequent allowance state separately.