Cowrie Research

bridge-typed-intent-dispatch-and-control-plane-separation

15 min read

Bridge Typed-Intent Dispatch and Control-Plane Separation

  • Name: bridge typed-intent dispatch and control-plane separation
  • Category: bridge reference / executor least-authority design / control-plane separation checklist / typed-message dispatch companion
  • Summary: Healthy bridges do not stop at proving that a message is authentic. They also keep the message’s authority class explicit and narrow, then keep that authority class on a smaller route-mode budget than the bridge can call it. Ordinary settlement or application traffic should not be able to reach keeper rotation, upgrade controllers, token minters, vault admins, or other root control-plane surfaces just because one generic dispatcher, message bus, or cross-chain manager happens to sit in the middle. The recurring review mistake this note is trying to kill is collapsing three different execution promotions into one vague the bridge executed a real message: the bridge authenticated something real, that real message was treated as this typed authority class, and that typed class was then allowed to keep this much downstream reach right now. This note exists to preserve the healthy-side target behind Poly Network and adjacent overpowered-executor failures: authentic transport is not permission to exercise every kind of protocol authority.
  • Why this note exists:
    • Bridge truth as a single security object is the top-level frame for what exact cross-chain fact should count as real?, but bridges also need a narrower design note for what exact class of authority is this authentic message allowed to exercise once it lands?
    • Privileged message dispatcher abuse preserves the negative exploit family where a bridge executor can be steered into admin or custody-root calls it was never supposed to reach.
    • Poly Network is the clean bridge exemplar: one cross-chain business-call executor also owned keeper-set storage, so misrouted execution became bridge-root takeover.

The five boundaries a healthy bridge should keep disjoint

  1. Message authenticity
    • The bridge still needs to prove the message is real: right source domain, right source contract or module, right route, right semantic commitment.
    • But authentic arrival only answers did the bridge really say something like this? It does not yet answer what powers may this message exercise now?
  2. Authority class / typed intent
    • Every executable message should carry one narrow authority class: user settlement, routine mint or burn completion, admin rotation, upgrade, emergency pause, recovery, or migration.
    • The safest systems make this machine-checkable before execution, not reconstructable later from target address folklore or selector shape.
  3. Target reachability
    • A business executor should only reach the contracts and selectors required for its authority class.
    • If one ordinary bridge lane can also reach keeper-set storage, upgrader contracts, or reserve-owner surfaces, then the ownership graph has already collapsed business execution into root authority.
  4. Control-plane mutation rights
    • Keeper rotation, signer-set updates, upgrader changes, vault-admin actions, token-pool rebindings, and other bridge-root mutations should travel on distinct execution lanes with distinct authentication and review rules.
    • The bridge can call it because the bridge owns it is usually the design smell that turns dispatch bugs into custody loss.
  5. Downstream blast radius
    • Even healthy lane separation should assume one executor path can still be misrouted once.
    • Caps, pauses, delay windows, and route-local throttles should keep wrong typed call landed from immediately becoming rewrite bridge truth and drain custody. Bridge bounded release design is the companion for that containment layer.

Three execution questions reviewers should not collapse

  1. Did the bridge authenticate a real message?
    • This is the authenticity question: right source domain, right source contract, right proof or quorum, right semantic commitment.
    • A yes here only means the bridge is not obviously executing fiction. It does not yet decide which power that real message deserves on the destination side.
  2. What authority class is that authentic message allowed to exercise?
    • This is the typed-intent question: routine settlement, mint completion, refund, emergency pause, admin rotation, upgrade, migration, or recovery.
    • Poly is the reminder that authentic enough to dispatch was never the same thing as allowed to rewrite keeper truth.
  3. How much downstream power should that authority class carry right now?
    • This is the blast-radius and operating-mode question: which targets, which selectors, which assets, which release budget, under which route mode.
    • Even a legitimate admin or recovery lane should usually arrive with narrower destination reach and smaller value budget than ordinary healthy-mode business execution. Bridge bounded release design is the companion when the sharper follow-up becomes how much damage should one still-correct typed lane be able to cause if it misfires?

Three control-plane continuity questions healthy bridges should not collapse

  1. Some admin or recovery lane still exists
    • An emergency executor, keeper-rotation lane, recovery multisig path, or governance-controlled bridge manager may still be able to act.
    • This is only the weakest fact: some bridge-owned control path is still live.
  2. That lane still authenticates this exact control-plane action
    • The harder question is whether the surviving lane is still bound to one exact action family such as pause, capped recovery withdrawal, signer rotation, or one narrowly described upgrade ceremony.
    • Only admin lane left is not yet a safety claim if that lane can still reinterpret routine bridge traffic, mutate unrelated root state, or jump from recovery into full business execution.
  3. That action still deserves this much downstream authority right now
    • Even a legitimate admin or recovery lane should not automatically inherit ordinary healthy-mode target reach, asset scope, or value budget.
    • Healthy bridges keep emergency and control-plane paths on intentionally smaller target sets, narrower message families, and tighter release or mutation budgets than the business lanes they are meant to rescue.

This is the control-plane companion to the earlier execution ladder: not only was the message authentic?, but also what exact admin class survived? and how much bridge-root power should that surviving class still retain under today's route mode?

What sound design looks like

  • One message family, one bounded authority story
    • A healthy bridge can answer both who authored this message? and what exact class of action is it allowed to perform?
    • Deposit completion, refund, admin rotation, upgrade, and emergency action should not all share one generic target + selector + calldata envelope.
  • Business executors terminate at business surfaces
    • A route that exists to complete user settlement or application calls should not also be the owner, operator, or admin of keeper registries, upgrade beacons, vault controllers, or signer-set storage.
    • If a bridge truly needs cross-chain admin actions, they deserve their own intentionally narrow lane rather than piggybacking on the same executor that handles routine traffic.
  • Typed intent is validated before low-level execution
    • The bridge should commit to expected target set, selector set, calldata schema, and authority class before any privileged call occurs.
    • Low-level .call should be the last mile of a typed policy decision, not the place where the bridge discovers what kind of action it is about to perform.
    • A healthy route can answer all three destination-side execution questions in order: was the message authentic?, which authority class did it claim?, and what concrete destination reach and release budget did that class deserve right now?
  • Downstream privileged contracts stay skeptical even of trusted internal callers
    • Keeper-set storage, upgrader controllers, vault-admin paths, and token-root contracts should demand a dedicated admin lane or dedicated caller, not merely any message executor the protocol happens to trust elsewhere.
    • Internal callers deserve least privilege too.
  • Control-plane mistakes fail locally and reversibly when possible
    • Admin rotations, route changes, and high-value config mutations should be delayable, reversible, or separately pausable.
    • A bridge is much healthier when one misrouted executor call first hits a narrow admin queue or route-local brake instead of live multi-asset custody.

Useful positive design shapes

1. Typed message lanes instead of generic target-and-selector envelopes

  • The bridge should enumerate allowed message families and bind each family to a closed set of targets, selectors, and schemas.
  • Business settlement, bridge admin, upgrade, and emergency action should be distinct lanes with distinct authentication objects and telemetry.
  • This is the cleanest way to keep authentic message from silently implying arbitrary privileged call.

2. Dedicated admin executors with narrower trust roots

  • If a bridge needs remote admin actions at all, the safest shape is a separate executor or control-plane contract whose only job is administering one narrow set of bridge-root mutations.
  • That executor should not also process ordinary user or application traffic, and it should usually sit behind higher-friction review, stronger provenance, and smaller exposure budgets.
  • The useful design question is not just is there a separate admin lane? but what smaller target set, message family, and route-mode budget does that lane keep compared with healthy-mode business execution?

3. Ownership graphs that stop at the intended layer

  • A business-call executor may own or call application adapters without also owning keeper registries, vault-admin state, or upgrade controllers.
  • The healthy question is not only can outsiders call this dispatcher? but what can this dispatcher reach as owner, operator, or upgrader if its own call discipline slips?

4. Exact calldata and selector-shape commitment

  • Privileged downstream calls should validate exact selector membership, exact ABI layout, and exact argument count rather than trusting prefix-compatible calldata or dynamic method-name hashing.
  • Bridge-controlled admin paths should prefer explicit typed functions over string-derived selector dispatch or raw low-level message forwarding.

5. Bounded release under dispatcher failure

  • Even with clean typed lanes, a bridge should assume one executor mistake can still happen.
  • High-value state changes should pair with delay windows, route-local pauses, or reduced release caps so wrong privileged call does not instantly become bridge-wide insolvency.

Design questions worth asking first

  • Which message families exist on this bridge, and which exact authority class does each family exercise?
  • What contracts can each executor call directly, own indirectly, upgrade, or configure as owner, operator, manager, or equivalent root role?
  • Which actions truly need to be callable cross-chain, and which should be local-only or human-gated admin operations instead?
  • If one business executor were honest-but-overpowered rather than fully compromised, what bridge-root state could it still touch accidentally?
  • What exact policy proves this authentic message is only allowed to do this one type of thing before any low-level call happens?
  • If one misrouted privileged call lands, what exact control prevents immediate keeper replacement, upgrader replacement, pool rebind, or uncapped asset release?

Red flags that usually mean a bridge dispatcher already has too much power

  • one generic execute or message-bus surface handles user settlement, bridge admin, and upgrades
  • business executors own keeper registries, vault-admin state, token minters, or upgrade beacons
  • selectors are derived from attacker-influenced strings, route metadata, or other dynamic inputs rather than a closed typed allowlist
  • downstream privileged functions accept prefix-compatible calldata or ignore trailing ABI words
  • route documentation can explain how the message arrives but not which authority class it is allowed to exercise once it arrives
  • admin mutation travels on the same lane and through the same auth object as routine bridge business calls
  • one executor mistake would immediately expose multi-asset custody before any time-delayed brake or route-local pause can fire

Failure-prevention checklist

  • Enumerate every bridge message family and bind each family to one explicit authority class, one closed target set, one closed selector set, one exact calldata schema, and one stated healthy-mode versus degraded-mode budget.
  • Treat admin and recovery lanes as their own budgeted authority classes, not as catch-all exceptions. pause, resume, cap change, keeper rotation, upgrade, and manual recovery withdrawal should not all inherit one shared bridge admin envelope.
  • Separate routine business execution from control-plane mutation. A bridge lane that completes user settlement should not also rotate keepers, change upgrade pointers, rebind token pools, or alter reserve ownership.
  • Inventory ownership graphs as first-class security boundaries: direct calls, owned contracts, owned-by-owned contracts, and upgrader reachability all count.
  • Reject dynamic or attacker-shaped selector derivation for privileged paths. If selector derivation must remain dynamic anywhere, prove the output belongs to a closed allowlist and cannot alias admin selectors through collision or alternate encoding.
  • Validate exact ABI layout and calldata length on privileged internal calls so trailing-parameter smuggling or prefix compatibility cannot reinterpret one message family as another.
  • Give bridge-root admin paths their own authentication story, telemetry, and review workflow rather than reusing ordinary settlement executors.
  • Add delay windows, route-local pauses, and fast rollback for high-value control-plane mutations such as keeper rotation, upgrader changes, and vault-admin rewiring.
  • Pair typed-lane discipline with bounded-release controls so one executor failure cannot immediately socialize loss across unrelated assets or routes.
  • Test selector collisions, wrong-target reachability, overlong calldata, business-lane-to-admin-lane confusion, and owner-through-owner reachability directly in audits and fuzzing.
  • Log which message family, authority class, target, selector, and downstream privileged path each execution consumed so incident response can reconstruct where lane separation failed.

Audit prompts

  • What exact authority classes exist on this bridge, and where in code is each class distinguished before execution?
  • For each authority class, what destination reach and release budget does it have in healthy mode, and what narrower budget does it fall back to under degraded or recovery modes?
  • Which executors, routers, or bridge managers can reach contracts that themselves control keeper sets, upgrade rights, vault release, token pools, or emergency roles?
  • Could any authentic business message still touch admin state because the executor owns the admin contract or can forward arbitrary-ish calls into it?
  • Are selectors or method metadata ever attacker-influenced, truncated, string-derived, or otherwise weak enough to collide with privileged downstream functions?
  • Would any privileged callee accept the right selector prefix plus extra trailing calldata words the dispatcher appends for another message family?
  • If the bridge says admin actions are separate, what exact contract, auth object, telemetry, and smaller route-mode budget prove that separation today?
  • If only an emergency or admin lane survives, what exact control-plane actions remain allowed, and which bridge-root powers are intentionally still unavailable from that lane?
  • Which high-value state changes can occur instantly, and which are delayable, reversible, or lane-local pausable if a dispatcher path behaves unexpectedly?
  • During upgrades, what test proves no newly owned contract or newly whitelisted selector silently turns a business executor into a root admin path?
  • Can responders explain, for any executed cross-chain message, which authority class it claimed and which downstream privilege boundary it crossed?
  • If one misrouted privileged call landed right now, what exact blast-radius control would stop it from becoming a bridge-wide custody event?

Lessons that should already be standard

  • Authenticity is not authorization. A bridge can receive a real message and still be catastrophically wrong about what that message is allowed to do.
  • Only admin lane left is not yet a safety argument. A surviving control-plane lane still needs an intentionally smaller target set and value budget than ordinary business execution.
  • Generic executors are dangerous exactly when downstream contracts trust them as admin. Parsing, dispatch, and ownership graphs then become custody code.
  • Admin mutation deserves its own lane. Reusing one cross-chain executor for both routine business traffic and bridge-root control is a convenience trade that compounds badly.
  • Owner-through-owner is a real bridge threat model. If the business executor owns the contract that defines keepers or upgrade rights, the bridge has already concentrated too much power in one helper.
  • ABI exactness is part of authority hygiene. Prefix-compatible calldata and ignored trailing words are not harmless quirks when the caller already has protocol privilege.
  • Bridges should assume one executor mistake will eventually happen and bound it. Otherwise one typed-intent failure can immediately rewrite authority and empty custody.
  • The healthy target is boringly explicit: one message family, one narrow authority class, one closed target set, one exact schema, and one separate admin lane for bridge-root mutation.
  • Separate admin lane is still not enough if that lane silently keeps full healthy-mode authority. Recovery and control-plane continuity should preserve less reach than ordinary business execution, not the same reach with a more prestigious name.

How to use this note with the exploit corpus

  • Start here when the question is how should a healthy bridge keep routine cross-chain execution from inheriting root control-plane authority?
  • Drop into Privileged message dispatcher abuse when you need the negative exploit-family anatomy for generic executors, selector collisions, or owner-through-owner reachability.
  • Pair with Bridge truth as a single security object when the question expands from lane separation to the full authenticated bridge object.
  • Pair with Bridge bounded release design when the separate question becomes how much damage one misrouted privileged call should be allowed to cause before the route is contained.
  • Pair with Execution-envelope identity pinning when the sharper issue is not only which authority class? but also which exact target bundle and call envelope stayed committed end to end?

Internal linkages

Control surface

Graph View

Backlinks