PolicyRegistry composite policies

​

When to use a composite policy

• UNION (OR). Authorize an account if any child policy authorizes it. Example: allow transfers from either a KYC allowlist or a market-maker allowlist.
• INTERSECT (AND). Authorize an account only if every child policy authorizes it. Example: require an account to pass a jurisdiction allowlist and not appear on a sanctions blocklist.

​

Policy types

​

Bounds

​

Functions

​

Events

​

Errors

​

Revert precedence

1. ZeroAddress — admin == address(0).
2. IncompatiblePolicyType — policyType is not UNION or INTERSECT.
3. ChildPoliciesOutsideOfRange — childPolicyIds.length is outside [2, 4].
4. PolicyNotFound — any listed child does not exist (checked in one pass over the whole set).
5. InvalidChildPolicy — any listed child is a composite or a built-in sentinel (second pass).

1. PolicyNotFound — policyId does not exist.
2. IncompatiblePolicyType — policyId is a simple policy, not a composite.
3. Unauthorized — caller is not the current admin. A renounced composite (admin address(0)) can never be updated.
4. ChildPoliciesOutsideOfRange — new child count is outside [2, 4].
5. PolicyNotFound — any new child does not exist.
6. InvalidChildPolicy — any new child is a composite or a built-in sentinel.

​

Evaluation

​

Example

// Two simple policies already exist on-chain.
uint64 kycAllowlist = 0x0100000000000042;      // ALLOWLIST
uint64 sanctionsBlocklist = 0x0000000000000043; // BLOCKLIST

// INTERSECT: only accounts that are on the KYC allowlist AND not on the
// sanctions blocklist are authorized.
uint64[] memory children = new uint64[](2);
children[0] = kycAllowlist;
children[1] = sanctionsBlocklist;

uint64 compositeId = policyRegistry.createCompositePolicy(
    adminAddress,
    uint8(PolicyType.INTERSECT),
    children
);

// Attach to a B20 policy scope. Validate the ID first, exactly as for a simple policy.
require(policyRegistry.policyExists(compositeId), "policy missing");
b20Token.updatePolicy(TRANSFER_SENDER_POLICY, compositeId);

// Later: replace the child set in full. Omitted children stop governing the composite.
uint64[] memory newChildren = new uint64[](3);
newChildren[0] = kycAllowlist;
newChildren[1] = sanctionsBlocklist;
newChildren[2] = jurisdictionAllowlist;
policyRegistry.updateComposite(compositeId, newChildren);

​

Guarantees and edge cases

• No nested composites. createCompositePolicy and updateComposite revert InvalidChildPolicy(childPolicyId) for any child whose type is UNION or INTERSECT.
• No built-in sentinels as children. ALWAYS_ALLOW and ALWAYS_BLOCK also revert with InvalidChildPolicy. To fold always-allow / always-block behavior into a composite, create a real ALLOWLIST or BLOCKLIST policy that reproduces the effect and reference it instead.
• Duplicates are permitted. The registry neither sorts nor de-duplicates the stored child list. Duplicates cost extra per-call evaluation but do not change the result — UNION and INTERSECT are idempotent under duplicates.
• No path to an under-sized composite. Every updateComposite call re-enforces [2, 4], so a composite can never be shrunk below two children.
• Renouncing a child admin does not break the parent. renounceAdmin on a child clears the child’s admin and freezes its future membership changes. The child still exists, isAuthorized on it still resolves, and the composite keeps evaluating it.
• No composite-specific activation flag. createCompositePolicy and updateComposite are gated by the same ActivationRegistry flag as createPolicy, updateAllowlist, and the rest. compositePolicyChildIds, the MIN / MAX bounds, and isAuthorized on a composite ID are always callable.