Cowrie Research

bridge-source-provenance-bundle-and-authoring-surface-discipline

13 min read

Bridge Source-Provenance Bundle and Authoring-Surface Discipline

  • Name: bridge source-provenance bundle and authoring-surface discipline
  • Category: bridge reference / source-authentication design / authoring-surface checklist / protocol-comparison note
  • Summary: Healthy bridges do not ask relayers, guardians, or downstream executors to guess who was allowed to speak for the bridge. They keep one source-provenance bundle intact: the exact source chain or domain, the exact emitter contract or module, the exact channel / endpoint / lane, the exact handler or state-transition family, and the exact semantic claim that artifact is allowed to make. Most message-source authentication failures happen because one of those joints gets widened or reconstructed later from weaker evidence such as event shape, log topic, packet format, mixed receipt context, fallback validation, or this usually comes from the real bridge folklore.
  • Why this note exists:
    • Bridge truth as a single security object is the right top-level frame, but bridges also need a narrower design note for the upstream question who is allowed to author bridge truth at all?
    • Message-source authentication failure captures the exploit family; this note is the positive-design companion for what a healthy authoring surface should look like.
    • Incidents such as Alephium, pNetwork, THORChain’s July 2021 refund-path exploit, and Secret / Axelar show the same recurring mistake in different clothes: the bridge authenticated message shape more strongly than message authorship.

The five joints a healthy source-provenance bundle should keep fused

  1. Canonical source domain
    • The artifact must come from the exact chain, rollup, appchain, channel, or lane the bridge meant to trust.
    • Packet from a compatible transport is not enough if only one channel or endpoint is actually entitled to back the destination-side asset.
  2. Canonical emitter set
    • The bridge should know the exact contract, module, or system component allowed to author each message type.
    • Bridge-looking events from helper contracts, wrappers, factories, refund rails, or sibling applications are still counterfeit if they are outside that set.
  3. Canonical handler path / state-transition family
    • Even the right contract can speak in the wrong context.
    • A deposit artifact should come only from the deposit path, a refund artifact only from the refund path, a migration artifact only from the migration path, and so on.
    • Right contract, wrong state transition is still forged bridge truth.
  4. Canonical semantic claim
    • The artifact should already commit to what it means: deposit, mint authorization, burn proof, refund, rollback, migration, governance action, or route update.
    • If downstream components have to infer intent from surrounding transaction context or operational convention, the authoring surface is under-specified.
  5. Per-artifact authentication rather than ambient batch trust
    • One legitimate bridge message should not sanitize neighboring artifacts in the same receipt, transaction, packet batch, or observation window.
    • A healthy bridge proves provenance for each relay-authoritative artifact independently.

Three source-authorship promotions healthy bridges should keep separate

  1. A bridge-shaped source artifact exists at all

    • A packet, event, log, VAA-like payload, voucher denom, or receipt fragment exists somewhere in the source-side system.
    • This is the weak first fact: something parseable and bridge-adjacent happened.
    • Many systems quietly stop here and let downstream observers treat recognizable message shape as the hard part of authenticity.

  2. That artifact proves one exact route-local speaker and one exact semantic claim

    • The harder question is whether the artifact came from the exact source domain, exact emitter, exact channel or endpoint, exact handler path, and exact message family that were entitled to author bridge truth for this route.
    • This is where pNetwork, THORChain’s refund-path exploit, Alephium, Secret / Axelar, and similar incidents actually fail: a weaker artifact was over-promoted into canonical bridge authorship even though the speaker set or semantic path had already widened.

  3. That admitted source-authorship object deserves this much destination-side authority

    • Even an authentic-enough source artifact should not automatically inherit full mint, release, dispatch, or shared-reserve authority.
    • This is where route-local caps, typed destination handlers, and containment still matter: the right speaker said something real is not the same claim as this message may now reach the whole balance sheet.

Healthy bridge review gets materially better once teams stop flattening those three promotions into one vague comfort claim like the relayer saw the right event.

What sound design looks like

  • One message type, one narrow speaker set
    • Each relay-authoritative message type has a machine-checkable allowlist of source domains, emitters, and route identifiers.
    • The safest systems are boring here: one bridge core, one route family, one semantically committed message surface.
  • Authorship and semantics are bound together
    • It is not enough to prove this came from the right contract if that contract can emit the same generic artifact from deposit, refund, recovery, rollback, and migration paths.
    • Healthy designs either use distinct message discriminants or keep semantically different paths unable to produce the same downstream-authoritative artifact.
  • Transport context is part of provenance
    • Channel IDs, IBC ports, emitter chains, route IDs, packet classes, topic layouts, and endpoint bindings are not metadata.
    • They are part of the statement this source-side artifact is allowed to speak for this destination-side asset or action.
  • Fallback validation preserves the same authoring surface
    • Degraded mode should not broaden which emitter, channel, endpoint, or path may author bridge truth.
    • If failover cannot preserve the same provenance guarantees, the route should stop rather than accept a weaker speaker set. Bridge verifier independence inventory and degraded-mode discipline is the companion when the sharper question is how failover should narrow authority under stress.
  • Helper paths cannot mint lookalike truth cheaply
    • Refund rails, recovery tools, wrappers, migrations, and admin helpers should not be able to emit artifacts that downstream relayers could confuse with fresh custody-moving authority.
    • If such paths must exist, they deserve separate message families and separate downstream treatment.
  • Route-local provenance failure should be survivable
    • Even healthy source-authentication design should assume one forged artifact may land once.
    • Caps, pauses, quarantines, and route-local throttles should stop one wrong speaker from immediately socializing loss across the whole bridge. Bridge bounded release design is the companion for that containment question.

Design questions worth asking first

  • For each relay-authoritative message type, which exact tuple defines allowed authorship: source domain, emitter contract, channel or endpoint, handler path, route identifier, and semantic claim?
  • If a message parses cleanly, what extra checks still prove it came from the one source-side actor actually entitled to speak?
  • Can the canonical contract emit the same artifact from both custody-changing and non-custody-changing paths?
  • Do relayers authenticate each artifact independently, or do they implicitly trust transaction, receipt, or batch context once one legitimate bridge event appears nearby?
  • What changes during degraded mode: infrastructure only, or the set of speakers allowed to author bridge truth?
  • Which upgrades, wrapper deployments, channel migrations, resource remaps, or factory additions would silently widen the authoring surface?

Red flags that usually mean authorship is already too broad

  • relayer documentation says watch the logs without naming the exact contract, path, and route semantics that make those logs authoritative
  • one generic event schema is emitted from deposit, refund, rollback, and helper paths with different downstream meaning
  • fallback validation relies on event shape, topic shape, or packet format when canonical-emitter checks become hard
  • a legitimate bridge event in one receipt makes sibling lookalike events or packets seem trustworthy by association
  • channel, endpoint, or route bindings live in operational convention rather than in machine-checked policy
  • compatibility wrappers, factories, or migration shims can emit artifacts that are indistinguishable from bridge-core output to offchain observers
  • route expansion or bridge upgrades do not force corresponding relayer-policy updates

Failure-prevention checklist

  • Enumerate the canonical authoring surface for every relay-authoritative message family: source domain, emitter contract or module, channel / endpoint, handler path, route identifier, and semantic claim.
  • Make that surface machine-checkable and route-specific. Relayers, guardians, and replay tooling should all enforce the same explicit policy rather than inheriting operational folklore.
  • Use distinct message discriminants, event schemas, or packet classes for materially different semantics such as deposit, refund, rollback, recovery, migration, and governance action.
  • Ensure non-canonical paths cannot emit lookalike artifacts that downstream components treat as fresh mint or release authority.
  • Authenticate provenance per artifact, not per surrounding transaction, mixed log batch, or packet bundle. One real bridge artifact must not confer trust on counterfeit neighbors.
  • Bind source-channel and endpoint identity tightly. A real packet from the wrong channel, route, or endpoint should fail before any asset-specific mint or release logic runs.
  • Treat degraded mode and failover validation as changes to bridge truth itself. If fallback cannot prove the same speaker set and semantic constraints, it should pause or sharply narrow release authority.
  • Review wrappers, factories, migrations, resource remaps, and route additions as authoring-surface changes. Expanding who can emit bridge-relevant artifacts is a security-boundary change, not a maintenance detail.
  • Add route-local caps, fast emitter revocation, and quarantine controls so one forged-authorship event cannot immediately spread across all assets and chains.
  • Test attacker-owned emitters, wrong-channel packets, helper-path emissions, mixed authentic-and-counterfeit batches, and fallback-validation paths directly rather than relying on happy-path message parsing tests.

Audit prompts

  • What exact tuple defines canonical provenance for this message family, and where is each field enforced today?
  • Can any non-canonical contract, module, wrapper, or helper path emit an artifact that honest relayers would still parse as bridge-authoritative?
  • Does the bridge prove right emitter only, or also right path, right route, and right semantic claim?
  • If two message sources share one packet shape or event schema, what prevents downstream observers from confusing them?
  • Are channel / endpoint bindings part of the authenticated object, or can a syntactically valid packet from the wrong route still reach mint or release logic?
  • What happens during failover, manual replay, guardian outage handling, or emergency recovery? Does any such mode broaden who can author bridge truth?
  • Can one legitimate bridge event in a receipt, block, or packet batch accidentally authenticate attacker-authored siblings by association?
  • Which upgrades or config changes would widen the authoring surface without a corresponding governance review of relayer and guardian policy?
  • If a forged source artifact were accepted right now, what exact control stops additional artifacts from the same wrong speaker: route-local pause, emitter denylist, cap clamp, or only a full bridge halt?
  • Can monitoring explain not just that a message was processed, but why this exact source-side speaker, path, and route were entitled to author it?

Lessons that should already be standard

  • A bridge-shaped artifact exists, that artifact proves one exact route-local speaker and semantic claim, and that admitted source-authorship object now deserves destination-side mint or release authority are three different claims.
  • Bridge messages are not authentic because they parse. They are authentic because one explicitly defined source-side speaker, on one explicitly defined route, was allowed to say that thing.
  • Right contract is not sufficient when the wrong handler path on that same contract can still emit a downstream-authoritative artifact.
  • Channel and endpoint identity are part of security, not transport plumbing. Real packets from the wrong route are still counterfeit bridge truth.
  • Mixed-batch trust is a recurring bridge smell. One real message does not make neighboring lookalikes safe.
  • Degraded mode is not allowed to redefine the speaker set quietly. If fallback broadens authorship, the bridge has already changed what counts as truth.
  • Wrapper support and compatibility shims are part of the authoring surface. If they can speak in a bridge-core accent, they need bridge-core review.
  • Route-local brakes matter even for provenance bugs. By the time counterfeit bridge truth has spread into AMMs, lenders, or offchain redemption queues, the source-authentication mistake has already become broader balance-sheet damage.
  • The healthy target is boringly explicit: one message family, one narrow speaker set, one route identity, one semantic claim, and no guesswork by observers.

Why this control matters

  • Source provenance is the first answer to who was allowed to speak for the bridge at all? If that answer is fuzzy, the rest of the bridge can behave exactly as designed and still honor counterfeit truth from the wrong speaker, wrong channel, wrong helper path, or wrong semantic context.
  • This is why parser correctness and verifier strength are not enough on their own. A syntactically valid packet, event, or receipt can still be bridge-authenticity failure when the authoring surface was wider than the protocol’s economic trust boundary.
  • The control matters especially during degraded mode, replay tooling, and route expansion. These are the moments when teams are most tempted to fall back to message shape, packet familiarity, or operational convention instead of preserving the same narrow speaker set.
  • It also matters because mixed-batch and mixed-context trust are easy to miss. One real bridge event in a receipt or one real packet in a batch should never sanitize attacker-authored neighbors, but operational tooling often drifts in exactly that direction unless provenance is explicit.
  • Route-local caps and pause paths still belong in the picture: when the wrong speaker gets accepted once, the next question is whether the bridge can isolate that exact authoring surface before the counterfeit message family becomes system-wide balance-sheet damage.

How to use this note with the exploit corpus

  • Start here when the question is what should a healthy bridge have made true before any source-side artifact was allowed to speak for the route at all?
  • Drop into Message-source authentication failure when you need the exploit-family anatomy for forged emitters, wrong-channel packets, helper-path confusion, or batch-contaminated observation.
  • Pair with Bridge deposit truth binding when the sharper question is not only who spoke? but also did the source-side artifact prove that real value moved on the canonical custody path?
  • Pair with Bridge canonical-path exclusivity and stale authoring-surface deauthorization when the sharper question is why a bridge that had already identified the right speaker set still left older generic paths, helpers, or refunds able to publish equivalent truth.
  • Pair with Bridge truth as a single security object when the question expands from authorship to the whole bridge authenticity bundle, including exact message commitment, asset identity, and verifier independence.
  • Pair with Bridge bounded release design when the separate question is how much one bad source-authentication event should ever be allowed to release or mint.

Internal linkages

Control surface

Graph View

Backlinks