# The TCO Framework: Translating Crypto Products into Institutional Finance *It's time to translate smart contracts and their operational lifecycles into concepts that are understandable to the finance/legal industry at large.* By [Herd Labs](https://paragraph.com/@herd-labs) · 2026-10-21 --- Code is (not) Law ================= 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. Subscribe 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](https://www.sifma.org/resources/market-practices-model-documentation/mra-and-gmra-documentation), 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](https://www.ycombinator.com/safe) as a kind of standardized form. **We are going to refer to these as "templates" from here on out.** ![](https://storage.googleapis.com/papyrus_images/c0854ea7093260a7bcc1b5f3988f0b8da5ced75b5a3303843e9b0ebf1767dcec.png) [Example Filled MRA Agreement](https://www.sec.gov/Archives/edgar/data/823277/000082327718000065/ex1040masterrepurchaseagre.htm) 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](https://www.nytimes.com/1982/06/16/business/drysdale-securities-out-of-business.html). 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](https://www.lsta.org/content/form-of-credit-agreement-investment-grade-term-loan-feb-27-2023/)) 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). ![](https://storage.googleapis.com/papyrus_images/97bfd7849dcda0a19d981ca39dd74613a216e670662dc77a7d15e69ca4ba149f.png) There are teams like Moody's who are scoring these conventions over time, like [Covenant Scoring](https://ma.moodys.com/rs/moodys/images/Database%20FAQ.pdf) as these covenants can materially affect the risk level of a given loan. ### 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: ![](https://storage.googleapis.com/papyrus_images/99be5f4a50c08712b2087e8fd3cafd85333b4a2550a485193d9b1b63c6635cdf.png) A generic US open-end mutual fund registered under the Investment Company Act of 1940, filing on Form N-1A, after its registration statement is effective. 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](https://www.crystalfunds.com/insights/style-drift-and-its-considerations-and-consequences/) 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. Subscribe 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.](https://read.cryptodatabytes.com/p/unwrapping-defi-the-evolution-of) 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. ![](https://storage.googleapis.com/papyrus_images/86f59d22148482b3ab32a6d2d8301dff14bd5eb3dcb2adee785fbe16b092558f.png) [The function used to launch Morpho Blue pools](https://herd.eco/ethereum/contract/0xbbbbbbbbbb9cc5e90e3b3af64bdaf62c37eeffcb/functions/0x8c1358a2), 13 created the last 7 days (10/2/2026). You can see one example in the screenshot on Herd with the 5 "terms" used in creation in Input Args of "marketParams" 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](https://paragraph.com/@herd-labs/measuring-defi-contagion-through-token-wrappers-and-protocols) of contracts/counterparties involved in launching a leveraged loop of a single asset (USDe) to maximize risk adjusted returns ([Twitter explainer here)](https://x.com/andrewhong5297/status/2096598959703634212/photo/1): ![](https://storage.googleapis.com/papyrus_images/b891688d2323a7ee0a59455f63c67965e0060a682968e1a2969c5b1bddc1cbe8.png) [Herd Balance Sheet Graph](https://herd.eco/doubleclick/tokens/graph/ethereum/0x3d7d6fdf07ee548b939a80edbc9b2256d0cdc003) showing holding and backing relationships across protocols to create a tranched leveraged loop position for USDe. Welcome to onchain structured finance! ### 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. ![](https://storage.googleapis.com/papyrus_images/18a224b9c72ebc0191aeefac935f28f96290e6a117fb1235e4cc69e217d18c4b.png) [Twitter link here](https://x.com/andrewhong5297/status/2092174022620385528) , this Herd forum post explains the full timeline of the market launches as well as then the borrower liquidations due to the TWAP oracle being attacked to bring borrowers below the LLTV. 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)](https://github.com/Keyring-Network/d-simm/blob/master/dsimm.pdf) 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](https://x.com/LlamaRisk/status/2100658265822765169)) or discussions around Rule 611/NBBO requirements as it comes out ([Allium letter](https://www.finra.org/sites/default/files/NoticeComment/Allium_FINRA_5310_Letter_Notice%2026-15.pdf?ref=allium.so)). 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](https://app.morpho.org/vaults) 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: ![](https://storage.googleapis.com/papyrus_images/5711386b06189566c387b58b82faf8b263e4f7ce8563d35e4975ec53dc656265.png) Again, these are NOT official, but we can triangulate the requirements based on public information 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](https://governance.aave.com/c/governance/new-asset/9) 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](https://www.hypernative.io/) and [Blockaid](https://blockaid.io/). Many free resources exist as well like the [Yearn monitoring Telegram group](https://curation.yearn.fi/monitoring/) 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: ![](https://storage.googleapis.com/papyrus_images/a40ed363f2972b16877ffc9303a2f9c16e58065f2a653f69c4b4fa5ba799bc52.png) [Herd Dependency Graph for the steakUSDC v2 Vault.](https://herd.eco/doubleclick/tokens/dependency/ethereum/0xbeef088055857739c12cd3765f20b7679def0f51) Each edge is either a permission (who can call what functions) or a read (where data like a "price" comes from) and each node is a wallet or contract. On a scale of 1-10 of complexity, this is like a 4. Some graphs have hundreds of operational nodes. 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](https://eyJpdGVtcyI6W1siZGRnIiwiZXRoZXJldW0iLCIweGJlZWYwODgwNTU4NTc3MzljMTJjZDM3NjVmMjBiNzY3OWRlZjBmNTEiXSxbImMiLCJldGhlcmV1bSIsIjB4NzYzMDNkNWVmMmVmZmI2YjQ4OWY2ZDkwNTFlNmI0MDk5NjJhYjcxNSIsImZ1bmN0aW9ucyIsIjB4MGI0NjdiOWIiXSxbImMiLCJldGhlcmV1bSIsIjB4NzYzMDNkNWVmMmVmZmI2YjQ4OWY2ZDkwNTFlNmI0MDk5NjJhYjcxNSIsImZ1bmN0aW9ucyJdLFsiYyIsImV0aGVyZXVtIiwiMHgwMjcyM2JiMDkyZjlmNjIxYzI1NWUxMDVkMjJhYzY3NDNmM2E3OWVjIl1dfQ) 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: ![](https://storage.googleapis.com/papyrus_images/ee1fc2a16ee3257cd81182386e4f9d28c003d0571cea497207d94ce0f38af94e.png) These examples all come from real protocols like USDC, Coinbase, Sky, Uniswap, Morpho, Steakhouse, Gauntlet, Veda, Centrifuge, Infinifi, Royco, Strata, Cap, EAS, Opacity, Midas, and TRM/Predicate. 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](https://www.sec.gov/files/ctf-memo-coalition-tokenized-markets-thorn-run-partners-llc-wisdomtree-inc-janus-henderson-investors.pdf) 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](https://www.law.cornell.edu/cfr/text/17/275.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](https://www.sec.gov/files/sec-cftc-harmonization-initiative-written-input-veda-tech-labs-inc-032326.pdf). 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](https://ethereum.org/developers/docs/smart-contracts/upgrading/) 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). Subscribe 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](https://www.sec.gov/files/ctf-written-input-salman-banaei-plume-network-092126.pdf)). 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: ![](https://storage.googleapis.com/papyrus_images/62f15be63492ae6181e3f21571fe546173dd310985aa88d53f22ade01fa472a3.png) 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](mailto:andrew@herd.eco) or [andrewhong5297](https://x.com/andrewhong5297). We already work with dozens of teams like Steakhouse, Maple, Centrifuge, and Monad. Subscribe --- *Originally published on [Herd Labs](https://paragraph.com/@herd-labs/the-tco-framework-translating-crypto-products-into)*