Limits, stated before they are found
- Clause 3.5 may admit at most sixteen actions to a window, and the registry refuses a mandate asking for more. The window is exact because the guard sums a ledger of the actions inside it, and the ledger has to be bounded or an instrument could be signed whose own enforcement runs out of gas. A firm wanting a higher rate needs a shorter window, or delegation.
- Clause 2.5 bounds price as a rate the owner signs, not as a market price. It has no oracle and cannot know what the pair was worth this minute: a floor set generously is a floor that permits a bad fill, and setting it is the owner’s judgement. It is expressed in basis points and carried in a
uint16, which suits pairs whose normalised rate lies roughly between 0.0001 and 6.5; a pair whose units differ by orders of magnitude needs a different encoding. - The registry’s own documentation comment still says recovery is
ecrecoveronly. It is not:SignatureCheckertakes the EIP-1271 path for an owner that has code, but the comment is part of the source that is verified on Sourcify, and correcting it would change the metadata hash the verification is anchored to. It is corrected at the next deployment and not before. - An instrument’s detail needs proof of control (a signature, not a password) and what a firm publishes is its own choice. But the officer path reads the spine rather than the chain, so an officer named on chain who has never filed a decision here cannot yet be recognised by that route.
- A read token is a bearer token for as long as it lives. It is set as an
httpOnlycookie, out of reach of anything running on the page, and the console keeps only the address it belongs to, but anything holding the cookie reads what its owner reads until it expires. - Exposure is bounded per instrument, never across them. The guard bounds one mandate and every mandate above it in its delegation chain; two instruments an owner signed separately carry two windows and nothing sums them. Measured rather than asserted: on vouch.finance’s
disbursement-integritykit, six beneficiaries converging on one flagged merchant is a pattern that exists only across instruments, and it is scored by the kit rather than by the guard. - Identity is settled before AMW is reached. AMW is asked its question after an owner has signed a mandate naming an agent; whether two beneficiaries are the same person is a KYC matter, answered at enrolment by the layer that admits them. The same kit’s three synthetic-identity cases belong to that layer.
- The sandbox is unauthenticated and bounded rather than free.
/api/previewand/api/stresstake no key and each does real work on a simulated chain through one queue, so one caller may run twelve searches and a hundred and twenty previews in ten minutes, and one search at a time across the deployment. A refusal is a 429 with aretry-after, not a place in a queue. - Single chain, Hedera EVM testnet, synthetic data.
Every limit above that is a behaviour carries a test that fails the day it stops being
true: packages/contracts/test/Invariants.test.ts for the contract ones.
Two are not behaviours: the encoding range of clause 2.5's floor, and the stale comment,
which is a fact about a document rather than about what the contract does.