My prior research on programmable stablecoin compliance proposed a hybrid architecture: off-chain risk resolution feeding attestations into a programmable authorization boundary, with a portable audit artifact packaging the decision for later review. That architecture still holds together.
What it did not answer was the question it named at the end: whose rulebook the resolver is actually executing.
This note investigates that question across four production enforcement surfaces: Circle xReserve, Safe Guards, Alchemy Modular Account, and Base Spend Permissions.
These are not four identical products in one category. Circle xReserve is an issuer-side attestation system. Safe Guards, Alchemy Modular Account, and Base Spend Permissions are programmable authorization surfaces where a resolver can bind, not complete compliance resolver stacks by themselves. But across all four, the same downstream problem appears from different mechanisms: the governing policy is not exposed as a self-describing, replayable rulebook and history surface.
That gap shows up in three ways; the system does not expose the rulebook in a semantically legible form. It does not expose rule changes in a normalized way that downstream state queries can reliably interpret. And it does not reliably preserve a self-contained explanation of why a transaction was blocked.
Circle xReserve enforces compliance through an off-chain attestation service that operates outside the smart contract's visibility. When that service withholds attestation, the chain produces silence: no revert, no timeout, no error state. The rulebook governing whether a cross-chain transfer clears is not in the contract and not accessible from it.
In the attestation-withholding test, the deposit succeeded, the user's balance dropped, the contract retained custody, and no on-chain failure mode distinguished delayed attestation from attestation that would never arrive.
*The state across all ten blocks is below.
*
Safe Guards allow rule logic to live behind an address the Safe tracks but cannot read semantically. A UUPS proxy upgrade can replace the Guard implementation without triggering a GuardChanged event on the Safe itself. A downstream observer can detect proxy-level upgrade artifacts if they already know to inspect that surface, but Safe state does not expose a first-class record that the governing rule logic changed.
Block reasons can also accumulate in Guard-internal state that Safe core never surfaces. An observer querying Safe records after a failed transaction can see that execution stopped, but not why.
*Three tests make the shape of this gap concrete.
*
Alchemy's modular account makes enforcement entrypoint-dependent. Session key revocation blocks the standard prevalidation path while leaving an executeUserOp-style path open. In other words, "revoked" is not a globally coherent state unless every execution path shares the same enforcement boundary.
Historical permission state also does not survive on the view surface; it lives in event logs that require off-chain indexing to reconstruct. The protocol exposes pieces of policy state, but not a replayable policy history through view calls alone.
*Three tests make the shape of these gaps concrete.
*
Base Spend Permissions has the strongest on-chain enforcement of the four, but permission validity and execution authority still run as separate state machines. A permission can remain currentlyValid=true while execution fails later at _execute because wallet authority has been removed.
Expired permissions also accumulate indefinitely in approved=true, revoked=false, currentlyValid=false, a state that a naive observer checking only the first two fields can misread as active. The issue here is not invisibility in the same form as Circle, It is that the authoritative policy state is split across fields and execution layers rather than exposed as one self-explaining surface.
The common pattern is not that every system fails in the same way, It is that none of them exposes a first-class, semantically legible, replayable representation of the policy actually governing execution at the moment it matters. In Circle, the rulebook is off-chain and silent on failure. In Safe, the pointer is visible but the semantics behind it can change or remain opaque. In Alchemy, enforcement coherence depends on entrypoint. In Base, the authoritative state is fragmented across validation and execution layers.
That makes the original architectural implication more precise, A programmable authorization boundary can enforce whatever a resolver attests or whatever policy state the wallet checks. But if the resolver's own governance and rule history are not legible at the protocol layer, the attestation carries opaque sovereign risk upstream. A trusted resolver feeding a wallet boundary is only as trustworthy as whoever sets its rulebook and however that rulebook changes over time.
The missing surface is not just technical metadata; It is what would let a downstream wallet, auditor, counterparty, or AI agent answer basic questions after the fact: What exact policy version governed this transaction? What changed between approval and execution? Why was this payment blocked? Could the decision be replayed from protocol-visible state alone? Across the four systems examined here, those questions remain only partially answerable or not answerable at all.
The architecture from the earlier piece still moves compliance closer to execution. What it does not yet do is make the compliance surface itself auditable.