Cowrie Research

cork-protocol

3 min read

Cork Protocol

  • Name: Cork Protocol
  • URL: https://docs.cork.tech/
  • Category: tokenized risk / redemption-liquidity infrastructure / programmable protected-exit markets
  • Summary: Cork Protocol is best understood as a programmable redemption-liquidity layer for risky or awkward onchain assets, not as a generic insurance product. Its core primitive takes a collateral asset and splits it into a principal claim (cPT) plus a swap/coverage claim (cST) that can be exercised before expiry by delivering the reference asset in exchange for the collateral asset. The reusable mechanism insight is that Cork turns “guaranteed exit liquidity under stress” into a separately tradeable tokenized right, which makes it analytically closer to a programmable CDS or protected-redemption rail than to a mutual-style cover pool.
  • What it does:
    • Pairs a Collateral Asset (CA) such as a liquid yield-bearing token with a Reference Asset (REF) whose depeg, duration, or redemption-liquidity risk needs coverage
    • Mints two separable claims when liquidity providers deposit collateral: Cork Principal Tokens (cPT) and Cork Swap Tokens (cST)
    • Lets cST holders exercise before expiry by delivering REF + cST to receive CA, creating a guaranteed redemption path even when secondary liquidity is stressed
    • Lets cPT + cST recombine back into the original collateral before expiry, and lets cPT redeem residual pool assets after expiry
    • Supports use cases such as depeg hedging, duration coverage for long redemption queues, liquidity buffers for vaults and bridges, peg support, and self-liquidating protected loops
    • Uses a singleton CorkPoolManager architecture with a periphery CorkAdapter, oracle/rate controls, and explicit governance / whitelist components
  • Key claims:
    • The official docs and GitHub docs mirror describe Cork as a programmable risk layer for vault tokens, yield-bearing stablecoins, and liquid (re)staking tokens, with the core mechanism built around a Collateral Asset / Reference Asset pair and the cPT / cST split
    • The docs say cST is the coverage instrument that grants the right to exchange the reference asset for the collateral asset before expiry, which is why Cork is better modeled as tokenized redemption rights than as passive “insurance” marketing
    • The Phoenix repository says deposits mint cPT + cST, exercise consumes REF + cST for CA - fee, unwind operations let positions reverse before expiry, and post-expiry redemption lets cPT holders recover the remaining pool mix
    • The Phoenix architecture centers all pool state in a singleton CorkPoolManager, which suggests the main protocol control surface sits in one shared market-management core rather than in fully isolated vault logic
    • The same repository makes governance unusually legible: DefaultCorkController handles pool authorization, fees, pause controls, treasury operations, and whitelist access management, while WhitelistManager provides both global and market-specific access control
    • The repository also highlights ConstraintRateAdapter for rate clamping / oracle safety and a protected CorkAdapter with slippage checks, deadlines, minimum outputs, and whitelist validation, which means the protocol’s trust surface includes oracle policy and execution protection rather than only payoff design
    • The docs frame Cork as infrastructure for institutional onchain credit and tokenized assets, which matters because the protocol is not only pricing risk; it is also trying to make stressed exits and delayed redemptions look composable enough for larger allocators
  • Whitepaper: No canonical standalone whitepaper or litepaper surfaced cleanly in this pass. The strongest primary materials were the official docs overview, the public docs mirror repo, and the Phoenix code/README architecture notes; see ../whitepapers/cork-protocol-primary-sources-2026-05-09.md.
  • Sources:

Internal linkages

Graph View