Skip to content

Anatomy of a Pendle pool

The word "pool" gets used loosely. On Pendle it has a precise, on-chain meaning, and getting that meaning right is the difference between loading the market you intended and pasting the wrong address. This page dissects a single Pendle pool: the one contract that is the pool, the three token contracts that hang off it, the data the pool exposes, how OpenPendle verifies a pool's origin before letting you act on it, and the trust that a factory check does — and does not — establish.

If you have not yet met Standardized Yield (SY), the Principal Token (PT), the Yield Token (YT), or the AMM, read those pages first. This one assembles them into a whole and assumes each individually.

A pool is one contract: PendleMarket

A "pool" — the app also calls it a market — is a single deployed smart contract of type PendleMarket. That contract is the pool. It holds the AMM reserves, quotes swaps, mints and burns liquidity, records the maturity date, and knows which token contracts it belongs to. Everything you do on a pool — swap, add liquidity, remove liquidity — is a call that ultimately touches this one address (routed through Pendle's Router V4, 0x888888888889758F76e7103c6CbF23ABbF58F946).

A community pool is simply a PendleMarket that someone deployed permissionlessly — no whitelist, no approval, and unreviewed by anyone. It is the same contract type Pendle's own app uses; the only difference is that Pendle's app does not list it. OpenPendle exists to let you use these markets. See Community pools & incentives.

The four contracts that make a pool

A pool is not one token — it is a small constellation of contracts that reference each other. One PendleMarket is wired to exactly one PT, one YT, and one SY, all sharing a single maturity and a single underlying yield-bearing asset.

Read the diagram from the top down:

  • The underlying is the yield-bearing asset the whole structure is built on — a staked token, a lending receipt, a vault share. Pendle wraps it as SY, a uniform EIP-5115 interface, so every downstream contract talks to one standard regardless of the asset inside.
  • Before maturity, SY splits into PT (the principal, redeemable 1:1 for the underlying at maturity) and YT (the right to all the yield until maturity). PT + YT mint from SY and redeem back to SY 1:1 at any time before maturity.
  • The PendleMarket is the AMM. Its standing reserve is PT and SY — not YT. Depositing into it makes you a liquidity provider and issues you LP tokens, a pro-rata claim on those reserves. (YT is not pooled; it is traded against SY by routing through the same market. See Liquidity & the AMM.)
  • The factory is the contract that deployed the market. It is not part of the pool's balance, but it is part of the pool's identity: the market records which factory created it, and that provenance is what OpenPendle checks.

Five contracts are therefore in play for one pool — underlying, SY, PT, YT, market — plus the factory that stamped it. Only one of those five is the address you hand to OpenPendle.

Paste the market address — not PT, YT, or SY

This is the single most important operational fact on this page.

Which address is the pool?

The pool is the PendleMarket contract. Its address — not the PT address, not the YT address, not the SY address — is what you paste into OpenPendle to open a market. The PT, YT, and SY are reachable from the market once it is loaded; you never enter them directly.

The confusion is natural, because a single pool exposes four related addresses (market, PT, YT, SY) and a block explorer or a third-party dashboard may surface any of them. Three of the four are the wrong thing to paste. Only the PendleMarket address loads the pool.

Pasting the wrong address is detected and reported

You do not have to memorize which of the four addresses is correct, because OpenPendle checks. When you paste an address that is a PT, YT, or SY rather than a market, OpenPendle detects the token type and reports it back to you — telling you the address is a component of a pool, not the pool itself — rather than silently failing or loading a broken screen. The intended fix is to find and paste the PendleMarket address for that same maturity.

This detection is a convenience, not a trust signal. Recognizing that an address is a PT does not mean the pool behind it is safe; it only means you pasted the wrong one of the four addresses.

Where to find the market address

If you have a PT, YT, or SY and need the market, look for the PendleMarket for that asset and maturity on a block explorer or in the pool's own metadata. Once you have any working pool loaded in OpenPendle, its market address is the one you can remember for next time — saved pools store the market address, so you resolve this lookup once.

What data a pool exposes

Because OpenPendle has no backend, no database, and no indexer, everything you see about a pool is read live from the chain — from the PendleMarket and the contracts it points to — over a public RPC, batched through Multicall3 (0xcA11bde05977b3631167028862bE2a173976CA11). The pool is self-describing. The main fields:

DataRead fromWhat it tells you
Component addressesThe marketThe PT, YT, and SY this market is wired to.
MaturityThe market / PTThe fixed date the pool resolves — after it, PT redeems 1:1, YT is worth 0, trading stops. See Maturity & redemption.
ReservesThe marketThe PT and SY balances in the AMM — the depth backing a swap and what an LP share is a claim on.
Implied APYDerived from the PT priceThe fixed yield implied by the current PT price — see How Pendle works.
Underlying / SY detailsThe SYThe wrapped asset, its decimals, and what tokens the SY accepts in and out.
Factory provenanceThe marketWhich factory deployed the market — the field OpenPendle validates (below).

Two notes on this data:

  • Implied APY is derived, not stored. No contract holds an "APY" field. It is computed from the current PT price against par and the time left to maturity, and it moves as PT trades. Treat any figure as a live reading, never a promise.
  • Prices come from a TWAP oracle. Pendle's PendlePYLpOracle (0x5542be50420E88dd7D5B4a3D488FA6ED82F6DAc2) provides time-weighted average prices for PT, YT, and LP. A freshly deployed market starts with oracle cardinality 1; quoting and trading through OpenPendle do not require the oracle to be expanded, but other protocols that want to price the pool via TWAP do. See Initializing the oracle.

Provenance: how OpenPendle validates a pool

Anyone can deploy a contract and call it a Pendle market. OpenPendle will not let you save or transact against a market until it has verified that the market was in fact created by a Pendle factory it recognizes. This is the provenance gate.

How the check works, and why it is built the way it is:

  • The factory set is hardcoded, for validation only. OpenPendle ships a known set of Pendle factory addresses and uses it solely to answer one question: did a recognized factory deploy this market? It is a provenance test, not an endorsement list.
  • The active factory is resolved live. Pendle's factories are governance-mutable — governance can change which factory is current. So OpenPendle resolves the active factory at runtime against the chain rather than trusting a frozen value; the hardcoded set is used only to validate provenance, never to decide where a new deploy is routed.
  • Factory lineage differs by chain. Not every network has the full history of factory versions. The lineage present today: Ethereum, BSC, and Arbitrum carry v1 + V3 + V4 + V5 + V6; Base and Plasma carry V5 + V6; Monad is V6 only. The authoritative live per-chain list is on the app's Protocol Status & Contracts page, which you can verify against pendle-finance/pendle-core-v2-public.

Validation is not endorsement

Passing the provenance gate proves only that a market descends from a genuine Pendle factory. It says nothing about whether the asset or SY underneath is sound. OpenPendle validates market provenance but cannot vouch for the assets or SY contracts underneath. A factory-valid market can still wrap a broken, exotic, or malicious asset.

The trust surface of a pool

A factory-valid market narrows what you have to trust, but it does not eliminate it. When you interact with a pool, you are extending trust to several distinct things. Know each one.

You are trustingWhy it mattersWhat provenance covers
The Pendle factory & contractsThe market, AMM, and PT/YT split logic are Pendle's audited V2 contracts.✅ Validated — the market descends from a recognized factory.
The underlying assetIf the underlying fails, PT may not redeem at par and the whole structure breaks.❌ Not covered — unreviewed.
The SY contractSY wraps the asset; a faulty or hostile SY can break deposits, redemption, or accounting.❌ Not covered — unreviewed.
The SY owner / upgradeabilitySome SYs are upgradeable proxies; whoever controls them can change SY behavior.❌ Not covered — see below.

The SY owner and upgradeability

The SY is the contract closest to the money, and it is the one most worth scrutinizing. Two facts about how community-pool SYs are typically owned:

  • Wizard-deployed SYs default to Pendle governance. An SY deployed through OpenPendle's create flow (via PendleCommonSYFactory, 0x466CeD3b33045Ea986B2f306C8D0aA8067961CF8) has, by default, its ownership assigned to Pendle's governance proxy (0x2aD631F72fB16d91c4953A7f4260A97C2fE2f31e). The owner can hold privileged roles over the SY's configuration.
  • Adapter SYs are upgradeable proxies under Pendle's ProxyAdmin. The "one-click adapter SY" variant is a TransparentUpgradeableProxy whose admin is Pendle's ProxyAdmin (0xA28c08f165116587D4F3E708743B4dEe155c5E64), i.e. Pendle governance. An upgradeable proxy means the implementation can be changed by its admin — a power that lives with governance rather than the pool's creator in the default case.

The point is not that Pendle governance is hostile — it is that "upgradeable" and "owned" are real properties of the trust surface, and a community pool's SY may have been deployed with a non-default owner or a custom adapter. Always check who owns and can upgrade the SY of a pool you intend to fund. The Protocol Status & Contracts page and a block explorer are your tools here.

A factory-valid pool can still lose you money

Community pools are permissionless and unreviewed — anyone can create one, and interacting with them can lose you funds. OpenPendle validates market provenance but cannot vouch for the assets or SY contracts underneath. If the underlying asset fails, the PT may not redeem at par; if the SY is faulty or hostile, deposits and redemption can break. Provenance protects you from a fake market, not from a bad asset. Experimental — use at your own risk. Not affiliated with Pendle Finance.

A worked example: dissecting one pool

Example — illustrative addresses and numbers only

The addresses and figures below are invented to show the shape of a pool's anatomy. They are not a real pool, asset, or APY, and pasting them will not load anything.

Imagine a community market with these four contracts, all sharing one maturity:

RoleIllustrative addressDo you paste it?
PendleMarket (the pool)0xMARKET…✅ Yes — this is the pool
PT0xPT…❌ No — detected & reported as a PT
YT0xYT…❌ No — detected & reported as a YT
SY0xSY…❌ No — detected & reported as an SY

You paste 0xMARKET…. OpenPendle confirms it is a PendleMarket, checks that a recognized Pendle factory on the active chain deployed it (provenance passes), then reads the pool live: maturity ~6 months out, reserves of roughly 60% PT / 40% SY, an implied APY of about 7%, and an SY wrapping the underlying whose owner resolves to Pendle's governance proxy.

Now suppose you had instead pasted 0xPT…. OpenPendle would detect a PT and report it — this is a component of a pool, not the pool; paste the PendleMarket address — and you would go find 0xMARKET…. At no point are the illustrative 7% or the 60/40 split a guarantee; they are live readings that move with every trade.

See also

Released under the GPL-3.0 License. Not affiliated with Pendle Finance.