Declarative rules are in early access and are not enabled by default. Talk to us if you’d like to participate.
The fallback
The fallback is what a layer does when none of its rules match a transaction. There are two choices:- Allow (the default). With no fallback, a transaction that matches nothing goes through.
- Deny. You add a final catch-all deny rule whose condition is always true, and a transaction that matches nothing is refused.
Deny style and allow style
The fallback decides how the rest of the layer has to be written.
Choose deny style when the wallet should generally work and you want to block specific things, such as an address, a large amount, or an unwanted token. Choose allow style when the wallet does one job and everything else should fail, such as paying USDC to a fixed list of vendors.
Why the two styles do not mix
The two styles are not compatible, because of how the engine decides. A deny rule can only refuse, and an allow rule can only rescue a transaction from the fallback. Neither one does anything outside its own condition.- A deny fallback under deny rules refuses everything. Take a wallet whose only rule is “deny anything above 5 ETH” and add a deny fallback. A 1 ETH transfer does not match the rule, so nothing permits it, and the fallback refuses it. The layer now refuses the very transfers the rule was written to let through.
- Allow rules without a deny fallback permit everything. Take a wallet whose only rule is “allow up to 100 USDC” and remove its deny fallback. A 10,000 USDC transfer does not match the rule, but an allow rule never forbids anything on its own, so the default fallback permits it.
How a layer decides
The order you write rules in does not matter. If any deny rule matches, the transaction is refused, because a matching deny always beats a matching allow. Otherwise, if any allow rule matches, the transaction is permitted. Otherwise, the fallback decides. Require approval is a third outcome. A matching approval rule holds a transaction the layer would otherwise permit until enough approvers sign off. It never permits anything by itself, so in allow style it only applies to transactions that an allow rule also permits.Transaction rules and operation rules
Every rule belongs to one of two phases.
An operation rule is a single comparison on the action, with no transaction details available. Of the wallet actions, only exporting the private key can require approval. A spend limit over time can only deny.
Approvals
An approval rule names who may approve, how many approvals are needed, and optionally a deadline, which defaults to 30 days. The person who made the request does not count toward the total. Approvers are identified by role:owner, admin, viewer, or any role your business account defines, where a custom role also counts as the built-in role it inherits. Dynamic does not check that a role exists, so naming a role nobody holds means the request can never be approved. Approval rules are available on the layers of business-account wallets.
Where each layer is written
Next steps
Rule anatomy
Rule fields, the fallback rule, and approval requirements.
Rule examples
A ready-made rule for each common case, and two whole layers.
Advanced conditions
Operators, lists, matching every item, and combined flows.
Policy layers
How the business account, wallet, and signer layers combine.