Anyone working in crypto has heard the phrase "code is law." This arose because deploying and interacting with smart contracts is permissionless, and the rules of a transaction are defined in the code. So, most people in crypto focus on just explaining the code. But in traditional finance, everyone is used to reading legal contracts and laws. In an effort to cross the chasm into institutional finance, crypto has ended up with a bunch of tech companies trying to slap terms like "discretionary, custodial, and ratings" onto smart contracts without actually translating what is happening onchain.

This guide will present a new framework to help bridge the language gap between finance and crypto, by showing how crypto protocols map to traditional financial agreements.

Templates, Conventions, and Operations (TCO)

The TCO framework captures the three key components that must come together when creating any financial product:

• Templates: First, decide on a standard structure of a product before any terms are filled in. It sets the roles, assets, the rights and obligations, and what happens on default.

• Conventions: Then, fill in terms on a template which come from a range of values, formulas, and rules. The commonly accepted ranges shift largely due to the counterparties involved and the state of the market.

• Operations: During the operational lifecycle of the agreement after launch, a party may want to change it. This comes with various procedures such as who has to be notified, who has to agree, and how long until a change takes effect.

Let's walk through this framework by first outlining the basics of the TradFi side, and then do a deeper comparison on the crypto side. This is meant to be a beginner's guide, so do not worry if you do not know much about finance/law or crypto.

How Traditional Financial Products are Created

Financial products are not created by law - they are built through agreements between parties. Those agreements set out who the counterparties are, what each one is responsible for, and which events trigger which actions (a missed margin call, a default, a redemption request). The law then looks at what the finished product does and who it is sold to, and decides which rules apply. Now, these agreements for a given financial product must be standardized to some degree for widespread adoption to be possible.

TradFi Templates: Standardizing Products through Forms

For example, let us take the "repurchase agreement" (repo) which is simply an agreement to sell an asset to another party and buy it back at a later date. This has been standardized by the SIFMA/ICMA trade bodies in MRA/GMRA forms, where "trade bodies" are non-profit associations that represent the collective industry and the MRA/GMRA are the standard forms for defining a repo agreement. Many financial products have some sort of trade body or government-sponsored enterprise (GSEs) standard, like ISDA Master Agreements, Fannie/Freddie mortgages, LSTA term loans, SIFMA/ISLA securities loans, etc. For the more tech inclined readers, you can think of the Y Combinator SAFE as a kind of standardized form. We are going to refer to these as "templates" from here on out.

Keep in mind that many of these templates took decades of iteration to work out! Many of these forms started with in-house/per company versions until some industry wide failure caused/forced standardization, such as the 1982 Drysdale collapse.

Many more complex financial products like a Commercial Mortgage Backed Security (CMBS) do not have some industry wide standard form - but that does not mean there is not some range of commonly expected terms.

TradFi Conventions: Going from Template to Agreement

After there is a template, the involved parties have to agree upon a set of terms that dictate values and add ons such as the MRA Annex I (supplemental terms such as margin percentages, eligible securities and extra default events) and Annexes II–VII, plus a separate tri-party custodial agreement when a tri-party agent is used. The common configurations give us "conventions" which depend on parties involved and the surrounding market conditions. A good example is a term loan (see the LSTA form) and its covenants. Loans come with rules around what triggers a default outside of just a failure to pay - for example, the leverage ratio (debt/EBITDA) may vary between 4-6x based on the economy, and maybe "cov-lite" when some covenants may be left out completely (in good times).

TradFi Operations: Checks and Balances on Operations

Finishing the negotiation process creates an agreement. After the agreement is activated, there can still be changes that happen during its operational lifetime. These changes are required to go through certain checks before a change is finalized. I am categorizing the checks required as notice, approval, and time to take effect. The checks differ depending on what is being changed. Each row in the table below represents an important category of actions that could be changed and the "checks" in each column - here is the comparison for an ETF:

The above table may differ for the same kind of product based on the template and conventions used, and there are still gray areas here where checks are skipped. For example if a manager wants to change the allocation of a mutual fund there can still be style drift without an official change in the mandate. These agreements fall along public/private and binding/non-binding spectra. Much of the information is only inspectable by the SEC/oversight body. Strict rules generally govern changes to a product's key characteristics, and these changes often involve many counterparties.

How Crypto Products are Created

The first misconception to clear up is that all those ERC-XX standards you have read about are NOT templates. They are just low-level code libraries that are unopinionated on the final use case. A crypto product is defined as the final live token, pool, vault, etc. that may be made up of many standards and libraries.

Crypto Templates: Protocols and Pools

"Templates" are packaged together by protocols like Uniswap v4 or Morpho Blue into different kinds of "pools," which allow you to launch a token pair swapping or lending pool by calling just one function with the "terms" specified as the function inputs (this call produces an onchain transaction from a single party). There are many different protocols for launching similar pools, which have taken inspiration from each other over time from new protocol versions but are still far from being standard the same way TradFi forms are. A big difference from TradFi is that these protocols benefit financially from you using their templates (in the form of fees on certain functions), so these are NOT at all neutral trade bodies.

Over the last decade of crypto, we have gone from protocols making all the design decisions about a template's configurations (in terms of how pricing, liquidation, and access should work) to giving more authority to the launcher of a pool. This is in part because to be able to support real world assets (securities like treasuries and stocks) onchain, you need to allow for more precise controls around access, operations, and pricing to be legally compliant.

You will often hear the word "factory created" when it comes to pools, because the underlying logic is the same for each pool. You will also hear "called" or "launched" which all mean that some single party (the "from" field) has created a transaction that initializes the pool. This is also where "permissionless" comes from, as typically anyone can call these functions to launch a pool. You may also hear terms like "markets" or "children" or "pairs" in crypto, but I am representing them all with just "pools" in this guide.

The above observes a single pool in isolation. The templates get more complex the more structured the product is, especially when multiple "templates" are launched and combined with one another. For example, this is the balance sheet graph of contracts/counterparties involved in launching a leveraged loop of a single asset (USDe) to maximize risk adjusted returns (Twitter explainer here):

Crypto Conventions: A Battle for Liquidity

"Conventions" are still in their early stages in crypto, and are often a PvP battle to see who can get their pool to attract the most liquidity first. One party creates the pool, and the other parties come in later to then select the pool to interact with (as an LP/swapper or lender/borrower). If a lending pool is launched with a conservative LLTV (the ratio at which collateral is liquidated) and a conservative oracle (price feed that takes the minimum value of a few sources) and that pool gathers lenders quickly, then as a borrower that may end up being the cheapest pool to borrow from even though you may get liquidated more easily.

We have seen this actually lead to losses when borrowers assume that the terms of a pool have not changed for fixed term assets which need a new pool created for the next term, upon maturity. See the below timeline for launching Morpho Blue pools for the same collateral, a Pendle PT-reUSD token.

A few Pendle PT-reUSD pools were initialized by a different party than past pools in June 2026, who introduced a new oracle that ended up getting "attacked" to liquidate $35m+ of borrowers. This oracle favored lenders over borrowers and did not have sufficient liquidity to prevent the attack.

So in a code only, adversarial environment, how can you set conventions? Is it always the party with more liquidity/incentives strong arming the others into following along in their pools? There are very few examples of being able to set more standard conventions onchain unfortunately, most of it happens in the backrooms today as part of "due diligence" processes during onboarding new assets to different protocols.

On launching lending pools, there are a few papers that take inspiration from TradFi conventions like the ISDA SIMM to use in crypto as D-SIMM (Keyring) so we can have more standard haircuts/LTV setting in new pools. Or for oracle pricing, new oracles come out following new orders from the SEC around TSV (LlamaRisk article) or discussions around Rule 611/NBBO requirements as it comes out (Allium letter).

However, having a written methodology does not force other parties to adopt it or comply with it. The most powerful method of setting conventions today is by gating distribution at the app/api level. For example, the Morpho Vaults frontend has specific requirements around being listed. Even though these aren't publicly disclosed, we can construct the assumed rules based on various online resources and comments from the Morpho team:

A lot of words in the table above are code-speak that primarily apply to how changes can happen to how these products are operated after launch. And for the pools we talked about earlier, most of the popular aggregators and frontends are arbitrarily adding and removing as they go (or through paid integration deals) behind closed doors. Very few protocols like Aave have a public governance process around the creation and term setting of pools and collaterals, so only they can launch and change new pools.

Crypto Operations: The Complexities within Dependency Graphs

The templates and conventions are so different and scattered right now that it would misrepresent products like a "market" or a "vault" to compare based on just one agreement (i.e. just one market/vault) like we did for the ETF above. Let's start with understanding how "notice, approval, and time" apply to onchain structures.

Let us start with "notice", which is the same for all pools because they are smart contracts. You can track if something onchain has changed through tracking function calls and event logs (emitted during function calls). Many times this data is not shown in any app frontends, and so teams have to set up separate monitoring infrastructure just to keep up. There is probably $300m+ of cumulative funding in these infra startups alone, such as Hypernative and Blockaid. Many free resources exist as well like the Yearn monitoring Telegram group that covers their positions. There are no required email/letter notices, which together with the lack of good app UX for monitoring leads to a lot of overlooked changes.

For "approvals and time" this is where 99% of the true complexity of crypto lies. Because these pools are just code, they are very easy to build on top of with other contracts. For example, you may have an "allocator" role on a vault template, but it could be assigned to a wallet, a multisignature wallet (like a Safe), or a whole other contract. That other contract could have its own set of roles and functions that are not considered by the protocol pool implementation at all - because all the pool sees is "some address with some valid role is calling this function." These nested contracts are also usually set by the launcher of the pool, in follow up transactions.

I call these nested contract management structures "dependency graphs" which split out the lifecycle of any change into more steps/functions and adds more counterparties. This looks like a graph, starting from a single contract and then expanding outwards:

Let us take the Steakhouse vault in the graph above. The Morpho Vault V2 template contains a "sentinel" role that can call the revoke function to block specific actions in the vault taken by the "allocator" role. Steakhouse after launching the vault has given that role to a "revoker" contract which then makes the only caller an Aragon DAO contract which then has a LockToVote plugin attached which allows all holders of the Steakhouse vault share token vote to revoke (with voting power based on the shares held). Some of these dependency patterns are shared across different templates, but there are easily hundreds of different enumerations out there today.

While the implementations can differ a lot, we can still at least cover the range of most popular patterns for our operations categories:

A lot of the sprawl from these implementations comes from trying to satisfy both technical and legal requirements. Allowlists and hooks get more ties to sprawling KYC/KYB solutions and transfer agent restrictions. Issuance/redemption has become more async while teams try and match the T+1/3 day periods that traditional finance takes and also as vault strategies get more complex.

I've combined the two hottest topics, custody and allocation, into one row because whoever has the ability to move the underlying tokens for a strategy effectively has custody of them. This becomes a new problem as more securities and commodities are tokenized. A vault holding them could raise the question of whether its curator is an investment adviser, or the vault itself an investment company. An adviser must keep client funds and securities with a qualified custodian under Rule 206(4)-2, such as a bank, a broker-dealer, or a trust bank like Anchorage Digital. A registered fund must use a custodian allowed under Section 17(f) of the Investment Company Act, typically a bank like BNY or JPMorgan. Neither definition was written with smart contracts in mind. Vy Le, Veda's General Counsel, asked the SEC and CFTC in March to recognize vaults that meet certain guardrails as satisfying these custody requirements in her letter.

You'll notice I skipped the "configuration" operations row, because all the ways in which the dependency graph is layered represents configuration. The most important distinction in configuration is how contract upgrades are treated. In the dependency graphs above, the yellow arrow on nodes means a contract is upgradable. If it's green, then you can at least trust that that part of the configuration is not going to change (though if it is tied by a role they could assign the role to another contract, effectively changing the rules again).

From Code to Law

The remaining elephant in the room is which registrations crypto protocols and all related counterparties need. There are dozens of letters to/from oversight bodies like the SEC/CFTC on what should be registered as a security, RIA, RIC, CPO, CTA, broker, etc (good summary here). I will not opine on how the law gets modernized, as I'm not a lawyer. But I do know that institutional adoption of crypto will come from speaking a shared language of finance and law that is easy for everyone to understand. And "adoption" means that institutions do more than just operate a fund that is then tokenized by some crypto startup - they should be structuring, operating, and allocating to crypto products themselves.

By driving forward education using frameworks like TCO, we can avoid drowning institutions/regulators in a sea of code and misapplied finance terms that lead them astray. Here is the complete framework we've walked through:

Herd has been building the intelligence and transparency layer needed for teams to understand the structures of any crypto product and execute across them safely. For example, Herd addresses the "notice" problem by helping teams keep track of what monitors to set up (metamonitoring) across the balance and dependency graphs within whatever monitoring system your team uses.

If your team wants a private walkthrough of how everything works onchain or learn to research and due diligence any token/protocol, reach out to schedule a time at andrew@herd.eco or andrewhong5297. We already work with dozens of teams like Steakhouse, Maple, Centrifuge, and Monad.

• All reports I saw implied this was a very simple exploit with an "accounting bug" - I knew this protocol team was reputable as they had previously worked with Maker/Sky, so there should be no simple exploits.

• The hack traces centered around a few tokens that had nothing to do with the protocol itself - not some weird synthetic/tranche/vault issuance bug. How was this token identified by the attacker but no one else?

• There was not enough idle liquidity initially in the vault for the attacker to withdraw $6m but they somehow got around that. Vault withdraw-able liquidity is often managed by the curator, not the depositor.

• The profit came from two vaults, not just one. No explanation I saw covered clearly why the second vault was impacted.

It became quickly clear to me that there was no bug in the contracts and no operator keys phished - the losses were due to vault design working exactly as intended. Vault contracts are simple on their own, given the ERC4626 standard. But their natural growth over time leads to compounding price and liquidity risk exposures (and code/operations issues) that when manipulated together can cause large losses. And the build up of these risks is not a 0-day or a sudden upgrade/change, it comes over months and years of managing positions and evolving protocol patterns.

All of today's vault face the same risks, that will only get worse as tokens and markets get more complex. So, it's important for us to collectively understand why and how this exploit happened.

All this analysis is performed with Herd, using our DoubleClick and MCP/CLI products.

You can find the full technical report with addresses/transactions linked in the agent forum post.

If you want visibility into all branches of your vaults and portfolios, with an agent to help you research and monitor positions - then reach out on twitter, telegram, or at andrew@herd.eco.

Part 1: The Stowaway in the Ark

To set the stage, the two vaults in question were launched on Summer Finance by the risk curator Block Analitica in Feb/May 2025. Curators are the ones who manage all strategies and positions in these vaults.

• Lower LVUSDC: a "lower" risk vault that had $9.68m TVL pre-exploit

• Higher LVUSDC: a "higher" risk vault that had $482k TVL pre-exploit. This is not a risk tranche situation, these are two different vaults.

Both vaults have been live for a little over a year at this point. All positions in the vault are managed in "ark" contracts which are individual solidity contracts for transferring and accounting (pricing) specific assets - be it a Morpho, Silo, or Gearbox vault or just plain USDC. This is a very common vault pattern typically called an "adapter". Across both vaults, there are sixty-seven arks set. Many of these are also vaults, which then have their own branching allocations depending on the protocol.

If we traverse across all of the child branches of the sixty-seven different arcs the two vaults allocate to, we'll find over 500 different underlying positions. Many of these child branches have correlated allocations as well, like 12 different arks allocating to the same WBTC/USDC market on Morpho.

Block Analitica put out a post after the exploit explaining that they were never responsible for removing arks because it's a governance role that they don't have. While technically true, this is a common risk from

The balance sheet graph is a tangled mess that is barely legible in Herd. Those two big nodes on the right-middle side are the LVUSDC lower and higher vaults. To the left of them, we have all of the arks and then all of their subpositions. To the right, we have the holders of the vault share tokens.

Hidden three levels deep within one ark under the lower vault in this graph is a Silo vault (vgUSDC) that is lending to a Silo market against nbxUSD-155 which is an xUSD wrapper. This is from stream finance, which blew up in late 2025. No borrower is going to repay their loan to get their xUSD back since its valueless now, so this vault is effectively illiquid (no one can redeem for USDC since its lent out in Silo). However, because of the high interest rate that continues to accrue in the market the value of the original $32.8m allocated by Silo vault into the market becomes worth $488m. So vgUSDC depositors are rich! They just can never withdraw it.

Naturally, vgUSDC holders are gonna wanna exit ASAP, and are forced to sell on a DEX instead. This creates a very imbalanced pool that then warps the exchange rate such that buying vgUSDC is very cheap compared to its actual net asset value of totalAssets()/totalSupply(). Five wallets swapped USDT for xUSD ($14.5k spent) and then swapped through the imbalance balancer pool for vgUSD valued at $7m (but again, totally illiquid). This was done between March 29, 2026 and April 9, 2026.

All this sleuthing work required knowing how to navigate a balance graph of vault dependencies, and finding a way to acquire an illiquid asset cheaply. The Block Analitica curator had added about 1-2 arks a month to the vaults over the last year, and never removed any arks. So even after the Stream Finance crash last year, they didn't realize that this exposure remained in an ark. The people at Block Analitica are very smart and have a long history in DeFi, so again this looks easy to spot now but only when its in a graph like this. If you are clicking through Etherscan/Debank or trying to write SQL queries you will very simply miss these dependencies.

And remember, only the lower vault had exposure to vgUSDC. The higher vault is not allocated to that ark. With this context, we're ready to go through the actual exploit.

Part 2: Attacking the Fleet

First, a conceptual lesson for how the hack works. I want to first emphasize that there was not a single bug in the Summer Finance code. This was a donation hack - a method we've seen before (1) (2), where some asset price is inflated by transferring tokens directly into a protocol instead of a normal deposit/mint. If pool A has 50 USDC and has 50 shares, then each share is worth $1. If I then transfer 50 USDC directly into the pool, the contract totalAssets() function will take balanceOf(USDC) and get 100 USDC and value each share at $2.

A vault holds many different tokens, so if you knew one of them was about to worthless you could:

1. deposit to get shares at the current price

2. transfer your worthless token to the vault to increase the price

3. redeem your shares at the inflated price

And that's exactly what the vgUSDC is for. The execution of steps is:

1. Obtain majority ownership of the vault shares

2. Transfer vgUSDC to the silo vault ark directly, inflating the totalAssets by $7m

3. Redeem your full ownership of the shares. Because you were a majority owner, you gain proportionally the most from the totalAssets inflation.

Now, here comes the second problem for the attacker. The lower vault had only $1.6m of withdrawable liquidity. So even with the $7m of profit, you'd only make it out with that $1.6m - this isn't ideal.

To get our answers, we have to look through all the traces of the hack transaction (everything below was done in one atomic tx).

Why the flashloan of $65m?

The lower vault had $9.6m in TVL. The $65m flashloan (one block loan) represents 86.4% of total shares when deposited, and if you then take the vgUSDC donation of $7.12m * 86.4% you get $6.15m.

This tells us exactly how much liquidity they thought they could get out.

How was the available liquidity increased?

Again, curators (Block Analitica in this case) are usually in full control of the available liquidity in their vaults. They will plan to have some percentage of the vault that is liquid so that depositors should have no trouble getting out.

However, Morpho V2 Vaults added a special new function to give users more control over liquidity. This is the forceDeallocate function. This allows ANYONE to pay a fee in shares of the vault (set by the curators of that vault) to force liquidity from an adapter/market into idle liquidity.

In the hack tx, we see the attacker depositing a minimal amount into the Morpho vaults that the lower vault arks are allocated to, and then calling forceDeallocate to move hundreds of thousands of dollars (sometimes millions) into idle liquidity as USDC. Some vaults don't have any fee set (like KPK prime) so they didn't even need to deposit to get shares.

These are the four Morpho vaults deallocated from by the attacker, and their set penalties. These vaults did NOT face any bad debt or exploit, they just lost some liquidity. The penalties are a small cost to pay to then be able to withdraw this liquidity later. With that, the total withdrawable liquidity on the lower vault is ~$5.64m. The traces tell us they made $6.1m from the lower vault, so we're still short about $500k. Where did that last bit come from?

There was one other ark token spotted in the traces. This was a tokenized strategy vault (tsvSummerfiUSDC), deposited into before the lower vault deposit. This strategy deposits into LVUSDC itself, so the $490k deposited here goes right back into the attackers pocket in the withdrawal, leaving only 21k shares of the lower vault in the attackers wallet.

This $490k nets out so their actual profit from the lower vault is $5.64m.

What about the higher vault, how was it exploited?

Well who holds the tsvSummerFiUSDC token? Its allocated to by an ERC4626ark held by the higher vault. So the higher vault actually IS allocated to the lower vault.

If you've been following closely then you already know what's coming:

1. They deposited into the higher vault with some of the lower vault redeemed funds (much less since the TVL was already much smaller only $482k)

2. They transferred the tsvSummerfiUSDC into the higher vault, inflating the value through that ark (the ERC4626ark)

3. The fourth Morpho vault they deallocated from earlier provides the extra $283k of liquidity on top of the $116k of available liquidity

4. Redeem out for $399k profit

That token's value also would have been inflated by the gain in lower vault's total assets, since the deposit came before the vgUSDC transfer to the ark. However this token contract's totalAssets must be manually updated by a keeper through a report() function, so it wasn't manipulated in this pass.

With both these redemptions they can now repay the flashloans and the attack is over. $6.1m in profit made (on $14.5k in xUSD costs).

Part 3: Rafting Back to Shore

After the hack, the team paused all contracts and also performed a sweep transaction to move all of the vgUSDC out of the ark - effectively crystalizing losses for depositors as bad debt. In this case, the majority of the exploit value hit only one large depositor who got into the vault with an initial deposit of $7.8m that is now worth $3.13m. The rest of the impact is partially taken by the higher vault and a couple hundred other very small depositors. Luckily, there were no other vaults wrapping these two.

Summer Finance has released their own postmortem with a higher level explanation of everything here on their Twitter account.

Interestingly, in the sweep transaction this 3/5 safe was able to grant all the permissions necessary to arbitrary move funds all in one go, no timelock or anything:

This kind of permissioning ends up raising even more eyebrows, since most of the exploits we've seen this year have been due to hacked keys/safes. So, it's always important to understand the roles and permissions across contracts too. Here's part of the dependencies graph for the lower vault:

And this is just on the lower vault token contract itself. Think about all the child arks and those 500+ positions again - can you imagine then researching and monitoring all the deps on top of those, which can constantly change? Welcome to the new DeFi that we've created.

The Biggest Risks for the Next Trillion Dollars of Vaults

It's unfortunate to see great protocols/teams suffer losses, and it hits doubly hard when they already faced bad debt on another vault due to Stream finance falling over last year. There are always multiple waves to exposure, the pricing and delays/operations of markets during stress as well as follow on exposures which can take weeks to months to fully materialize (as we see here today).

Our team has spent the last year analyzing the full graph structures of hundreds of different tokens and vaults, and there are four obvious patterns gaining traction that increase the risk of this happening again:

• Every token is now a vault: We're seeing more and more "vault" wrapping "vault" like structures. Looking at apxUSD is a good example of how many levels of wrappers you can end up with that all have different behaviors. There's always more yield to be had, with RWAs, risk tranches, interest rate mechanisms, etc. I just call these all "tokens" now because every token is just a vault. USDS is a vault. USDe is a vault. This sixty-seven ark type of structure is becoming more common.

• Pricing is not just a single oracle problem: Vault accounting will continue to get more complex given layered wrappers. A lot of teams are still spending their times on oracles, but in most real depegs the oracles will go stale and are mismanaged. And then its up to the downstream accounting to see what fallbacks and other pricing options have been implemented where to keep the protocol/vault alive.

• More counterparties and timings are involved in todays tokens: A lot of tokens now have async redemptions and queues, so accounting matters even during the time between requesting and claiming a redemption. Even more new attack vectors will come from this.

• Everyone wants instant liquidity facilities: There are tons of teams working on liquidity facilities for different types of assets, providing backstops to markets/vaults. As we've seen with flashloans and now force deallocations - all instant liquidity is a potential exit vector for attackers.

These risk patterns are only going to get worse over time as more assets and money come onchain. I would argue that these risks are no longer the "security" risks we've traditionally thought of but now proper financial and economic risks. The same that any large bank or fund would have to responsibly manage. I believe this is the next wave of risk management we are about to face as an industry - and it isn't just a code problem.

But we are hiding all the complexity in the shadows, behind that cute one click button/number input that says "7% yields here!" Then pointing at curators when things go wrong. Vaults are gaining more and more mainstream distribution now with stablecoins and fintech deals, on protocols and platforms that do not want to take on the burden of assessing any of that risk.

At a time when everyone is leaning into the chaos of complexity to chase more TVL, I believe all players need to recognize our responsibility to depositors and the industry at large.

I don't care if you are issuer, curator, allocator, protocol, or an app/aggregator - transparency is everyone's responsibility. Let's do better. We should set the right reporting standards ourselves, before the SEC or anyone else does it for us. Especially if the risks are hard to continuously find even for the top curators in the space.

Again, all analysis is performed using our DoubleClick and MCP/CLI products.

I'm around if you want to chat, you can reach out on twitter, telegram, or at andrew@herd.eco.

Well, this time it was the price that was variable (as bitcoin today crossed below $60k):

However, what piqued my curiosity is the effects on all the tokenized versions of it. When price is crafted in smart contract code and not just a simple order book, you will observe all kinds of drifting behaviors.

There are three main tokens that are backed by STRC:

• STRCx ($200m FDV): Strategy PP Variable xStock is a tokenized security that provides on-chain economic exposure to Strategy Inc.’s variable-rate perpetual preferred stock. The asset is backed 1-to-1 by the underlying preferred stock, which is held in traditional custody by a regulated issuer.

• apxUSD ($300m FDV): Synthetic dollar backed by a basket of preferred shares, which is 80% STRC and 20% cash "equivalents". Yield is passed through to apyUSD in a vault that wraps apxUSD.

• sUSDat ($80m FDV): Yield-bearing vault token built on the ERC-4626 standard. It represents a user's share of a managed pool of digital credit exposure, where yield is generated from Saturn's STRC holdings and passed through to stakers automatically. It's 90% backed by STRC and 10% by USDai which is backed by M0 stablecoins.

We will be breaking down how each token builds yield and leverage through different wrappers/protocols, and then the exposure and pricing chains derived from that graph. ApxUSD is the most complex/highest value graph so we will focus there.

All of the following analysis is performed with Herd, using our DoubleClick and MCP/CLI products. Please get in touch with the team for access and/or a demo.

None of this is financial advice.

How the apxUSD graph is structured

The word "graph" here refers to our "Balance Sheet Graph" product, which you can read more about in this article. In short, it shows recursively what all the assets backing a token are as well as where it is being used/wrapped after issuance (liabilities). For apxUSD, that graph looks like this:

On the left hand side we can see their reported reserves (source). There are levels to transparency, and we have no way of really knowing where they are holding these funds or all their team wallets unfortunately. The DoubleClick agent has done some sleuthing to find the STRCx reserve which accounts for roughly 1/3 of their reported STRC position, in an 0x37b0779a66edc491df83e59a56d485835323a555 safe. This safe will come into play later in this article.

The rest of the cash/POL/inventory holdings can be partially tracked onchain on the liabilities side actually, as we will find many Apyx team wallets/safes holding positions throughout other protocols where the token is used. If you're unfamiliar with "wrapper" tokens and defi protocols, I highly recommend reading this overview of how and why tokens are wrapped first. When I say a token is "utilized" I mean it is being deposited into one protocol (smart contracts) and then a new position "wrapper" is issued/tracked on top that can be utilized again.

The Yield Wrapper: apxUSD and apyUSD

The most basic wrapper in our graph is depositing apxUSD into a vault that gives you apyUSD in return. If you look at the right side of the balance sheet graphic above, you'll see that about 45% of apxUSD supply is in this vault. This is because you want one stablecoin token that maintains a $1 peg, and the another token that can accrue rewards as yield. Yield accrues through three steps, detailed below:

This stable and staked/yield token combo is very common practice in crypto, see USDS/sUSDS, BOLD/sBOLD, cUSD/stcUSD, etc.

In this case, both apxUSD/apyUSD are utilized in a lot of the same protocols, with the primary difference in secondary market (DEX) liquidity. There is a single DEX pool for apyUSD that is in Curve pool as an apxUSD/apyUSD pair (~$3m of liquidity), while apxUSD has Curve, Uniswap, and Pancake pools (~$11m of liquidity). The depth of liquidity is actually half that value since half the pool is in apxUSD or apyUSD, so as you can see there isn't actually that much liquidity to sell in these pools.

The main exit mechanism from apyUSD to apxUSD is through the UnlockReceipt contract which is seen carrying $40m of tokens waiting to get out. It has a fee paid for exiting early (3.4% fee if after 3 days, decays to 0 in 20 days). Then you still have to sell it on a DEX to get USDC back - but there are also a few cases of large holders doing OTC swaps with the Apyx team directly for STRCx.

Tranches and Zero-coupon Bonds

Now that we have a yield source, people will want as much of that yield as possible as safely as possible. This happens primarily in two steps:

• Risk Tranches: To protect investors in the case of a downside in STRC price, apyUSD is deposited into protocols like Royco to create a junior and senior tranche. In the event of a price drop, the junior tranche eats losses first (all the way to 0) before senior tranche does. This is still a fairly new mechanic so not may tokens have picked it up yet. Only $5m of the $125m of apyUSD is allocated through tranches.

• Zero-coupon Bonds: This is the most popular tokenization strategy in crypto now, which is placing a yield bearing token into Pendle to get a principal and yield token (PT/YT). the PT starts off with a discounted future value built into it, and YT starts at 0. These have set maturities, so at the time of maturity one PT = one underlying token and the YT = the yield realized during the duration. Most of apxUSD/apyUSD directly goes into Pendle.

To learn how to read this graph, consider each dark gray node a "manager" which could be a protocol or just a wallet. Each light gray node is a "position" issued/backed by the manager. So the further right we go, the more nested the positions are. But they can still be unwrapped all the way to get back (left) to apxUSD.

These all obviously offer varying yields with different risk profiles based on time and liquidity. Now the missing piece of the puzzle is leverage.

Lending Markets and Vaults

If you believe that apxUSD is stable and apyUSD is monotonically increasing with dividends, then you would consider it safe to borrow USDC against it to then utilize somewhere else. This is made possible through Morpho markets, which define individual pairs of collateral and borrow tokens like a USDC/apyUSD market (deposit apyUSD as collateral to borrow USDC). Interesting enough, there are plenty of apxUSD/apyUSD* variant markets too.

That first yellow node is the Morpho Blue singleton, and then each position coming off of it is a different market pair. To the right of that are the managers supplying/borrowing from those markets, with the ones that are multiple hops being Morpho vaults belonging to different curators.

Vaults allow users to deposit USDC that they then lend out to different market pairs or hold PT exposure directly. This takes us to the end of the graph (of course you could then keep iterating to see who the largest suppliers of those vaults are and what else they supply to, but we won't do that here).

Fun fact, one Safe accidentally supplied to a Morpho market buts with the behalfOf set to the Morpho Blue contract itself so those funds are lost forever (or until liquidation). It borrowed most of it back out for now.

Understanding Exposure and Pricing

Most holders and suppliers have gotten out over the last few weeks, but some of the primary ones were vaults like Lulo, Termmax, Beefy, Hyperithm, and Apyx team vault. A majority chunk of lending supply and DEX liquidity actually comes from Apyx team safes - remember the inventory/POL liquidity on the assets side from the start of the article? Well, here is where it shows up.

When the depeg first occurred the first week of June, the team had to move fast to try and maintain the peg during user outrage. Diversity of liquidity providers matters a lot when you have a token/graph this complex, since your exits could be locked out very quickly!

Here's a timeline of the Apyx team activity from known team wallets:

On top of counterparty exposures, you also have pricing difference across ALL of these positions. Here is part of a table detailing some of the main feeds, the current price, formula, and who/how it can be changed.

What Happens Next?

Once you've gone deep on the graph above and the counterparty/price exposures that play a part in scenario modeling, you can make some informed decisions. It's worth taking a look at saturn's sUSDat graph too, which has similar structures all around just less POL and instead actual stablecoin backing with M0. and then they use Strata for tranching instead of Royco, but similar risk profiles.

If you believe that STRC is going to recover, how you choose to arbitrage or go long depends on your expected recovery period. Here's some agent analysis on opportunities, again this is not financial advice:

• Best convex trade: PT-ROY-JT-apyUSD 5NOV2026 or spot ROY-JT

  • ROY-JT is around $0.705, so par recovery is ~+42%.

  • PT-ROY-JT spot is shown around $0.5503, so if the underlying junior recovers enough before/through maturity, the upside is much larger, ~+82% to $1 before fees/slippage.

  • The catch: this is path-dependent. Royco’s 30-day window is not price smoothing; it is a recoverable-loss window. If losses crystallize before recovery, then any gains after that go through the normal utilization yield split between junior and senior.. There are 11.5 days left (as of June 27th).

• Looks good but is NOT the same: jrUSDat

  • It is the clearest “STRC recovery levered tranche” in the set. jrUSDat is around $0.3464, structurally ~6x exposed because it is the first-loss piece under srUSDat. However Strata does not have Royco’s 30-day recoverable-loss window. So if STRC/sUSDat NAV later recovers, that recovery is treated as new tranche economics flowing through the waterfall, not a rewind of the old loss. Senior gets priority/protected yield first; junior only gets the residual upside after senior claims, fees, and coverage mechanics.

• Cleanest direct thesis: STRCx

  • STRCx has underlyingPerShare = 1.05182045, so STRC at $100 implies about $105.18/STRCx share-value unit. Against the graph market slot of $77.04, that is roughly +36.5%

Thanks for reading, and stay safe out there :)

The Herd team will be in New York during ETHConf June 8-14, we'll be co-hosting an event at Chelsea Piers on the 9th. RSVP here!

The Death of One-time Token Due Diligence

Tokens are increasingly becoming the centerpoint of complexity instead of protocols, which have become more modular and configurable. The surface area of a given vault can easily balloon to 300+ contracts with constantly changing operations across underlying tokens (rotating EOAs, upgraded contracts, new bridges, etc).

In the first five months of 2026, we've seen the consequences of this bloated operational complexity with almost a billion dollars worth of hacks. Notable hacks include Resolv in early March (USR mint hack), then Drift (multisig hacked) and KelpDAO (rsETH bridge hack) in April. Hackers would then route the hacked tokens through other protocols to gain exit liquidity, creating contagion affecting billions of dollars of other tokens in places like Aave.

Throughout this difficult period, two questions have been asked by everyone:

• How can I continuously due diligence these tokens, instead of one time reviews?

• What is the contagion to my portfolio from a market shock/hack on another token?

This can be measured with the right risk models, which are typically required and regulated in traditional finance for examinations and reporting. However, we don't have any standards or legal frameworks for this in defi yet. Most the tooling we have has traditionally been security focused, with transaction/address screening products. Some expert teams have worked with protocols like Aave on one-time research and analysis of tokens, but this is no longer enough.

You can think of modeling risk like navigating a map, where factors like construction, weather, and traffic conditions all affect your decision making. You could go off of just what you see and feel on the road, but your visibility into the pathways will be poor. We decided to start out by building out the token map. But every token is structured completely differently - there is no "ERC20" for all the composable dependencies of a token. So, we leveraged our own MCP/CLI and built a research harness around it that can map out and maintain an "asset liability graph" for any token.

Herd's Token Balance Sheet Graph

Every balance sheet has two sides, assets and liabilities. We define assets as all the positions backing a given token. Liabilities are the issued token itself, and what protocols it's being used in and re-wrapped.

This approach isn't inherently novel, and a version for MakerDAO/DAI (now Sky and USDS) has been written about before. Having a balance sheet modeled out is required to then model common metrics such as a Liquidity Coverage Ratio (LCR) and Capital at Risk Ratio (CARR). The Federal Reserve then comes in to test bank models with Comprehensive Capital Analysis and Review (CCAR), setting different stress assumptions each year.

Our key difference in approach is that we recursively breakdown every position (line item) to get its underlying positions and who manages them to create a balance sheet graph. Now, let's look at an example graph we built with our agent.

iUSD is a yield-bearing stablecoin issued by InfiniFi. Here's a portion of their token graph:

Each graph also comes with an aggregated balance sheet view that can be exported as a json/csv/pdf. All data can be queried live, and the agent has many monitors set for continuously researching changes in underlying positions/managers.

Both sides of the balance sheet are sources of contagion risk. On the asset side, ~43% of iUSD's reserves are off-chain Fasanara Capital positions. If there's a credit event, those can't be liquidated onchain. On the liability side, ~52% of the supply is re-deployed as siUSD into Morpho, Pendle, Silo, and Euler, with another ~33% locked in weekly tranches (liUSD-1w through 13w). A freeze on the assets doesn't stay contained, it creates redemption pressure that cascades through every protocol holding siUSD downstream. Our graph shows you exactly where the shock enters and how it travels.

Building Transparent Risk Models For Every Token

To create risk models, you need to simulate onchain functionalities across contracts with different actors. The balance graph gives us the starting "map" to explore, but it doesn't capture all possible paths and counterparties involved. Our agent can double click into each node and edge in the balance sheet graph and further research sets of functions for managing everything from deposits, redemptions, and configurations.

Here's a function graph that shows who can call the mint function on USDC on ethereum (a few EOAs and then a few Circle bridge contracts):

Together, the balance sheet and function graphs give you everything needed for an accurate exposure risk model. Both need to stay live as positions get rebalanced, contracts are upgraded, new managers are added. The agent monitors and maintains every layer continuously, flagging changes and tweaking model assumptions as they happen.

Our product directly answers both earlier questions. For continuous due diligence, the graph is maintained automatically by agents with human review - no more one-time reviews that are stale the next week. For contagion, when KelpDAO's rsETH bridge was hacked in April, any token with rsETH in its balance sheet graph had a traceable exposure. With the graph you see immediately whether that shows up as a liquidity crunch during a run, bad debt for which depositors, or cascading liquidations as sell pressure pushes correlated collateral below LLTV.

Work with Herd

At Herd, we've worked closely with vault curators like Steakhouse and Chaos Labs using our Explorer and MCP/CLI. This new product is the next evolution of leveraging AI to manage the complexity of crypto at scale while remaining accurate.

We're currently working with a few design partners on custom risk models for their tokens and portfolios. We'll have more to reveal soon and are giving out beta invites to anyone actively issuing or managed tokenized assets. Subscribe to this newsletter to get our updates, I'll be posting research into interesting tokens each week as well.

If you want to model token/portfolio risks or have ideas for working together, please reach out to andrew@herd.eco (andrewhong5297 on twitter/tg) for a product demo.