Pendle is a DeFi Yield-Trading Protocol Built Around Principal Tokens

Pendle is a practical route for swapping an accepted asset into a dated Principal Token, reading the resulting on-chain balance and closing the position at the right stage. Before maturity, PT exits through a market sale; after maturity, it redeems against the named accounting asset or rolls into a later market.

The wrong maturity changes the PT you receive

Four fields define a Pendle PT position: accounting asset, market contract, chain and expiry. A mismatch in any field produces a different claim.

The date in the token name matters because every maturity has its own PT and market address. The accounting asset in brackets sets the unit returned at redemption; PT-ezETH (ETH) settles in ETH value rather than one whole ezETH. The chain decides where the ERC-20 balance lives and which gas asset pays execution. Check all 4 fields in the trade preview before signing, then match the market address to the position row after settlement. A familiar symbol alone doesn't identify the claim because tokens from the same yield source carry different expiries and prices.

Entering PT starts with the route's exact chain and output

A Pendle PT entry succeeds when the wallet, input asset, receiver and minimum output match the quoted route. The app assembles those choices before execution.

Choose the dated market

Choose the dated PT market first, then set the wallet to the chain carrying that market. Ethereum uses chain ID 1, Optimism 10, BNB Chain 56, Mantle 5000, Base 8453 and Arbitrum One 42161. MetaMask and other EVM wallets use these identifiers to keep a same-looking balance on the intended network. ETH pays gas on Ethereum, Optimism, Base and Arbitrum One; BNB pays it on BNB Chain.

Review the receiver and minimum

The receiver defaults to the connected wallet, yet cross-chain PT makes the destination a separate decision. If the receive chain differs from the market chain, the preview shows swap and bridge legs and the final balance appears on the selected destination. Pendle presents the cross-chain route as 1 user transaction even though it contains several settlement steps. Read the minimum PT output after selecting the source, destination and input token.

Approve the input and execute

When the input token's ERC-20 allowance falls below the spend amount, entry requires 2 on-chain transactions: approval and swap. Native ETH skips the ERC-20 approval step. The approval authorizes the router to spend a stated amount; the swap then converts the selected input and sends PT to the receiver. Wait for both receipts before judging the final balance.

The balance belongs to a contract address, not a display label

A Pendle PT balance is the ERC-20 balance of one contract on one chain. The Dashboard and wallet simply render that state.

The Dashboard groups 3 position types - PT, YT and LP - beneath the selected chain and offers 2 viewing modes. USD Mode converts positions and profit or loss into dollar terms, while Underlying Mode expresses each individual asset position in its underlying units. Aggregate portfolio values remain dollar-denominated. If the row hasn't appeared after settlement, read the transaction receipt, confirm the receiver address and reopen the same network. Etherscan serves Ethereum, Arbiscan serves Arbitrum One and BaseScan serves Base; each explorer exposes the token transfer and receiver balance.

An EVM account address is 20 bytes, displayed as 40 hexadecimal characters after 0x; the full visible address therefore contains 42 characters. A transaction hash is 32 bytes, or 64 hexadecimal characters after 0x, for 66 visible characters. USDC uses 6 decimal places, while ETH-style assets commonly use 18. PT and YT follow the relevant underlying setup, including 18-decimal Scaled18 wrappers where Pendle uses them.

Partial sales resize the position without changing its maturity

A partial Pendle sale spends only the exact PT amount entered and leaves the remainder under the same contract. The quote, minimum received and price impact apply to the sold slice, while the unsold PT keeps its original accounting asset and expiry. After settlement, compare the wallet's remaining ERC-20 balance with the Dashboard position row. This routine adjustment releases part of the position while preserving the existing maturity for the remainder.

What happens when a PT market reaches maturity?

At maturity, a Pendle market stops pricing PT as a tradable time-discounted claim. The position becomes a redemption or rollover decision.

Each market uses 1 Unix timestamp recorded in seconds by the yield contract, so a calendar label resolves to an exact on-chain boundary. At that boundary, the YT claim reaches 0 and the market no longer supplies an early-exit quote. Before expiry, direct PY redemption requires equal PT and YT amounts; after expiry, PT alone supplies the principal claim. The Dashboard then exposes 2 maturity actions: Roll Over and Redeem All. PT also stops gaining from convergence toward par. The next choice is therefore between cashing out and selecting a later expiry.

Selling before expiry and redeeming afterward settle differently

A PT sale uses the market's live route, while maturity redemption uses the yield contract's principal claim. The available output and price source therefore change at expiry.

Before maturity, swapExactPtForToken spends an exact PT amount and returns a market-priced token output. The quote incorporates pool state, price impact and the selected output conversion; minimum received sets the transaction floor. At maturity, 1 PT redeems for 1 unit of the accounting asset named in brackets on the market. For another output token, the app redeems into SY and converts that SY through the requested route. Matured PT redemption carries a 0% Pendle protocol fee, although the chain still charges gas and any output conversion retains its route terms.

Worked example. Every changing input is hypothetical: an exact sale of 40 PT from a USDC-accounting market, a 38.6 USDC quote, a 0.5% slippage tolerance and route liquidity remaining constant until inclusion. Minimum received equals 38.6 × (1 − 0.005), or 38.407 USDC. If execution can't produce at least 38.407 USDC, the swap reverts; network gas sits outside this output calculation. The concrete comparison is between that 38.407 USDC floor and the 40 USDC maturity claim.

A rollover replaces one dated claim with another

A Pendle rollover converts the source position into a later PT or LP market within 1 routed transaction. It changes maturity rather than merely refreshing the display.

After maturity

After expiry, the Dashboard exposes Roll Over beside Redeem All. Its 6-step flow opens the matured position, selects a target market, chooses PT or LP source amounts, optionally bundles LP rewards, chooses PT or LP as the destination and asks for final approval. A target marked Similar Market keeps the underlying asset and broad risk profile aligned while extending maturity. Choosing another asset changes the economic exposure, so the next expiry isn't the only field to compare.

Before maturity

Before expiry, rollover uses a normal swap with the existing PT or LP selected as the input asset. That path sells the source position at its market price and enters the target market at its quoted terms. The dedicated Roll Over action appears only after maturity, when redemption has replaced the source market sale. The timing decision weighs uninterrupted deployment against accepting the source market's price before its 1:1 claim becomes redeemable.

The router converts inputs through SY and the PT AMM

Pendle's router turns a supported input token into Standardized Yield before the market delivers PT to the receiver. Each layer has a distinct job.

Input normalization

Standardized Yield, or SY, wraps different yield-bearing assets behind one contract interface. Lido stETH, Aave aUSDC and Ethena sUSDe illustrate yield sources with different accounting behavior. The route converts the selected input into a form the relevant SY accepts, then mints or sources SY for market execution. KyberSwap supplies an intermediate token conversion when the selected route needs one.

Market execution

Barring an unusual setup, PendleMarket trades PT against SY rather than arbitrary input tokens directly. Exact-token entry therefore requires an approximation: the router computes how much SY must swap to deliver PT, while the Hosted SDK narrows the binary-search range off-chain. Eligible limit-order fills join the route before settlement. The transaction encodes minPtOut as a 256-bit unsigned integer, so 0 removes token-output protection at contract level; the user-facing route supplies a nonzero floor from the chosen slippage setting.

Receipt settlement

After execution, the router sends net PT to the receiver and emits ERC-20 transfer logs. The PT contract already binds the token to 1 SY, 1 YT and 1 expiry, so the receipt doesn't create a generic balance. Importing the exact PT address into a wallet restores the correct display without changing the position. The next operation always starts from that same token contract.

The final receipt defines the next action

A completed Pendle exit leaves an output-token balance, a transaction receipt and any remaining PT. Those 3 records distinguish a full close from a partial adjustment.

A full pre-expiry sale leaves 0 PT and the chosen output token, while a partial sale leaves the unsold remainder. Full maturity redemption consumes PT and delivers the selected asset. Roll Over leaves a later PT or LP token instead. The receipt logs identify the contract addresses, token amounts and receiver, so display labels don't control reconciliation. Match the output balance with any remaining PT, then decide whether the next position should retain the accounting asset or adopt a different maturity.