Stablecoins made execution programmable faster than compliance systems made authorization legible. That asymmetry did not matter much when payment authority stayed inside custodial relationships and institutional rails, but it matters a lot once the executable path assembles itself from prompts, tool calls, delegated keys, sponsor logic, and whatever the wallet's validation layer will accept.
Not every stablecoin payment is the kind of payment this piece is about. Where a custodian, PSP, or canonical issuer remains in the transfer path, legacy compliance edges still do most of the real work. This piece is about the slice where that is no longer true: flows where authorization has become programmable, where execution assembles after the institutional approval event, and where the decisive control point has shifted away from the old regulated edge.
That shift creates a split worth naming precisely. Institutional-path flows, including custodial exchange withdrawals, PSP-mediated merchant rails, and canonical issuer-controlled transfers on supported chains, still bind compliance mainly at the institutional edge, the custodian sees the customer, the PSP governs the rail, and the issuer sits inside the transfer path with freeze, burn, and redemption authority operating at contract level. On those paths, issuer control is not just a legal backstop, it often remains inside the real-time execution path.
Programmable-account flows work differently, and the four-path split below is the cleanest way to see where the boundary actually falls.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Flow-type taxonomy — Compliance surface by flow type</title>
<style>
*, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }
:root {
--color-background-primary: #ffffff;
--color-background-secondary: #f5f5f4;
--color-text-primary: #111110;
--color-text-secondary: #6b6b68;
--color-text-tertiary: #9b9b97;
--color-border-primary: rgba(0,0,0,0.4);
--color-border-secondary: rgba(0,0,0,0.3);
--color-border-tertiary: rgba(0,0,0,0.15);
--font-sans: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif;
--font-mono: "SFMono-Regular", Consolas, "Liberation Mono", Menlo, monospace;
--border-radius-md: 8px;
--border-radius-lg: 12px;
}
@media (prefers-color-scheme: dark) {
:root {
--color-background-primary: #1a1a18;
--color-background-secondary: #242422;
--color-text-primary: #e8e8e4;
--color-text-secondary: #9b9b97;
--color-text-tertiary: #6b6b68;
--color-border-primary: rgba(255,255,255,0.4);
--color-border-secondary: rgba(255,255,255,0.3);
--color-border-tertiary: rgba(255,255,255,0.15);
}
}
body {
background: var(--color-background-secondary);
font-family: var(--font-sans);
display: flex;
align-items: center;
justify-content: center;
min-height: 100vh;
padding: 32px 16px;
}
.ftax {
background: var(--color-background-primary);
border: 1px solid var(--color-border-secondary);
border-radius: var(--border-radius-lg);
padding: 22px 24px;
width: 100%;
max-width: 680px;
}
.ftax-top {
display: flex;
justify-content: space-between;
align-items: center;
margin-bottom: 20px;
}
.meta {
font-size: 10px;
letter-spacing: .08em;
color: var(--color-text-tertiary);
font-family: var(--font-mono);
}
.fgrid {
display: grid;
grid-template-columns: 1fr 1px 1fr;
column-gap: 24px;
}
.fsep {
background: var(--color-border-tertiary);
}
.zone-hd {
font-size: 13px;
font-weight: 600;
color: var(--color-text-primary);
margin: 0 0 2px;
}
.zone-sub {
font-size: 10px;
font-family: var(--font-mono);
color: var(--color-text-tertiary);
margin: 0 0 14px;
}
.fcard {
border: 1px solid var(--color-text-primary);
border-radius: var(--border-radius-md);
padding: 14px;
margin-bottom: 10px;
cursor: pointer;
transition: background .15s;
}
.fcard:last-child {
margin-bottom: 0;
}
.fcard:hover,
.fcard.open {
background: var(--color-background-secondary);
}
.fcard-head {
display: flex;
justify-content: space-between;
align-items: flex-start;
gap: 8px;
margin-bottom: 10px;
}
.ftag {
display: inline-block;
font-size: 10px;
font-family: var(--font-mono);
padding: 2px 8px;
border-radius: 99px;
flex-shrink: 0;
line-height: 1.6;
}
.ftag-n {
border: 1px solid var(--color-border-secondary);
color: var(--color-text-secondary);
}
.ftag-y {
background: var(--color-text-primary);
color: var(--color-background-primary);
}
.fcard-title {
font-size: 13px;
font-weight: 600;
color: var(--color-text-primary);
margin: 0 0 3px;
}
.fcard-surf {
font-size: 10px;
font-family: var(--font-mono);
color: var(--color-text-secondary);
margin: 0;
line-height: 1.5;
}
.fcard-detail {
font-size: 12px;
color: var(--color-text-secondary);
line-height: 1.6;
max-height: 0;
overflow: hidden;
transition: max-height .3s ease, margin-top .2s ease;
margin-top: 0;
}
.fcard:hover .fcard-detail,
.fcard.open .fcard-detail {
max-height: 160px;
margin-top: 10px;
}
.ftax-foot {
text-align: center;
margin-top: 18px;
padding-top: 14px;
border-top: 1px solid var(--color-border-tertiary);
font-size: 10px;
letter-spacing: .07em;
color: var(--color-text-tertiary);
font-family: var(--font-mono);
}
</style>
</head>
<body>
<div class="ftax">
<div class="ftax-top">
<span class="meta">COMPLIANCE SURFACE BY FLOW TYPE</span>
<span class="meta">HOVER OR TAP TO EXPLORE</span>
</div>
<div class="fgrid">
<div>
<p class="zone-hd">Legacy compliance dominates</p>
<p class="zone-sub">Thesis does not apply in these paths</p>
<div class="fcard">
<div class="fcard-head">
<svg width="28" height="28" viewBox="0 0 28 28" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<circle cx="14" cy="9" r="4"/>
<path d="M6 24c0-4.4 3.6-8 8-8s8 3.6 8 8"/>
</svg>
<span class="ftag ftag-n">not here</span>
</div>
<p class="fcard-title">Institutional / custodial</p>
<p class="fcard-surf">exchange · PSP · custodian stack</p>
<div class="fcard-detail">KYC, transaction monitoring, travel rule, and sanctions screening attach at the institutional edge. The PSP or custodian governs execution directly. No gap exists for a programmable authorization boundary to fill.</div>
</div>
<div class="fcard">
<div class="fcard-head">
<svg width="28" height="28" viewBox="0 0 28 28" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<path d="M14 4l8 3.5V13c0 4.8-8 9-8 9s-8-4.2-8-9V7.5L14 4z"/>
<path d="M10.5 13.5l2.5 2.5 5-5"/>
</svg>
<span class="ftag ftag-n">not here</span>
</div>
<p class="fcard-title">Canonical issuer-gated</p>
<p class="fcard-surf">issuer contract admin · redemption gate</p>
<div class="fcard-detail">On canonical USDC, USDT, PYUSD, and RLUSD paths the issuer is the primary real-time control surface. Freeze, blacklist, burn, and redemption authority operate at contract level. Control degrades only once value moves into wrappers or non-canonical bridge representations.</div>
</div>
</div>
<div class="fsep"></div>
<div>
<p class="zone-hd">Hybrid architecture required</p>
<p class="zone-sub">Thesis applies in these paths</p>
<div class="fcard">
<div class="fcard-head">
<svg width="28" height="28" viewBox="0 0 28 28" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<rect x="3" y="5" width="22" height="18" rx="2"/>
<path d="M3 11h22"/>
<path d="M7 16l2 2-2 2"/>
<path d="M12 16h9"/>
</svg>
<span class="ftag ftag-y">thesis applies</span>
</div>
<p class="fcard-title">Programmable smart-account</p>
<p class="fcard-surf">validateUserOp · authorization boundary</p>
<div class="fcard-detail">ERC-4337 flows, delegated spend permissions, sponsored execution. The validateUserOp surface is the narrowest pre-settlement gate. Wallet validation alone is insufficient: route truth, counterparty risk, and sanctions freshness all require off-chain resolution feeding into it.</div>
</div>
<div class="fcard">
<div class="fcard-head">
<svg width="28" height="28" viewBox="0 0 28 28" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round">
<rect x="3" y="7" width="22" height="4" rx="2"/>
<rect x="3" y="13" width="22" height="4" rx="2"/>
<rect x="3" y="19" width="22" height="4" rx="2"/>
<circle cx="8" cy="9" r="1.2" fill="currentColor" stroke="none"/>
<circle cx="8" cy="15" r="1.2" fill="currentColor" stroke="none"/>
<circle cx="8" cy="21" r="1.2" fill="currentColor" stroke="none"/>
</svg>
<span class="ftag ftag-y">thesis applies</span>
</div>
<p class="fcard-title">Detached / wrapped cross-domain</p>
<p class="fcard-surf">degraded issuer · partial wallet · audit artifact</p>
<div class="fcard-detail">Third-party USDC wrappers, USDT through non-Tether bridge infrastructure, cross-domain routing through chain abstraction middleware. Issuer controls do not follow the asset across non-canonical representations. The portable audit artifact is often the only post-execution reconstruction mechanism available.</div>
</div>
</div>
</div>
<div class="ftax-foot">LEGACY EDGES OPERATIVE ON LEFT · HYBRID POLICY-AND-EVIDENCE LAYER REQUIRED ON RIGHT</div>
</div>
<script>
document.querySelectorAll('.fcard').forEach(c => c.addEventListener('click', () => c.classList.toggle('open')));
</script>
</body>
</html>Once execution moves into self-custodial smart accounts, delegated spend permissions, sponsored execution paths, or cross-domain routing that detaches from issuer contract control, the institutional edge becomes an outer ring rather than the decisive gate.
Third-party USDC wrappers do not inherit Circle's admin surface, USDT flowing through non-Tether bridge infrastructure sits outside Tether's direct contract control, and USDT0's lock-and-mint architecture preserves canonical USDT as the underlying reserve but introduces a separate LayerZero-mediated trust surface that is not identical to native Tether issuance on every supported chain.
The further execution moves from issuer-controlled contracts, the more the issuer becomes a recovery or legal counterparty rather than the actor inside the execution path making the call. For these flows, the strongest minimum compliance architecture is a hybrid policy-and-evidence layer with a "programmable authorization boundary" at its enforcement core, and that is the surviving thesis.
The Mechanism Shift
Legacy control stacks were built around a specific assumption: a legally legible institution touches the transfer at the moment when payment intent becomes settlement. The institution could identify the customer, attach originator and beneficiary data, screen counterparties, and keep records. FATF, FinCEN, OFAC, and the EU transfer-rule stack all attach obligations where regulated intermediaries perform covered services.
The assumption holds when the institution stays in path. When payment authority moves into an agent loop, it starts to break at a specific seam, the original approval event may happen at an institutional edge, but what actually settles value is a wallet operation assembled afterward from prompts, tool calls, delegated permissions, sponsor logic, route selection, and whatever the validation layer will still accept. Authorization and execution decouple.
Compliance cannot just govern the account relationship or the institutional approval event anymore. The relevant object has shifted: it has to govern the executable authorization path.
Where Programmable Flows Break the Old Model
Recipient substitution shows exactly how that gap opens, a beneficiary can be screened correctly at an institutional edge. The actual destination address can still change between the screened record and the wallet operation, through address book poisoning or clipboard replacement in the agent context.
Legacy controls cleared the beneficiary record, execution bound to a different address.
Route mutation works similarly, a payment request can look simple at the interface layer and resolve into a bridge hop, an L2 detour, a sponsored execution sequence, or a relayed path that emerged after the approval event, not before it. Approval attached to the abstract intent, execution attached to a resolved route that no compliance check ever saw. Chain abstraction middleware is where that gap opens.
Delegated authority creates a different kind of separation: KYC binds to the account holder, the operative actor during execution is the agent, and what the institution sees at settlement tells it nothing about whether machine-delegated authority stayed within the scope that was actually intended.
Evidence fragments across all of this: once decisive facts split across prompts, tool invocations, route resolution, sponsor decisions, and wallet validation steps, ordinary institutional books and records no longer reconstruct the payment cleanly. The compliance problem becomes partly an enforcement problem and partly an evidence problem. The sequence below maps exactly where that fragmentation happens.
<style>
.seq{background:var(--color-background-primary);border:1px solid var(--color-border-secondary);border-radius:12px;padding:20px 24px;font-family:var(--font-sans)}
.seq-top{display:flex;justify-content:space-between;margin-bottom:20px}
.smeta{font-size:10px;letter-spacing:.08em;color:var(--color-text-tertiary);font-family:var(--font-mono)}
.tl{display:flex;align-items:flex-start;position:relative;margin-bottom:16px}
.tl::before{content:'';position:absolute;top:14px;left:6%;right:6%;height:1px;background:var(--color-border-secondary);z-index:1}
.st{flex:1;display:flex;flex-direction:column;align-items:center;position:relative;z-index:2;cursor:pointer}
.sn{width:28px;height:28px;border-radius:50%;border:1px solid var(--color-text-primary);display:flex;align-items:center;justify-content:center;font-size:10px;font-family:var(--font-mono);color:var(--color-text-primary);background:var(--color-background-primary);transition:all .15s}
.st.active .sn,.st:hover .sn{background:var(--color-text-primary);color:var(--color-background-primary)}
.st.risk .sn{border-color:var(--color-text-warning);color:var(--color-text-warning)}
.st.risk.active .sn,.st.risk:hover .sn{background:var(--color-text-warning);color:var(--color-background-primary);border-color:var(--color-text-warning)}
.st.gate .sn{border-color:var(--color-text-success);color:var(--color-text-success)}
.st.gate.active .sn,.st.gate:hover .sn{background:var(--color-text-success);color:var(--color-background-primary);border-color:var(--color-text-success)}
.sl{font-size:9px;font-family:var(--font-mono);color:var(--color-text-secondary);margin-top:5px;text-align:center;line-height:1.3;max-width:64px}
.sp{font-size:9px;font-family:var(--font-mono);padding:1px 5px;border-radius:99px;margin-top:3px;line-height:1.6}
.sp-n{background:var(--color-background-secondary);color:var(--color-text-tertiary)}
.sp-r{background:var(--color-background-warning);color:var(--color-text-warning)}
.sp-g{background:var(--color-background-success);color:var(--color-text-success)}
.dp{border:0.5px solid var(--color-border-tertiary);border-radius:8px;padding:14px 16px;min-height:82px}
.dp-s{font-size:10px;font-family:var(--font-mono);color:var(--color-text-tertiary);margin:0 0 5px}
.dp-t{font-size:13px;color:var(--color-text-secondary);margin:0;line-height:1.65}
.leg{display:flex;gap:16px;margin-top:14px;padding-top:12px;border-top:0.5px solid var(--color-border-tertiary);flex-wrap:wrap}
.leg-item{display:flex;align-items:center;gap:5px;font-size:10px;font-family:var(--font-mono);color:var(--color-text-tertiary)}
.leg-dot{width:8px;height:8px;border-radius:50%;flex-shrink:0}
</style>
<div class="seq">
<div class="seq-top">
<span class="smeta">AUTHORIZATION TO SETTLEMENT</span>
<span class="smeta">TAP A STAGE</span>
</div>
<div class="tl">
<div class="st active" onclick="sel(this,0)">
<div class="sn">1</div>
<span class="sl">Approval</span>
<span class="sp sp-n">legacy edge</span>
</div>
<div class="st risk" onclick="sel(this,1)">
<div class="sn">2</div>
<span class="sl">Agent runtime</span>
<span class="sp sp-r">mutation risk</span>
</div>
<div class="st risk" onclick="sel(this,2)">
<div class="sn">3</div>
<span class="sl">Tool call</span>
<span class="sp sp-r">mutation risk</span>
</div>
<div class="st risk" onclick="sel(this,3)">
<div class="sn">4</div>
<span class="sl">Route resolution</span>
<span class="sp sp-r">mutation risk</span>
</div>
<div class="st risk" onclick="sel(this,4)">
<div class="sn">5</div>
<span class="sl">Sponsor selection</span>
<span class="sp sp-r">mutation risk</span>
</div>
<div class="st gate" onclick="sel(this,5)">
<div class="sn">6</div>
<span class="sl">Wallet validation</span>
<span class="sp sp-g">new gate</span>
</div>
<div class="st" onclick="sel(this,6)">
<div class="sn">7</div>
<span class="sl">Settlement</span>
<span class="sp sp-n">post-exec</span>
</div>
</div>
<div class="dp" id="dp">
<p class="dp-s">Stage 1 — approval</p>
<p class="dp-t">The institutional approval event. Legacy controls attach here: KYC, sanctions screening, spend scope, and beneficiary check. This is where the old perimeter binds most cleanly. What the institution approves and what the wallet eventually executes can still diverge.</p>
</div>
<div class="leg">
<div class="leg-item"><span class="leg-dot" style="background:var(--color-border-primary)"></span>Legacy control point</div>
<div class="leg-item"><span class="leg-dot" style="background:var(--color-text-warning)"></span>Silent mutation risk</div>
<div class="leg-item"><span class="leg-dot" style="background:var(--color-text-success)"></span>New programmable gate</div>
</div>
</div>
<script>
const D=[
{s:'Stage 1 — approval',t:'The institutional approval event. Legacy controls attach here: KYC, sanctions screening, spend scope, and beneficiary check. This is where the old perimeter binds most cleanly. What the institution approves and what the wallet eventually executes can still diverge.'},
{s:'Stage 2 — agent runtime',t:'Authorization can mutate silently here. Prompt injection can redirect tool-selection logic or override policy parameters. The agent assembles the payment object from context that legacy compliance stacks cannot see.'},
{s:'Stage 3 — tool call',t:'Malicious invoice injection and address substitution occur at this stage. A forged invoice or poisoned address book entry replaces the approved beneficiary. Legacy controls cleared the beneficiary record. Execution binds to a different address.'},
{s:'Stage 4 — route resolution',t:'Chain abstraction middleware collapses compliance-relevant facts behind orchestration logic. A simple payment instruction resolves into a bridge hop, L2 detour, or relayed path that was never explicitly approved. The economically real path materializes here, not at the original approval event.'},
{s:'Stage 5 — sponsor selection',t:'A paymaster can sponsor gas for execution paths the principal wallet would not have funded directly. Sponsorship creates a second execution-enabling actor outside the original approval scope. Legacy controls do not treat gas sponsorship as a compliance-relevant decision point.'},
{s:'Stage 6 — wallet validation',t:'The narrowest pre-settlement gate in programmable-account flows. Recipient binding, route manifest, delegation scope, sponsor conditions, and policy version can all be enforced here before execution releases. This is the proposed enforcement core of the hybrid architecture. Wallet validation alone is insufficient: off-chain risk resolution must feed into it.'},
{s:'Stage 7 — settlement',t:'Finality. Once settlement completes, interdiction is no longer available through the execution path. Post-execution sanctions discovery produces evidence but not prevention. Issuer controls can assist with recall on canonical asset paths. The portable audit artifact is the main remaining instrument.'}
];
function sel(el,i){
document.querySelectorAll('.st').forEach(s=>s.classList.remove('active'));
el.classList.add('active');
const d=D[i];
document.getElementById('dp').innerHTML='<p class="dp-s">'+d.s+'</p><p class="dp-t">'+d.t+'</p>';
}
</script>The Programmable Authorization Boundary
In ERC-4337-style smart-account flows, the narrowest deterministic gate before settlement is the programmable authorization boundary. The validateUserOp and validatePaymasterUserOp surfaces are where that boundary lives, and what gets verified there can be much richer than signature validity, recipient binding, route manifest, delegation scope, sponsor conditions, risk freshness, and policy version can all be checked before the wallet releases execution.
The bottleneck follows structurally: Whoever defines what the wallet must verify before it executes controls the narrowest real-time gate in programmable-flow systems, and that is not a rhetorical claim about wallets being important. It is the consequence of where finality sits in ERC-4337 execution: after the agent and tool layers have assembled a candidate payment, before settlement, and at the exact object that is about to move value.
This argument does not travel to every flow type, EOA flows have no programmable validation surface to enforce against. MPC and custodial architectures push policy into signer infrastructure, not user-side wallet code. PSP-mediated merchant rails leave the PSP's risk engine as the main pre-execution gate. The boundary only exists where a programmable smart account is actually in the path, and the diagram below shows exactly where it sits inside the ERC-4337 execution sequence.
<style>
.erc{background:var(--color-background-primary);border:1px solid var(--color-border-secondary);border-radius:12px;padding:20px 24px;font-family:var(--font-sans)}
.erc-top{display:flex;justify-content:space-between;margin-bottom:20px}
.emeta{font-size:10px;letter-spacing:.08em;color:var(--color-text-tertiary);font-family:var(--font-mono)}
.etl{display:flex;align-items:flex-start;position:relative;margin-bottom:16px}
.etl::before{content:'';position:absolute;top:14px;left:5%;right:5%;height:1px;background:var(--color-border-secondary);z-index:1}
.est{flex:1;display:flex;flex-direction:column;align-items:center;position:relative;z-index:2;cursor:pointer}
.en{width:28px;height:28px;border-radius:50%;border:1px solid var(--color-text-primary);display:flex;align-items:center;justify-content:center;font-size:10px;font-family:var(--font-mono);color:var(--color-text-primary);background:var(--color-background-primary);transition:all .15s}
.est.active .en,.est:hover .en{background:var(--color-text-primary);color:var(--color-background-primary)}
.est.enforce .en{border-color:var(--color-text-success);color:var(--color-text-success)}
.est.enforce.active .en,.est.enforce:hover .en{background:var(--color-text-success);color:var(--color-background-primary);border-color:var(--color-text-success)}
.est.external .en{border-color:var(--color-text-warning);color:var(--color-text-warning)}
.est.external.active .en,.est.external:hover .en{background:var(--color-text-warning);color:var(--color-background-primary);border-color:var(--color-text-warning)}
.est.neutral .en{border-color:var(--color-border-secondary);color:var(--color-text-tertiary)}
.est.neutral.active .en,.est.neutral:hover .en{background:var(--color-text-secondary);color:var(--color-background-primary);border-color:var(--color-text-secondary)}
.el{font-size:9px;font-family:var(--font-mono);color:var(--color-text-secondary);margin-top:5px;text-align:center;line-height:1.3;max-width:68px}
.ep{font-size:9px;font-family:var(--font-mono);padding:1px 5px;border-radius:99px;margin-top:3px;line-height:1.6}
.ep-e{background:var(--color-background-success);color:var(--color-text-success)}
.ep-x{background:var(--color-background-warning);color:var(--color-text-warning)}
.ep-n{background:var(--color-background-secondary);color:var(--color-text-tertiary)}
.edp{border:0.5px solid var(--color-border-tertiary);border-radius:8px;padding:14px 16px;min-height:100px}
.edp-s{font-size:10px;font-family:var(--font-mono);color:var(--color-text-tertiary);margin:0 0 5px}
.edp-t{font-size:13px;color:var(--color-text-secondary);margin:0 0 8px;line-height:1.65}
.edp-rows{display:grid;grid-template-columns:1fr 1fr;gap:6px;margin-top:10px}
.edp-row{padding:7px 10px;border-radius:6px;font-size:10px;font-family:var(--font-mono);line-height:1.5}
.edp-row.can{background:var(--color-background-success);color:var(--color-text-success)}
.edp-row.ext{background:var(--color-background-warning);color:var(--color-text-warning)}
.edp-row-hd{font-size:9px;opacity:.7;margin-bottom:3px}
.eleg{display:flex;gap:16px;margin-top:14px;padding-top:12px;border-top:0.5px solid var(--color-border-tertiary);flex-wrap:wrap}
.eleg-item{display:flex;align-items:center;gap:5px;font-size:10px;font-family:var(--font-mono);color:var(--color-text-tertiary)}
.eleg-dot{width:8px;height:8px;border-radius:50%;flex-shrink:0}
</style>
<div class="erc">
<div class="erc-top">
<span class="emeta">ERC-4337 EXECUTION — COMPLIANCE ANNOTATION</span>
<span class="emeta">TAP A STAGE</span>
</div>
<div class="etl">
<div class="est neutral active" onclick="esel(this,0)">
<div class="en">1</div>
<span class="el">UserOp construction</span>
<span class="ep ep-n">pre-validation</span>
</div>
<div class="est neutral" onclick="esel(this,1)">
<div class="en">2</div>
<span class="el">Bundler simulation</span>
<span class="ep ep-n">transport only</span>
</div>
<div class="est neutral" onclick="esel(this,2)">
<div class="en">3</div>
<span class="el">EntryPoint</span>
<span class="ep ep-n">protocol gate</span>
</div>
<div class="est enforce" onclick="esel(this,3)">
<div class="en">4</div>
<span class="el">validateUserOp</span>
<span class="ep ep-e">enforce here</span>
</div>
<div class="est enforce" onclick="esel(this,4)">
<div class="en">5</div>
<span class="el">validatePaymasterUserOp</span>
<span class="ep ep-e">enforce here</span>
</div>
<div class="est external" onclick="esel(this,5)">
<div class="en">6</div>
<span class="el">Execution</span>
<span class="ep ep-x">external needed</span>
</div>
<div class="est neutral" onclick="esel(this,6)">
<div class="en">7</div>
<span class="el">Settlement</span>
<span class="ep ep-n">post-exec</span>
</div>
</div>
<div class="edp" id="edp">
<p class="edp-s">Stage 1 — UserOperation construction</p>
<p class="edp-t">The agent or application assembles the UserOperation object: calldata, sender, nonce, gas limits, and paymaster data. No policy enforcement occurs here. This is where recipient substitution, prompt injection, and route mutation can already have occurred before the compliance boundary is reached.</p>
<div class="edp-rows">
<div class="edp-row ext"><div class="edp-row-hd">requires external resolution</div>Counterparty risk, route truth, invoice provenance</div>
<div class="edp-row ext"><div class="edp-row-hd">cannot enforce here</div>No validation surface exists at construction time</div>
</div>
</div>
<div class="eleg">
<div class="eleg-item"><span class="eleg-dot" style="background:var(--color-text-success)"></span>Enforceable at this surface</div>
<div class="eleg-item"><span class="eleg-dot" style="background:var(--color-text-warning)"></span>Requires external resolution</div>
<div class="eleg-item"><span class="eleg-dot" style="background:var(--color-text-secondary)"></span>Protocol / transport layer</div>
</div>
</div>
<script>
const ED=[
{s:'Stage 1 — UserOperation construction',t:'The agent or application assembles the UserOperation object: calldata, sender, nonce, gas limits, and paymaster data. No policy enforcement occurs here. This is where recipient substitution, prompt injection, and route mutation can already have occurred before the compliance boundary is reached.',can:null,ext:'Counterparty risk, route truth, invoice provenance|No validation surface exists at construction time'},
{s:'Stage 2 — Bundler simulation',t:'The bundler simulates validateUserOp and validatePaymasterUserOp to check protocol validity before including the operation in a bundle. Bundlers are transport infrastructure, not compliance adjudicators. They forward any operation whose validation logic passes, regardless of whether policy was actually enforced inside that logic.',can:null,ext:'Bundler cannot assess compliance quality|Rejection means protocol failure, not policy failure'},
{s:'Stage 3 — EntryPoint',t:'The EntryPoint contract coordinates the validation and execution sequence. It calls validateUserOp on the account and validatePaymasterUserOp on the paymaster if present. The EntryPoint enforces the ERC-4337 protocol rules but carries no native compliance semantics. What compliance exists must be encoded upstream in the validation logic.',can:null,ext:'No native compliance logic at EntryPoint|Compliance must be encoded in validation hooks'},
{s:'Stage 4 — validateUserOp',t:'The narrowest enforceable compliance gate in the ERC-4337 execution sequence. The smart account runs its validation logic here before execution is permitted. Recipient binding, delegation scope, spend limits, route manifest presence, policy version, and risk freshness can all be enforced at this surface. If the wallet requires a valid off-chain attestation before passing validation, this is where that requirement binds.',can:'Recipient binding|Delegation scope|Spend limits|Route manifest|Policy version check|Risk freshness window',ext:'Cannot self-resolve counterparty graph risk|Cannot self-resolve sanctions freshness'},
{s:'Stage 5 — validatePaymasterUserOp',t:'If a paymaster is sponsoring execution, its validation logic runs here. The paymaster can refuse sponsorship based on programmable conditions, making this a second enforcement surface. In the hybrid architecture, the paymaster can also verify that a valid policy attestation is present before agreeing to sponsor, adding a redundant compliance check independent of the wallet.',can:'Sponsorship conditions|Attestation presence check|Route class allowlist',ext:'Optional — only present when paymaster is used|Cannot substitute for wallet-side enforcement'},
{s:'Stage 6 — Execution',t:'The EntryPoint executes the calldata after both validation steps pass. At this point, enforcement opportunity has closed. What executes is whatever the validated UserOperation specified. Post-execution, the compliance layer shifts entirely to the audit artifact, which must reconstruct what the agent knew, what policy fired, and what route was resolved.',can:null,ext:'No pre-settlement intervention possible|Audit artifact is the only remaining instrument'},
{s:'Stage 7 — Settlement',t:'Finality on the destination chain. Once settlement completes, interdiction through the execution path is no longer available. Issuer controls, freeze authority, and redemption gating remain available on canonical asset paths as backstop mechanisms. The portable audit artifact produced at validation time is the primary post-execution compliance instrument.',can:null,ext:'Issuer backstop available on canonical paths only|Portable artifact is the main remaining instrument'}
];
function esel(el,i){
document.querySelectorAll('.est').forEach(s=>s.classList.remove('active'));
el.classList.add('active');
const d=ED[i];
let rows='';
if(d.can){
const cs=d.can.split('|');
const es=d.ext.split('|');
rows='<div class="edp-rows">';
rows+='<div class="edp-row can"><div class="edp-row-hd">can enforce here</div>'+cs.join(', ')+'</div>';
rows+='<div class="edp-row ext"><div class="edp-row-hd">requires external resolution</div>'+es.join(', ')+'</div>';
rows+='</div>';
} else if(d.ext){
const es=d.ext.split('|');
rows='<div class="edp-rows">';
rows+='<div class="edp-row ext" style="grid-column:1/2"><div class="edp-row-hd">requires external resolution</div>'+es[0]+'</div>';
if(es[1]) rows+='<div class="edp-row ext"><div class="edp-row-hd">note</div>'+es[1]+'</div>';
rows+='</div>';
}
document.getElementById('edp').innerHTML='<p class="edp-s">'+d.s+'</p><p class="edp-t">'+d.t+'</p>'+rows;
}
</script>Why the Wallet Alone Is Not Enough
A wallet can verify that a route manifest was supplied, but knowing whether that manifest accurately represents the full execution graph requires a resolver that already expanded the path. The same gap applies to counterparty risk: a proof can be checked for presence, but graph-risk classification, sanctions freshness, and beneficiary resolution from a display name are not things the validation contract can generate on its own.
Production wallet documentation confirms this gap rather than closing it. Safe, Base, and Alchemy all document real programmable validation surfaces, module governance, capability-scoped delegation, and installable policy plugins. None of them document sanctions-grade beneficiary resolution or cross-chain route attestation as native defaults. The hook exists, the policy substance must come from outside.
The synthetic harness built for Phase 4 of this research made the gap legible. Across 28 scenarios run against three architecture modes, wallet_core reduced risky-flow completion from 1.000 to 0.273 relative to the legacy_edge baseline, but it escalated ten scenarios rather than resolving them, specifically in invoice-provenance and route-complexity cases where the wallet could detect uncertainty but lacked the resolution machinery to act on it.
The hybrid mode dropped risky-flow completion to 0.136 and escalations to three. The difference was not blocking posture, it was resolution quality. Route attestation, counterparty resolution, and freshness gating supplied the context the wallet boundary needed to decide rather than defer. That is the most important signal in the set: the gap between wallet-only and hybrid is a resolution gap, not an aggression gap.
These numbers are architecture-comparative evidence inside a synthetic programmable-flow domain. The claim they support is architectural, not regulatory.
The Hybrid Architecture
The minimum viable architecture for programmable stablecoin compliance has three functional parts.
Off-chain risk resolution expands the candidate route, classifies the counterparty against the settlement address rather than the display name, checks sanctions freshness, and validates delegation scope against the grant record.
The programmable authorization boundary enforces the resolved policy before execution, refusing the wallet operation if the required attestation is missing, stale, or inconsistent with the proposed path. The portable audit artifact packages decision inputs and outputs so that later review does not require reconstructing the runtime from fragments.
Issuer controls remain in this architecture, but as a backstop with asset-specific powers rather than the primary real-time gate for programmable flows. Freeze and redemption authority still matters for canonical asset recovery, post-execution sanctions containment, and legally mediated remediation, and the architecture does not replace that.
What it addresses is the slice where issuer controls have already thinned, where the flow has moved into detached representations, unhosted routing, or delegated machine authority that settled value before the issuer perimeter became relevant.
The diagram below shows how the three parts sit relative to each other and where the issuer backstop re-enters.
<style>
*{box-sizing:border-box}
.hyb{background:var(--color-background-primary);border:1px solid var(--color-border-secondary);border-radius:12px;padding:20px;font-family:var(--font-sans)}
.hyb-top{display:flex;justify-content:space-between;align-items:center;margin-bottom:20px;gap:8px;flex-wrap:wrap}
.hmeta{font-size:10px;letter-spacing:.08em;color:var(--color-text-tertiary);font-family:var(--font-mono)}
.hlayers{display:grid;grid-template-columns:1fr 1fr 1fr;gap:12px;margin-bottom:16px}
@media(max-width:560px){.hlayers{grid-template-columns:1fr}}
.hlayer{display:flex;flex-direction:column;gap:8px}
.hzone-hd{font-size:10px;font-family:var(--font-mono);color:var(--color-text-tertiary);margin:0 0 8px;letter-spacing:.06em}
.hcard{border:1px solid var(--color-text-primary);border-radius:8px;padding:12px;cursor:pointer;transition:background .15s;width:100%}
.hcard:hover,.hcard.active{background:var(--color-background-secondary)}
.hcard.backstop{border-color:var(--color-border-secondary);border-style:dashed}
.hcard-title{font-size:12px;font-weight:500;color:var(--color-text-primary);margin:0 0 3px}
.hcard-sub{font-size:10px;font-family:var(--font-mono);color:var(--color-text-secondary);margin:0;line-height:1.4}
.harrow{display:flex;justify-content:center;padding:2px 0;color:var(--color-text-tertiary)}
.hlayer-arrow{display:none;justify-content:center;padding:4px 0;color:var(--color-text-tertiary)}
@media(max-width:560px){.hlayer-arrow{display:flex}}
.hdivider{display:flex;align-items:center;justify-content:center}
@media(max-width:560px){.hdivider{display:none}}
.hdp{border:0.5px solid var(--color-border-tertiary);border-radius:8px;padding:14px 16px;min-height:72px;margin-bottom:14px}
.hdp-s{font-size:10px;font-family:var(--font-mono);color:var(--color-text-tertiary);margin:0 0 5px}
.hdp-t{font-size:13px;color:var(--color-text-secondary);margin:0;line-height:1.65}
.hleg{display:flex;gap:12px;padding-top:12px;border-top:0.5px solid var(--color-border-tertiary);flex-wrap:wrap}
.hleg-item{display:flex;align-items:center;gap:6px;font-size:10px;font-family:var(--font-mono);color:var(--color-text-tertiary)}
.hleg-box{width:10px;height:10px;border-radius:2px;flex-shrink:0}
</style>
<div class="hyb">
<div class="hyb-top">
<span class="hmeta">HYBRID ARCHITECTURE — FUNCTIONAL LAYERS</span>
<span class="hmeta">TAP ANY COMPONENT</span>
</div>
<div class="hlayers">
<div class="hlayer">
<p class="hzone-hd">RESOLUTION LAYER</p>
<div class="hcard active" onclick="hsel(this,0)">
<p class="hcard-title">Agent runtime</p>
<p class="hcard-sub">assembles payment intent</p>
</div>
<div class="harrow">
<svg width="14" height="14" viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M8 3v10M4 9l4 4 4-4"/></svg>
</div>
<div class="hcard" onclick="hsel(this,1)">
<p class="hcard-title">Off-chain risk resolver</p>
<p class="hcard-sub">route · counterparty · freshness</p>
</div>
<div class="harrow">
<svg width="14" height="14" viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M8 3v10M4 9l4 4 4-4"/></svg>
</div>
<div class="hcard" onclick="hsel(this,2)">
<p class="hcard-title">Signed attestation</p>
<p class="hcard-sub">policy decision output</p>
</div>
</div>
<div class="hlayer-arrow">
<svg width="14" height="14" viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M8 3v10M4 9l4 4 4-4"/></svg>
</div>
<div class="hlayer">
<p class="hzone-hd">ENFORCEMENT LAYER</p>
<div class="hcard" onclick="hsel(this,3)">
<p class="hcard-title">validateUserOp</p>
<p class="hcard-sub">attestation · recipient · scope</p>
</div>
<div class="harrow">
<svg width="14" height="14" viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M8 3v10M4 9l4 4 4-4"/></svg>
</div>
<div class="hcard" onclick="hsel(this,4)">
<p class="hcard-title">validatePaymasterUserOp</p>
<p class="hcard-sub">sponsor · attestation check</p>
</div>
<div class="harrow">
<svg width="14" height="14" viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M8 3v10M4 9l4 4 4-4"/></svg>
</div>
<div class="hcard" onclick="hsel(this,5)">
<p class="hcard-title">Execution · settlement</p>
<p class="hcard-sub">post-validation finality</p>
</div>
</div>
<div class="hlayer-arrow">
<svg width="14" height="14" viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M8 3v10M4 9l4 4 4-4"/></svg>
</div>
<div class="hlayer">
<p class="hzone-hd">EVIDENCE LAYER</p>
<div class="hcard" onclick="hsel(this,6)">
<p class="hcard-title">Portable audit artifact</p>
<p class="hcard-sub">decision · route · inputs</p>
</div>
<div class="harrow">
<svg width="14" height="14" viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M8 3v10M4 9l4 4 4-4"/></svg>
</div>
<div class="hcard" onclick="hsel(this,7)">
<p class="hcard-title">Settlement trace link</p>
<p class="hcard-sub">artifact bound to execution</p>
</div>
<div class="harrow">
<svg width="14" height="14" viewBox="0 0 16 16" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"><path d="M8 3v10M4 9l4 4 4-4"/></svg>
</div>
<div class="hcard backstop" onclick="hsel(this,8)">
<p class="hcard-title">Issuer backstop</p>
<p class="hcard-sub">freeze · recall · canonical paths</p>
</div>
</div>
</div>
<div class="hdp" id="hdp">
<p class="hdp-s">Agent runtime — resolution layer</p>
<p class="hdp-t">The agent assembles the payment intent from prompts, tool calls, and routing context. No enforcement occurs here. The off-chain resolver runs in parallel, expanding the candidate route and resolving risk inputs before the wallet operation is submitted for validation.</p>
</div>
<div class="hleg">
<div class="hleg-item"><span class="hleg-box" style="border:1px solid var(--color-text-primary)"></span>Active enforcement component</div>
<div class="hleg-item"><span class="hleg-box" style="border:1px dashed var(--color-border-secondary)"></span>Optional backstop — canonical paths only</div>
</div>
</div>
<script>
const HD=[
{s:'Agent runtime — resolution layer',t:'The agent assembles the payment intent from prompts, tool calls, and routing context. No enforcement occurs here. The off-chain resolver runs in parallel, expanding the candidate route and resolving risk inputs before the wallet operation is submitted for validation.'},
{s:'Off-chain risk resolver — resolution layer',t:'Expands the candidate route to its full execution graph, classifies the counterparty against the settlement address rather than the display name, checks sanctions freshness against the data provider freshness window, and validates delegation scope against the grant record. Produces a signed attestation carrying all resolved inputs.'},
{s:'Signed attestation — resolution layer',t:'The policy decision output of the resolver. Contains the resolved counterparty classification, route manifest hash, freshness receipt, delegation scope confirmation, and policy version. The attestation is what the wallet validation boundary consumes. Without a valid attestation, the wallet should refuse to execute.'},
{s:'validateUserOp — enforcement layer',t:'The narrowest pre-settlement enforcement gate. Verifies the attestation signature and freshness, checks recipient binding against the approved address set, confirms delegation scope is within grant limits, and enforces route manifest presence. If any check fails, the wallet refuses execution before value moves.'},
{s:'validatePaymasterUserOp — enforcement layer',t:'If a paymaster is sponsoring execution, its validation logic provides a second enforcement surface. The paymaster can verify that a valid attestation is present before agreeing to sponsor, adding a redundant compliance check independent of the wallet. Optional but architecturally significant when present.'},
{s:'Execution and settlement — enforcement layer',t:'After both validation steps pass, the EntryPoint executes the calldata and value moves to settlement. Enforcement opportunity has closed. The compliance posture from this point is determined entirely by what the audit artifact captured at validation time and what issuer backstop powers remain available on canonical asset paths.'},
{s:'Portable audit artifact — evidence layer',t:'Packages the full decision context: resolver inputs, attestation contents, validation results, policy version, route manifest, and escalation record if applicable. Produced at validation time and linked to the settlement trace. Survives independently of the runtime that produced it, which is what makes later review possible without reconstructing the agent session.'},
{s:'Settlement trace link — evidence layer',t:'The artifact is bound to the on-chain settlement trace, creating a verifiable chain from policy decision to execution outcome. Regulators, issuers, or counterparties with access to the artifact can reconstruct what the agent knew, what route was resolved, and what policy fired without requiring access to the agent runtime logs.'},
{s:'Issuer backstop — optional downstream',t:'Freeze authority, redemption control, and clawback powers on canonical asset paths. These remain available after settlement on USDC, USDT, PYUSD, and RLUSD where the issuer contract still governs the relevant asset representation. The backstop does not substitute for pre-execution enforcement, but it is the primary remediation instrument when post-execution sanctions exposure is discovered.'}
];
function hsel(el,i){
document.querySelectorAll('.hcard').forEach(c=>c.classList.remove('active'));
el.classList.add('active');
const d=HD[i];
document.getElementById('hdp').innerHTML='<p class="hdp-s">'+d.s+'</p><p class="hdp-t">'+d.t+'</p>';
}
</script>
What the Architecture Does Not Solve
Post-execution sanctions discovery stayed unresolved in every architecture mode the harness tested. If the relevant intelligence only becomes knowable after settlement, better wallet policy cannot pull that fact backward in time. Issuer controls can help with recall or containment on canonical asset paths, and the portable artifact improves post-execution auditability, but neither closes the fundamental problem: some compliance-relevant facts arrive after finality.
One structured-payment scenario completed conditionally even in the hybrid mode. Intent-level aggregation across multiple transfers remains weaker than single-operation validation, the architecture governs one executable object cleanly, but struggles to recognize when several objects are fragments of a single intent.
Human escalation remains a governance-heavy residual. The hybrid improves the evidence that accompanies an escalation and narrows how often escalation replaces resolution, but it does not remove the oversight problem from override decisions.
Where Power Accumulates
If programmable authorization becomes the main compliance boundary for smart-account stablecoin flows, control does not concentrate at the issuer. It moves toward whoever defines the policy schema, runs the off-chain risk resolver, sets the wallet verification standard, and controls the audit interface. Wallet platforms, policy engines, attestation networks, and counterparty data providers are the operative power positions in that structure.
The bottleneck is commercial as much as technical. Whoever controls the policy schema, the verifier interface, and the attestation trust list shapes which counterparties clear, which routes count as acceptable, which sponsors are admissible, and which evidence formats downstream institutions will honor.
Issuers retain meaningful power in this structure, specifically freeze authority, redemption control, and legal cooperation capabilities on canonical asset paths, but that is not the role that decides most programmable-flow execution.
The Remaining Gap
The strongest architecture here still does not make compliance final at execution time across every scenario. Some facts arrive after settlement, some intent only becomes visible across multiple transfers, and human override remains partly outside the technical control path.
What the programmable authorization boundary plus off-chain resolution plus portable artifact accomplishes is narrow: it moves the compliance surface closer to the object that actually moves value and makes the decision legible enough to survive the runtime that produced it. For that specific slice, it is the best minimum architecture the evidence supports.
The core constraint the field has not YET solved is that execution can be made more legible before settlement, but "not every relevant compliance fact becomes knowable before settlement does."
Several questions the architecture does not resolve are worth naming directly: the most important is "governance of the resolver itself."
The hybrid layer assumes a trusted off-chain risk resolver feeding valid attestations into the wallet boundary. *Whose rulebook the resolver is executing is still open. * How its classifications are audited and who bears liability when it misclassifies a route or issues a stale attestation are also still open.
The architecture moves the compliance surface closer to execution without fully answering "who controls the policy being enforced there."
Policy placement is also unsettled: Push too much logic into the authorization boundary and portability breaks across wallets and chains, push too little and compliance recentralizes at the resolver edge, which is "a different kind of institutional chokepoint, not the absence of one."
The deeper strategic question is whether programmability actually distributes compliance or simply "relocates concentration." If resolver quality, attestation issuance, and wallet policy defaults consolidate around a small number of operators, the architecture produces a new center of gravity rather than removing the old one. THAT OUTCOME IS NOT RULED OUT BY THE DESIGN.