Cowrie Research

market-role-authenticity-and-cross-market-token-segregation

14 min read

Market-Role Authenticity and Cross-Market Token Segregation

  • Name: market-role authenticity and cross-market token segregation
  • Category: integration-safety reference / market-local role-admission design note / endpoint-authenticity checklist / permissionless-market segregation companion
  • Summary: Healthy protocols do not let this token exists or this contract implements the expected interface answer the stronger question what economic role may this object play inside this exact market? They keep one market-role object intact: the exact market instance, the exact role being assigned inside that instance, the exact issuance lineage or canonical external asset that is allowed to occupy that role, the exact helper or hook context allowed to operationalize it, and the exact segregation boundary that keeps one market’s derivative or one counterfeit endpoint from masquerading as another market’s reserve, repay, collateral, or reward-defining object. This note exists to keep that positive design target explicit instead of making readers reconstruct it only by inverting incidents like Cork Protocol or Onyx Protocol.
  • Why this note exists:
    • Some exploits are not well-described by bad token semantics alone and not well-described by wrong root object alone. The sharper failure is that the protocol never kept which market is this? and what role may this object play here? fused into one protocol-owned answer.
    • Permissionless market creation, flexible helper paths, and callback-heavy settlement widen the temptation to treat market-local roles as late-bound metadata. That is how one market’s derivative token becomes another market’s reserve asset, or how a counterfeit market contract becomes the apparent canonical repay or collateral endpoint.
    • The healthy-side question is not only did we authenticate a real contract? It is did we authenticate the right contract in the right market-local role with the right issuance lineage and settlement context before money moved?

The six joints a healthy market-role object should keep fused

  1. Canonical market instance identity

    • The protocol needs one exact answer to which market, vault, liquidation lane, or reward program is being reasoned over.
    • A token or helper cannot be admitted safely if the system has not first fixed the exact market-local object whose economics it is about to trust.
    • This is the first joint Cork lost once a new market could be created around attacker-chosen role assignments while downstream settlement still touched the original market’s real redemption machinery.

  2. Exact role assignment within that market

    • The object must bind what the candidate actually is in that market: reserve asset, pegged asset, collateral market, repay market, reward source, debt leg, claim leg, or redemption leg.
    • This contract is a real ERC-20 or this contract exposes the oToken ABI is weaker than this object is the canonical repay or reserve role for this exact market right now.
    • This is the joint Onyx lost when a liquidation helper let caller-supplied contracts define the repay-market and collateral-market roles inside a privileged flow.

  3. Issuance lineage or canonical external-asset provenance

    • The object must bind whether the role expects a canonical external asset, a market-local derivative issued by this exact market, or some narrower registry-approved equivalence class.
    • Healthy systems do not let a derivative minted in market A become reserve truth in market B merely because it is real, transferrable, and expiry-bearing.
    • A market role should come with one explicit answer to where did this token get the right to mean that here?

  4. Role-local settlement and hook context

    • The object must bind which helper, hook, pool, callback, or settlement lane is allowed to operationalize the role assignment.
    • A protocol that says this token is the reserve asset for this market but then lets attacker-shaped hook or helper context mint against that claim still has two incompatible trust stories.
    • Cork is the clean reminder that role authenticity and hook authenticity often need to be proven together, not in separate mental buckets.

  5. Cross-market segregation boundary

    • The object must bind what stays market-local and what may travel across markets as fungible inventory, collateral, or payout material.
    • Healthy systems do not let one market’s receipt, derivative, or helper-authenticated claim silently inherit reserve, repay, or collateral meaning in a sibling market without crossing an explicit admission boundary.
    • Token is transferable and token may satisfy another market's core liability are very different claims.

  6. Post-admission effect scope

    • The object must bind what real authority the role assignment unlocks: minting, redemption, liquidation, borrow power, reward recognition, or payout routing.
    • Sound design does not let a newly admitted role instantly inherit every downstream effect surface before the protocol proves that the assignment is canonical, market-local, and still within the intended settlement lane.
    • If one bad role assignment can immediately reach uncapped redemption, liquidation, or reserve release, the design has skipped the bounded-loss layer too.

What sound design looks like

  • Market identity comes before role validation

    • The protocol first anchors the exact market, vault, or helper-owned state machine it intends to trust, then validates which objects may occupy which roles within that state machine.
    • It does not ask a caller-supplied market or token to explain its own legitimacy after the fact.

  • Role meaning is protocol-authored, not interface-inferred

    • Reserve asset, repay market, collateral market, reward source, and redemption leg are explicit protocol-owned assignments rather than ambient conclusions drawn from ABI shape, expiry metadata, or caller-chosen addresses.
    • A contract can be valid code and still be invalid for the role under review.

  • Issuance lineage is part of role authenticity

    • A healthy protocol can say whether a role expects a canonical external asset, a wrapper bound to one issuer path, or a market-local derivative minted by this exact instance.
    • If that lineage cannot be stated machine-checkably, the role boundary is already too soft.

  • Settlement context cannot re-author role truth later

    • Helpers, callbacks, and pool hooks may consume a role assignment, but they should not be free to redefine which object holds that role after execution is already in flight.
    • Market-role truth and settlement truth should be two views over the same committed object, not two independent stories.

  • Cross-market reuse is explicit and narrow

    • If a token may legitimately travel between markets, the protocol should specify the exact conversion, wrapper, or admission rule that grants that meaning.
    • Otherwise the default should be segregation: market-local derivatives stay market-local, and helper-local endpoints stay helper-local.

  • Wrong-role admission should fail before economic side effects

    • The best design bar is stronger than the helper later notices something odd. The protocol should reject the candidate before minting, liquidation, redemption, reward publication, or reserve release begins.

Useful positive design shapes

1. Typed role registries per market instance

  • Keep one protocol-owned mapping from market instance to allowed role occupants: canonical reserve asset, canonical repay market, canonical collateral market, canonical reward source, canonical hooks or pool ids.
  • Helpers and callbacks should load from that registry rather than accept fresh caller-supplied substitutes.

2. Market-local token namespaces

  • Treat market-issued derivatives, receipt tokens, DS / CT pairs, vault shares, or strategy receipts as objects that are market-local by default.
  • If any of them can later serve as reserve, collateral, or repayment truth somewhere else, force that through a separate explicit admission process instead of inheriting meaning from transferability alone.

3. Role-specific helper entrypoints

  • Prefer helper paths that already know which role they are servicing instead of generic market-like object in, do the rest flows.
  • A liquidation helper should load the canonical repay and collateral markets itself; a redemption helper should load the market’s canonical reserve asset itself; a reward harvester should load the canonical reward source itself.

4. Joint authentication of role and settlement context

  • When hooks or callbacks are involved, bind which role-bearing object is being used and which exact hook / pool / helper context is allowed to act on it in the same committed state.
  • This is the positive-design answer to exploits that need both counterfeit role assignment and counterfeit callback context to cash out.

5. Market-local blast-radius controls

  • Even if a wrong role slips through, caps, isolated markets, delayed redemption, route-local payout buckets, and pause scope should keep that mistake from immediately inheriting full reserve or liquidation authority.
  • Role authenticity and bounded-loss design should reinforce each other.

Design questions worth asking first

  • What exact market instance is this flow trying to reason over, and where is that identity fixed before any caller-supplied addresses are trusted?
  • What exact role is the candidate object supposed to occupy here: reserve asset, repay market, collateral market, reward source, derivative leg, or helper endpoint?
  • Does the protocol prove the object’s issuance lineage or canonical external-asset provenance, or merely that the object looks interface-compatible?
  • Could one market’s derivative or receipt token become another market’s reserve, collateral, or repayment truth without crossing an explicit admission boundary?
  • If hooks, callbacks, or helper flows are involved, what exact committed state proves that the role assignment and the settlement context still belong to the same market-local object?
  • What real economic authority does this role grant immediately after admission, and what caps or quarantines keep a wrong assignment from becoming full loss at once?

Red flags that usually mean market-role truth is too loose

  • The caller supplies the market and the token, and we just verify they point to each other.
  • This token is real and expiry-bearing, so it is good enough to be the reserve leg here.
  • The helper only needs an interface-compatible oToken / market contract.
  • Hooks are authenticated separately from market configuration.
  • Transferable market-issued tokens can be reused anywhere another market expects a similar-looking asset.
  • If the role is wrong, a later mint / redeem / liquidation check will catch it.

Failure-prevention checklist

  • Define market-local roles explicitly and keep a protocol-owned source of truth for which object may occupy each role in each live market or helper path.
  • Load canonical role occupants from trusted local state, registries, or Comptroller / factory bindings rather than from arbitrary caller-supplied addresses.
  • Distinguish external canonical assets from market-local derivatives, receipts, or claims, and make cross-market reuse opt-in through explicit admission logic rather than implicit through transferability.
  • Bind role authenticity and settlement authenticity together whenever hooks, callbacks, routers, or helper-owned state machines can operationalize the role assignment.
  • Reject interface-compatible but role-incompatible endpoints early: looks like the right ABI is never enough for reserve, repay, collateral, reward-source, or redemption-critical roles.
  • Keep helper and convenience paths role-specific. Do not let liquidation, redemption, migration, or reward wrappers accept fresh caller-defined market graphs they will later trust.
  • Add negative tests for wrong-role admission specifically: one market’s derivative as another market’s reserve asset, fake repay market, fake collateral market, fake reward source, fake helper endpoint, and mixed-market hook context.
  • Make market-issued tokens market-local by default in docs, code, and registry semantics; if a token may cross domains, encode the conversion and trust boundary explicitly.
  • Put blast-radius limits under newly admitted roles anyway: isolated markets, route-local payout buckets, redemption caps, delayed activation, and fast pauses should survive one wrong assignment.
  • Preserve operator telemetry for role-authentication failures: unexpected role changes, mixed-market hook calls, non-canonical role occupants, and helpers consuming endpoints outside approved registries.

Audit prompts

  • What exact storage object or registry says which contract occupies each economically meaningful role in this market right now?
  • Can the caller choose a market-like or token-like endpoint that the protocol later treats as reserve, collateral, repay, or reward truth without first loading a canonical protocol-owned binding?
  • If the candidate object is a market-issued derivative or receipt, what exact rule says it is allowed to satisfy this role in this different market?
  • Do helpers and callbacks consume the same market-role object the protocol authenticated earlier, or can they rebind to a different endpoint or pool context mid-flight?
  • Is the protocol proving role lineage (minted by this market, listed by this registry, approved by this Comptroller, external canonical asset) or only proving interface shape and local pointer consistency?
  • Which economic effects become live immediately after role admission: minting, redemption, liquidation, borrow power, reward distribution, or reserve release?
  • What would stop one wrong role assignment from cashing out through a deeper sibling market, canonical redemption path, or helper-owned reserve bucket before operators react?
  • Are market-local derivatives, receipt tokens, or helper-issued claims segregated by default, or can downstream code silently treat them as generic fungible inventory?
  • Which tests prove that one market’s real token cannot masquerade as a different role in another market even when hooks, helper callbacks, or nested settlement routes are involved?
  • If a protocol advertises permissionless market or plugin creation, what exact narrower rule still prevents new instances from defining reserve or repay truth for old ones?

Lessons that should already be standard

  • Real token is not the same thing as valid token role here.
  • Looks like the right market is not the same thing as is the canonical market this helper was supposed to trust.
  • Transferability is not permission for cross-market economic meaning. Many market-issued objects should remain market-local even when the token standard makes them movable.
  • Helper flows often inherit more economic authority than developers realize. A liquidation, redemption, or reward wrapper that accepts caller-defined endpoints is often equivalent to letting callers redefine market truth.
  • Hooks and callbacks are not only caller-authentication problems. They are also role-authentication problems whenever they operationalize reserve, repay, or collateral assignments.
  • Permissionless market creation is not free-form role creation. If the protocol cannot say what new markets are forbidden to treat as canonical reserve or payout objects, the permission boundary is still underspecified.
  • The healthy review question is blunt: what exact object has the right to mean reserve / repay / collateral / reward truth in this market, and where is that right enforced?
  • Cross-market segregation is a safety feature, not an inconvenience. Many systems fail because they collapse same chain, same standard, same asset family into same economic role.

Negative exemplar cluster: what split market-role truth looks like

  • Cork Protocol is the clearest real token, wrong role, wrong market exemplar: a legitimate market’s DS token was allowed to masquerade as RA in a new market, and attacker-shaped hook context then turned that counterfeit role assignment into redeemable claims.
  • NFTLiquidation is the clean helper trusted the wrong role occupants exemplar: counterfeit market contracts became the apparent repay and collateral endpoints inside a privileged liquidation convenience path.
  • Exactly Protocol is the useful mixed fake market first, hostile callback second exemplar: the decisive mistake begins with accepting the wrong market endpoint as authoritative, then cashes out through later callback authority.

How to use this note with the exploit corpus

  • Start here when the sharper design question is how should a protocol keep market-local roles, issuance lineage, and helper / hook context coherent enough that one market's token or one counterfeit endpoint cannot impersonate another market's reserve, repay, collateral, or payout object?
  • Pair with root-of-trust substitution when the exploit-side classification question is still primarily which counterfeit root object got trusted first?
  • Pair with semantic compatibility failure when the exploit-side classification question is still primarily why did interface shape get mistaken for economic safety?
  • Pair with helper-path invariant reuse and fail-closed discipline when the sharper design follow-up is why a liquidation, redemption, or migration helper should have loaded canonical roles and reused the main invariant instead of trusting caller-shaped endpoints.
  • Pair with settlement envelope truth as a single security object when the protocol already authenticated the right market role but later let a hook or settlement blob redefine which exact stage, payer, or counterparty was being settled.
  • Pair with collateral membership truth as a single security object when the sharper downstream question is no longer role admission itself but which admitted assets still support debt for one account or vault.

Internal linkages

Control surface

Graph View

Backlinks