The riskiest moment in a leveraged position that uses a maturity based token has nothing to do with the market. Everything comes down to whether or not a user checks their messages and unwinds their position before their yield starts to dwindle away.

Users can access boosted yields through leverage products that borrow a stablecoin against the yielding counterpart, but when the maturity date of the yielding leg is reached the position is no longer productive. But as that maturity date approaches, all we can do today is post announcements: banners across the top of our websites, messages in our community Telegrams, and direct reach outs to large depositors warning them to get out.

If users fail to react in time, they remain sitting in a position that is costing them money. Every hour past maturity, the earned yield is being eaten away and due to the leverage, the risk of liquidation comes into frame.

We have all of the information needed to avoid these risks. The timelines are public and known well in advance but the money markets for these tokens don’t shut down at the maturity date, so the systems to navigate these moments have to settle for manual, multi-party coordination. Imagine you’re a lifeguard who can see a swimmer drifting toward the rocks. You know the exact moment the current will take them, but you can’t swim out. All you can do is shout from the shore.

As an industry, we have accepted this shout from the shore, but at a certain point, the routine stops scaling. This is made more painful by the fact that this problem scales alongside adoption. There are too many expiration dates to keep up with and too many users to inform. So users often miss the messages and start blaming the products for their lost yield. There are too many riptides and too many swimmers in the water to save all of them by shouting.

But solving this problem requires new smart contracts that are expensive and time-consuming to build. Months spent on development and audits, all to kill a reminder process that must continue throughout each epoch between now and then. And due to the immutability of smart contracts, the code at the end of all of those months would address the shape of this single issue and nothing else. The math doesn’t make sense for a lean team, so the reminder process stays in place, and we keep shouting from the shore.

Spiral Stake opened our eyes to this exact problem. They launched in late 2025 as a leverage execution system built on top of Morpho, to enable users to enter positions that boost existing yields and quickly scaled to $3.3M in assets managed.

One flavor of their offerings revolves around using Pendle Principal Tokens (PTs) as collateral. Pendle PTs are bond-like tokens, bought at a discount and redeemed for full value at a fixed public date. The discount is the yield. At the end of every epoch, Spiral Stake, like the rest of us operating in this part of the market, makes announcements to depositors that it is time to exit these positions.

The problem they presented wasn't about code. It was routine: the registry of dates, the banner rotation, the pings, the direct messages to the largest depositors, and the standing worry underneath all of it. The question that came back was different: why does anyone need to be warned at all?

Plug’s programmable transactions can ensure that no one gets swept away in the current. A plug is a transaction intent written in advance and signed once, carrying its own conditions with it, to achieve whatever outcome we want. The signature grants permission for exactly one thing, and nothing else. No keys change hands. No funds are custodied.

The next announcement has the opportunity to be a celebration instead of a warning. Users can sign the exit intent once, and everything is in place before the water ever turns dangerous.

Spiral Stake understood the vision, so the Plug team jumped into action, and Morpho support, the first piece the fix depended on, was live a day after the first conversation. And because of Plug’s protocol integration framework and human readable intents, there was no need to write or audit any new smart contracts. The ability to exit a leveraged Morpho position on a pre-established date was live within the week, inside a single epoch, before the problem could happen again.

To get here, our teams considered every outcome that needed to be achieved on Morpho to make this possible: access to flashloans, ensuring complete exits, and handling Morpho’s oracle nuances. Let’s walk through how each piece can be achieved to instantly settle everyone’s transactions at expiry.

First, we support Morpho’s flashloan system. We know that closing a leveraged position requires capital you don't have on hand while you're deployed. The money is the collateral, and the collateral can't be accessed until the debt is repaid. But Morpho’s flashloans let us access the capital needed to unwind an entire position at once, so there is no step-by-step looping, no queue of transactions to manage, and no gas bill that stacks with every step. And because Morpho’s flashloans carry no fee, the automated exit costs a fraction of what the manual unwind ever did.

Next, we ensure that our exits clear completely within Morpho’s share based accounting system. Morpho accounts for debt in shares rather than tokens, so exiting cleanly requires us to convert between the two without losing precision, and repay our debt down to the last share so nothing is left behind in a position that’s supposed to close.

Lastly, we handle Morpho’s oracle nuances. To enable our flashloan repayment, we swap the collateral token back to the loan token, but Morpho’s oracle does not return tokens priced in USD. Collateral tokens are priced in terms of the loan token, so we need to calculate the right amount of collateral to be swapped to the loan token before repaying the flashloan. Otherwise, we naively swap all of the withdrawn collateral, we end up exiting the position holding the wrong token in the market.

Now that all of these concerns have been handled, the exit intent can be assembled as a set of individual steps taken off the shelf and strung into a single transaction, gated behind one question about the date.

The hard work is done, and today every team building on these markets gets it for free.

But an audit of the old process finds one aspect that remains: a human’s touch is still required. The date registry must be maintained and every intent depends on a human having typed the right date. A system that has to be told when to act is still manual at the root. Automating warnings was never the goal. Removing the need to make announcements at all was.

With the exit intent assembled and firing based on a date, the risk falls plainly on maintenance of the registry and translation of its records into the date checking step of the transaction.

Input a date that causes the intent to fire too early, and users miss out on gains they should have captured. Enter a date too far past the maturity, and earned yield starts to deteriorate. Fail to enter a date altogether and users risk liquidation unless they remember to log back in and inspect the position themselves.

Every market has its own date and needs its own record in the registry, so the scale of the problem remains even if the need to act has been addressed. And nothing can be built on top: rollovers into the next epoch are impossible while a human curates the calendar.

Either the dates come from the onchain markets themselves, or the problem stays half-solved.

The maturity dates were always public, always known in advance, and they never needed to live in anyone’s spreadsheet. They exist onchain, in Pendle’s own contracts, published the moment each market is created.

So the exit changes shape one last time. Before a single token moves, the intent asks the market directly: has the maturity date been reached? That question is one new Pendle read sitting at the top of every exit. Nothing beneath it changes: the hand-typed date comes out, the onchain answer goes in, and this final adjustment arrives before the week ends. The registry isn’t automated. It’s deleted.

For the first time, we know how the epoch will end before it occurs. The moment the maturity date is reached, the intents fire. Everyone exits together, safe, and with all of the yield they generated intact. The growth that had been breaking the process is no longer a risk. No more messages on a schedule. No more shouting from the shore and hoping.

Time and effort spent maintaining the date registry and managing the announcement process made us feel important in the ongoing relationship with our users. But we are no longer required to act in this way. The message sits in drafts. It never needs to be sent. We don’t need to protect users by shouting from the shore when the maturity date approaches, and we realize we were never supposed to be the lifeguard.

The following epochs end without announcements, and other teams start asking how they can avoid that manual process. Now, our energy is focused on distributing and improving our offerings rather than managing positions. Instead of protecting users at maturity, we can focus on the next step: rollovers into the next epoch. And rollovers are not a new build, they are a recombination: the same pieces that close this epoch’s position can open the next one, and every piece added this week combines with everything already on the shelf. Each problem solved this way makes the next team’s problem smaller before they ever ask.

Everything that manual announcements were trying to do has been delivered through programmable transactions. A problem we’ve accepted for years in the industry is solved in a week.