Policy Gates - WalletSuite

Policy gates are how WalletSuite decides what an automated actor is allowed to sign. Every signing intent passes through a deterministic Policy Decision Point before the MPC cosigner produces its share. It evaluates the request against your rules and returns one outcome: allow or deny.

Signing runs through MPC threshold signing — no share, no signature. A policy deny means no signature is produced, so a denied intent cannot be signed by anyone. See Agents and Authority for how an automated actor proposes a transaction and why it can never authorize its own.

How rules work

Allowlist rules are your own rules for what may be signed. They are opt-in and deny-by-default: with no active rule, any signing intent on a chain you’re entitled to is admitted; once at least one rule is active, an intent is allowed only if it matches an active rule, and denied otherwise. An intent on a chain you’re not entitled to is always denied. You write rules against typed operations (below), not raw transaction bytes.

Rule Anatomy

A rule matches on the fields below. A field left unset matches any value for that field. All set fields must match for the rule to admit the operation.

Field	Required	What it matches
`chain`	yes	The chain the intent targets
`operationType`	yes	One of the typed operations classified from the calldata
`contractAddress`	For contract ops	The token or contract the operation targets. Absent on native transfers, required on every other operation type
`methodSelector`	For contract ops	The 4-byte selector as `0x` plus 8 hex chars. Absent on native transfers, required on every other operation type
`destination`	no	Pins the decoded recipient, spender, or operator. When set, only that destination matches
`amountCap`	no	Per-transaction cap in base units (wei or smallest token unit). An intent above the cap does not match
`expiresAt`	yes	Mandatory expiry. Authority is never open-ended. A rule stops matching once it expires

Match fields are normalized to lowercase before storage so they line up with the operation typing. amountCap is always base units. It is never a USD or decimal value.

Typed Operations

WalletSuite recognizes the following operations. Each rule targets exactly one.

Operation type	Method selector	Family
`native_transfer`	none	EVM native
`erc20_transfer`	`0xa9059cbb`	ERC-20
`erc20_approve`	`0x095ea7b3`	ERC-20
`erc20_transfer_from`	`0x23b872dd`	ERC-20
`erc721_transfer_from`	`0x23b872dd`	ERC-721
`erc721_safe_transfer_from`	`0x42842e0e` / `0xb88d4fde`	ERC-721
`erc721_approve`	`0x095ea7b3`	ERC-721
`erc721_set_approval_for_all`	`0xa22cb465`	ERC-721
`tron_native_transfer`	none	Tron native
`tron_trc20_transfer`	`0xa9059cbb`	Tron TRC-20

An operation outside this set cannot be typed and is denied once your allowlist is armed.

A Rule

A rule that permits USDC transfers on Ethereum to a single payout address, capped per transaction, with a mandatory expiry:

{
  "chain": "ethereum",
  "operationType": "erc20_transfer",
  "contractAddress": "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48",
  "methodSelector": "0xa9059cbb",
  "destination": "0x1111111111111111111111111111111111111111",
  "amountCap": "5000000000",
  "expiresAt": "2027-01-01T00:00:00Z"
}

The amountCap here is 5000000000 base units, which is 5000 USDC at 6 decimals. Any transfer to a different destination, above the cap, of a different token, or on a different chain does not match this rule. With this as the only active rule, everything else is denied. For creating, listing, and deactivating rules through the admin API, see Managing Policy Rules.

Off, Shadow, Enforce

The engine has three modes. They are the adoption motion. You watch the engine decide beside your rules before you let it enforce them.

Mode	What it does
`off`	Evaluation is disabled
`shadow`	Every intent is evaluated and every would-deny is recorded, but signing still proceeds. You see what the engine would deny without denying anything
`enforce`	A deny is a deny. The intent is recorded as denied and no signature is produced

The path is shadow first, then enforce. Arm your rules, run in shadow, read the would-deny records, confirm the engine denies exactly what you expect, then switch to enforce. Nothing you did not intend to deny gets denied by surprise.

What a Deny Does

When an intent is denied:

The intent is persisted as denied with the deny reason.
No signature is produced — the cosigner never releases its share for a denied intent.
The decision is recorded in the signing-intents ledger — see Policy Decisions for the record fields.

The decision plane decides. The cosigner enforces. A deny is not a warning that a compliant caller might ignore — it is a signature that is never produced.

Decision Provenance

Every evaluation, allow or deny, produces a fresh policyDecisionId and a stable reason — the seed of your execution evidence. See Policy Decisions → Decision reasons for the reason strings and the full decision record.

Administration

Rules are org-scoped and administered by an admin; every mutation is audited. See Managing Policy Rules for the request shapes and audit snapshots, and Structured Errors for how a policy denial surfaces to a caller.

​How rules work

​Rule Anatomy

​Typed Operations

​A Rule

​Off, Shadow, Enforce

​What a Deny Does

​Decision Provenance

​Administration

How rules work

Rule Anatomy

Typed Operations

A Rule

Off, Shadow, Enforce

What a Deny Does

Decision Provenance

Administration