Reading a Pendle limit order
Our last piece on Pendle was about what a position is worth. This one is about a harder question: whether you can tell a transaction is yours at all. A passive limit order changes your holding inside a transaction you did not send, and you did not send one to place it either. You signed the order off the chain, gaslessly, and later a stranger’s transaction filled it and moved your position. Nothing in that transaction is addressed to you.
How a passive limit order works
Section titled “How a passive limit order works”On Pendle you can trade a PT or YT two ways. You can swap against the pool right now, in your own transaction, or you can place a resting limit order and wait. The second one does not work the way it looks. You do not send a transaction to place the order. You sign it: an off-chain message that fixes your price, size, and expiry, gasless and invisible to the chain. The signed order rests in Pendle’s order book, off the chain, until a taker chooses to fill it. Only then does it touch the chain, when that taker submits your signed order inside their own transaction.
An ordinary swap is simple to account for: the trade belongs to whoever sent the transaction, or to the address named in the call. A passive limit order is the opposite on every count. You are not the sender. You are not the party the router is executing for. You did not send a transaction to place the order, and you did not send the one that filled it. The only place you surface as a counterparty is the event the router emits at fill time, naming you as the maker of the order it just settled.
One transaction, two makers
Section titled “One transaction, two makers”Here is a public example you can open on Etherscan: one Pendle router transaction from June 2026, at block 25,385,272. We use it only to show the shape of the problem. No client wallet is a party to it.
A stranger sends a single call to the Pendle router, and that one call settles two resting limit orders
from two different makers, across forty-eight logs. The router is the taker on both. The two fills
surface as two OrderFilledV2 events, one at log 80 and one at log 93, each naming a different maker and
a separate order.
Forty-eight logs came out of that call. Two of them carry the whole story.
| Log | Event | Order type | Maker | Maker gives | Maker receives | ||
|---|---|---|---|---|---|---|---|
| 80 | OrderFilledV2 | SY_FOR_YT | 0x3f4bef…983c | 7.915265 | srUSDe | 67,638.983589 | YT-srUSDe-25JUN2026 |
| 93 | OrderFilledV2 | PT_FOR_SY | 0x2e966c…1444 | 202.014470 | PT-srUSDe-25JUN2026 | 197.131215 | srUSDe |
Read what those two lines name, and what they do not. Each names its maker. The counterparty each one names is the router, not the wallet that sent the transaction. So the log gives you one side of the trade and a contract, and the person on the other side of it is not in there at all.
Two positions change in this one transaction. Neither maker sent it. Neither maker is the address the
call executes for. Each appears exactly once, as the maker field inside its own OrderFilledV2
event, and nowhere else that a decoder would treat as a party to the trade.
Why reading the call books nothing
Section titled “Why reading the call books nothing”Decode the function the transaction called and you see one thing: a stranger swapped a token for PT through the router. The makers are not parties to that call. Their addresses sit inside the signed order structs the taker submitted to fill them, not in the counterparties a decoder produces from the call.
So a tool that books from the decoded call books nothing for either maker. Their positions changed, and there is no journal entry behind the change. The holding simply moves. If you are one of those makers, your PT or YT balance shifts with nothing in the transaction to explain it, because the part that was yours was never in the part a call-reader looks at.
Recovering the fill
Section titled “Recovering the fill”The only record of a maker’s fill is the event, so that is where attribution has to begin. Booking a
fill means reading the OrderFilledV2 events rather than the call. You walk every one of them, read the
maker field on each, and keep the events whose maker is one of your wallets. In this transaction there
are two makers, and if one of them were yours, you would book that fill and its two legs, the PT that
left and the token that came in, and you would leave the other maker’s fill untouched. It is not yours,
and it belongs on nobody’s books but theirs.
It is worth seeing what that transaction does to three sets of books at once, because they have almost nothing in common. The taker sold a large YT position. One maker bought a slice of it, and the rest was recombined with PT and redeemed back into the underlying. The other maker was not in that trade at all: they sold PT, a different instrument, and were simply filled in the same call.
- YT-srUSDe-25JUN2026
- −438,862.217827
- srUSDe
- +64.820733
- srUSDe
- −7.915265
- YT-srUSDe-25JUN2026
- +67,638.983589
- PT-srUSDe-25JUN2026
- −202.014470
- srUSDe
- +197.131215
Three parties, three unrelated trades, one transaction. You already know it concerns you, because your balance moved and that is why it is in front of you at all. What you do not have is which two of those six lines you book, and that comes from the events, not from the call.
What makes this real work rather than a lookup is that one transaction can fill many orders in sequence, so you cannot stop at the first event. Filling several at once is the shape the router is built for, not a quirk of this transaction, so you have to walk all of them to find the one that is yours. Miss the walk and you book someone else’s position.
Waiting has a second consequence worth knowing. An order does not have to be filled all at once. It can be taken in pieces over time, in separate transactions days apart, so a position arrives in instalments and no single one of them is the whole trade.
The same lesson, one step further
Section titled “The same lesson, one step further”This is the same problem as our teardown of one real transaction, carried a step further. There, the account was missing from the transfer: the movement was in plain sight, but the thing it belonged to had to be recovered from the protocol. Here, you are missing from the transaction: the movement is not even addressed to you, and the only thread back to your books is a maker field buried in a log.
In both cases the accounting truth lives in the events the protocol emitted, not in the function the transaction called. Reading it is programmatic, protocol-level work: you reconstruct what actually happened from the logs, for every protocol whose transactions do not announce themselves. That is the difference between a book built from what occurred and one built from what a transaction happened to be labelled.
The general point
Section titled “The general point”A Pendle position can be hard to price and, as this shows, sometimes hard even to recognize as yours. A set of books that is right has to get both: what the position is worth, and the fact that it moved at all. That is the unglamorous, protocol-by-protocol care behind DeFi NAV and shadow NAV, on exactly the transactions that do not make it easy.