These are my independent thoughts and do not necessarily represent the views of my employer.

Tokenization = putting an asset onchain

PYUSD is a tokenized dollar liability. The special part of the liability is the token part, which is its new form factor. The underlying dollar corporate obligation doesn’t change whether PayPal issues it as a token or as a Venmo or PayPal balance. Generalized, if you tokenize something of you value you’ll have something of value, but tokenize junk and you’ll still have junk.

Tokenized Money Market Funds have not found PMF

Tokenized Money Market Funds (”TMMFs”) have added ~$6.4b in supply in the past 18 months while stablecoins have added 17x that amount. This seems like poor performance for an asset class that’s supposed to be a drop-in replacement. Additionally, a lot of TMMF issuance is subsidized by chain foundations, which means the organic growth of the class is even smaller. Why might that be? Hint: it has to do with my first observation. What’s the difference between BUIDL and USDC on the asset side? Now how about on the token side?

A security is just a legal contract

Equity is an entitlement to partial ownership of a company. Debt is a a legal obligation for future repayment. Legal contracts are secured by the state, the rule of law, and a legal system. Are you unclear about what you own? Ask yourself if you own a legal obligation to some future asset or performance.

A token is just a smart contract

Because I learned about blockchain from Bitcoin, I didn’t realize that an EVM ERC-20 token is not a literal bearer asset in the way I thought of a Bitcoin UTXO. In the Ethereum account model, tokens are smart contracts that record each wallet’s ownership. Understanding this is key to imagining the programmability that can make tokens special form factors for value.

DeFi adds the most value in the worst markets

Thanks to Brendan Malone for teaching me this. A startling number of people want to tokenize stocks. Why? The U.S. equities market is one of the best-regulated, most-liquid markets in the world (perhaps surpassed only by the market for U.S. Treasuries, lol). The barriers are higher and the improvements smaller for U.S. equities vs. other asset classes. Perhaps it’s wiser to start with a market that is inefficient, fragmented, and antiquated.

Understanding truths about the nature of assets and tokens can identify promising areas of investment, research, and innovation. Hopefully this post has helped.

These are my independent thoughts and do not necessarily represent the views of my employer.

The problem to solve

As part of my work, I regularly use LLMs to help with data queries. We have a broad set of high-quality onchain and offchain data stored in Google BigQuery, and I write SQL to access and transform the data into actionable insights. LLMs — e.g., Claude, ChatGPT — are very helpful for accelerating that work because they help me quickly iterate on my code.

An important part of using LLMs to their max effectiveness is ensuring that your prompt has the necessary context for the LLM. Most simply, if you’re asking an LLM to write a SQL query that roughly takes the form of SELECT (column_names) FROM (table_name), you need to provide the LLM the relevant column and table names. If you don’t, you’ll need to edit them manually before running the query, which can be tedious.

What I do now

You could verbally describe the columns and table names, but it’s pretty tedious. Instead, I typically provide the LLM a screenshot of the table schema, which shows the model the column names and their types. However, this has a few drawbacks:

1. Most models only allow four image uploads, so this doesn't work for queries that requires >4 tables, which is common.

2. The model has to “tokenize” the screenshot, which introduces some error vs. text tokenization (I think). This could lead to less accuracy.

3. Images are not “semantically dense” when it comes to the context tokens that they consume. For example, the image of a table schema I tested used 2,205 tokens while the text representation of the table schema used 668 tokens — 33% of the image. If you feed an LLM more tokens than strictly necessary, it will perform worse, all else equal.

4. While small, it takes a little bit of repetitive effort to find and provide the relevant table schema to the model. This is a small, but constant, annoyance.

What's better

A new standard for providing context to models has emerged, the llms.txt standard. An llms.txt file is essentially a compressed set of documentation, that makes it easier for developers to use LLMs to integrate the API. Here is Anthropic’s llms.txt file. Other AI tools like Cursor use similar concepts — you can define context in a ‘cursor_rules.md’ file that guides the LLM’s output according to your preferences.

The Project

I wanted to write a tool that could programmatically pull schemas for any table in our Google BigQuery into a single text file. The idea would be to feed that single text file into each of my queries so that any LLM I use would have full information about the schemas and table names with which I work.

What I made

Conceptually, the script is very straightforward. Google provides relatively usable APIs that help users identify and collect information about Google BigQuery assets — exactly what I wanted to do. At a high level, I:

1. Intake the user’s arguments, which include some config details (credentials, output filepath) and the tables that the user wants to collect (lns. 98-134)

2. Connect to the Google BigQuery API and authenticate (lns. 136-169)

3. Every table in Google BigQuery is defined by a unique project.dataset.table identifier, so I iterate through the user’s designated projects, datasets, and tables to collect all table names (lns. 172-266)

4. Collect the schema for every table from the Google BigQuery API (lns. 269-309).

5. Write every schema to a text file, with formatting (lns. 314-374).

For this project, I used the clap, serde, reqwest, and yup_oauth2 crates for the first time 🙂

And it works! Here’s a demo I made for the hackathon showcase:

Reflections

I’ve already been using this file to accelerate my work. I can more readily chat with the LLM I’m using like I would another employee. Referencing “the blocks table” and specific columns and correcting work in natural language rather than writing SQL myself makes iteration much faster. Here are some reflections on the project:

• Using AI helps you figure out how to use AI better.

• I think the context file I generated could save me up to 40 mins per day on analysis-intensive days (+ a good amount of mental overhead). That's about an 8% increase in productivity (if I worked eight hour days). While that might not sound like too too much, it’s being applied to a base where I'm already 1.7-2x more productive than I was 1.5 years ago. These improvements compound over time

• A 10% productivity improvement for a typical tech employee is equivalent to something like $30k/yr including benefits. Capital investments on internal AI tooling seem well, well worth the cost.

• I like writing Rust! As a beginner engineer, I don’t know all of the errors that I might run into. Writing Rust with robust error handling and strong types feels (at the very least) very secure and reliable. When I write and run Python scripts, I often feel like I’m just praying they execute if I return to them a few months later.

You can use this tool yourself! Check out the ReadMe and Usage guide for more information.

As discussed prior in this blog (see Gyges Lydias: Disaggregating Decentralization), verifiability is one of the key goods provided by decentralization. In this case, even though a TEE may be run by a single party, it still provides valuable user protections worth pursuing.

In this article, I lightly explain what a TEE is and walk through a new initiative by Flashbots and BeaverBuild to introduce verifiable priority ordering within L1 blocks. We will:

1. Learn how a TEE introduces verifiability

2. Explain the Flashbots/BeaverBuild initiative

3. Verify one component of the initiative (priority ordering on ETH L1)

These are my independent thoughts and do not necessarily represent the views of my employer.

How a TEE works

A TEE is a special computer processor, typically manufactured by Intel, that contains an embedded private key. For modern TEEs like Intel’s TDX, the TEE is functionally the same as the CPU. The CPU can be made available in cloud environments like Google Cloud or on bare metal providers. "TEE" stands for "Trusted Execution Environment" because users can trust the chip after verifying the attestation as described below.

The private key in the TEE is used in the same way we use private keys everyday: to prove the authenticity of some claim through a cryptographic signature. When we connect to our bank account, our browser authenticates the HTTPS connection with the bank’s server and verifying that the internet traffic is encrypted. When we send ETH to a friend, our wallet is signing transaction calldata with our private key which tells the network the transaction could only have been signed with our key.

For our purposes, a TEE produces a verifiable attestation by taking a “measure” of the virtual machine and programs deployed to the TEE, including the operating system kernel and all software loaded in, and signs and publishes an attestation of the hash of that software. You can think of this as putting all of the code into a string and hashing that string to produce a unique, deterministic, shorter signature.

To verify the signature, users, e.g., you and I, can rebuild the entire kernel and software from open source code and produce a hash of our local build. If we can produce the same hash provided by the TEE operator, then we know we have have verified exactly what software is being run on the TEE. This is very similar to how we verify open source smart contracts today — we compare the deployed bytecode of a smart contract, which is available onchain to anyone running a full node, to the source code provided by the publisher. If the bytecode of the source code matches that which is onchain, we have verified it is accurate.

In sum, using a TEE provides the quality of verifiability — an essential benefit of decentralization. If we can reproduce the hash then we know the source code we see is the source code in use. And once we know the source code that is in use, we can review the code to see exactly what is happening.

Flashbots/BeaverBuild’s BuilderNet

Flashbots is a research and development organization focused on mitigating the negative externalities posed by MEV. It develops and operates MEV-Boost, a key component of ETH L1’s block building system that processes ~90% of ETH L1 blocks. BeaverBuild are one of two major ETH L1 block builders, and they also run a powerful “searching” operation, which means they compete to arbitrage economic opportunities on ETH L1.

Builders on ETH L1 construct blocks, which they send to validators through MEV-Boost. Because they send full blocks to validators, builders have significant control over which transactions are included on ETH L1.

BuilderNet is a new initiative to build a distributed system that will decrease the control builders have over transaction inclusion and other important characteristics of ETH L1. The general idea is to construct a more verifiable, fair, resilient system that still offers competitive economics to profit-maximizing validators.

In order to achieve strong economics for validators, BuilderNet makes certain promises about how transactions sent to BuilderNet will be processed. For example, a user can send a transaction to BuilderNet and receive a rebate if her transaction generates MEV. Importantly, though, the user needs to trust that BuilderNet will provide the rebate prior to submitting her transaction. This is where TEEs come in: by running BuilderNet within TEEs (many of them; the system is distributed), users can verify that the code being run will provide the rebate that is promised. Hopefully you can see how the introduction of verifiability on arbitrary code expands the design space for decentralized systems.

Priority ordering and censorship resistance

Most people think of the value of censorship resistance in the context of a nation-state conflict: perhaps a powerful country like Russia wants to censor payments to dissidents like Alexei Navalny. But it is also important for a more benign — but still important — application on blockchains: fair auctions.

One way to mitigate MEV is to use strict priority ordering: transactions within a block will be ordered based on descending priority fee paid by the transaction submitter. Because only one transaction can capture an available economic opportunity, priority ordering amounts to an implicit auction: the block builder is effectively ‘selling’ the opportunity to the highest bidder. For a more eloquent explanation, see Priority Is All You Need by Dan Robinson and Dave White.

One failure mode for a priority ordering auction is that the auctioneer, i.e., the block builder, is colluding with a bidder — or, in fact, is a bidder itself. This is not theoretical: this happens on ETH L1 today because BeaverBuild and Titan Builder are integrated searcher-builders. In this failure mode, the builder might position their own transactions ahead of other searchers’ transactions. This would break the priority ordering auction which would render the mechanism almost useless.

By running a block builder within a TEE, as BuilderNet is working on doing, searchers can verify that BuilderNet will order transactions by descending priority fee. If searchers can verify that the claimed behavior will actually be followed, they will be more likely to participate, and the system will be more efficient, with welfare accruing to all blockchain users in a well-designed system.

How to verify BuilderNet is ordering transactions by priority fee

As discussed above, there is a two-step process to verify the behavior of a TEE:

1. Rebuild the TEE locally and compare your local attestation to the attestation provided by the TEE operator → this allows you to verify that the code that the operator claims is being run is actually being run

2. Examine the source code you built locally to see what it is doing → this allows you to verify that the code is doing what the operator says the code is doing

We’ll leave the first step to a later exercise, but today, we will audit the BuilderNet code to see if the code orders transactions by priority fee.

Flashbots claim that BuilderNet uses rbuilder, which, if you’re at all familiar with the typical naming conventions of Rust aficionados, is a block builder written in Rust. Again, we can only verify their claim by verifying their attestation, which is out of scope for this exercise. The rbuilder code, however, is available on Github.

I will now attempt to explain Flashbots’ code in natural language for someone unfamiliar in Rust. Rust is pretty… f&ked, for lack of a better word, so bear with me. I’ve stripped out a lot of the code, but I share the filepath and code line for each block if you want to read the full thing. For those of you who know Rust, the terminology will not be correct, but I hope you will agree it is accurate.

The code that shows rbuilder uses priority ordering

We enter the block building process through the build_block() function. The function has a different behavior based on the OrderPriority parameter we use (that’s what the <OrderPriorityType: OrderPriority> angle brackets mean). Remember this.

This kicks us to fill_orders() immediately below. In fill_orders(), we loop through all the “orders” (i.e., pending transactions) that can go into the block.

PriorityQueue , despite what it’s name might indicate in this context, is a non-Flashbots-specific function that implements a very high-performance data structure for sorting things. It is an open source and widely used primitive. In the docs for that data structure, we see that pop() pops the “item with the greatest priority.”

Okay, we’re popping orders off a stack of block orders that sorts the stack based on “the greatest priority.” Now, we need to check if that priority is based on priority gas fee in our specific implementation!

If we setup our block builder with OrderPriorityType of “OrderMevGasPricePriority” then we will pop orders based on priority gas fee. Let’s move over there.

The PriorityQueue library lets developers define the behavior based on the developer’s implementation of cmp(), which is short for “compare”. So Flashbots need to define comparison behavior for their specific use case. Let’s get back to rbuilder.

And we find the money line:

It might not look like it 😭 — as I said, Rust is pretty wonky. But In Rust, this function returns an Ordering which is like a shorthand for either Greater, Equal, or Less.

So if a.sim_value.mev_gas_price > b.sim_value.mev_gas_price then the function will return Greater . It’s probably approximately clear that we’re comparing gas prices of two different orders, but let’s just double check here.

The cmp() function takes in two variables, a and b of type SimulatedOrder. We find SimulatedOrder in primitives/mod.rs , which is intuitive: these are the “primitive” types used throughout the codebase.

Okay phew! We can now see that when we compare a.sim_value.mev_gas_price to b.sim_value.mev_gas_price , we are comparing two very large integers and that the function cmp() tells us whether the value for a is Greater than, Less than, or Equal to the value for b.

WOW! If you’ve made it this far without knowing Rust, great job. At this point, you can see if we configure rbuilder to sort by OrderMevGasPricePriority , then, when the block builder calls pop_order(), it will first pop orders that have the greatest mev_gas_price and process those first. That means that orders will be ordered within the block by mev_gas_price — exactly what we expect.

Therefore, the last thing we need to check is how the configuration is set. If we can verify that the config file in-use (i.e., by checking that the TEE attestation covers the config file (suffixed .toml, see rbuilder/config-live-example.toml for an example) has what we expect, then the block builder will sort orders by priority fee. One last go…

In Rust, we use a library called serde (short for “serialize - deserialize”) to parse string arguments into the strict types that Rust needs in the program.

This is really, really confusing (I warned you…), but the #[ blocks are like auto-transforms. What these say in natural language is something like “take a text input in kebab-case (i.e., the "mev-gas-price" in our config.toml file) and deserialize (parse) it into CamelCase (e.g., “CapsLookLikeACamelWhichIsRustStandardConvention”). If the text input ends up matching “MevGasPrice” then our Sorting setting will be MevGasPrice.

If we go to the ordering_builder , we see how the builder is initialized:

Whew. As a final review, here’s what we know happens in the code:

• The builder builds blocks based on an OrderPriorityType

• If the OrderPriorityType is set to OrderMevGasPricePriority, then when we pop() orders off the stack, we will first pop orders with the greatest mev_gas_price

• We set the builder to use OrderMevGasPricePriority by passing the argument sorting = "mev-gas-price" into our config.toml file.

Therefore, what we need to verify from the TEE attestation is that:

• The BuilderNet TEE is running the same rbuilder code that we’ve reviewed here.

• The builder running in the TEE used a config.toml file that has the sorting = "mev-gas-price" line.

If we can verify all of that, then we know that transactions on BuilderNet will be sorted in priority order.

Verifiability as a central good of decentralization

I’ve claimed before that decentralization may not be important for its own sake; instead, it seems good for other things. In this article, I’ve shown how TEEs introduce verifiability: by producing an attestation that can be locally verified against source code which any user can verify. I’ve also shown how users can take the next step and actually verify the behavior of the source code.

While much of this discussion is still somewhat theoretical — for example, I’m not currently aware if or where BeaverBuild publish TEE attestations to the code they’re running — I hope you can see the future design space for TEEs and a plausible pathway to get there. BuilderNet makes many more promises aside from transaction ordering — refund mechanisms, privacy guarantees are two examples — so being able to verify these guarantees will be essential to its success.

Verifiable systems are important for fair, transparent, immutable, and censorship financial markets, and I’m more optimistic than ever that Ethereum DeFi is on the way to achieving that goal.

Thanks to Dan Marzec for providing feedback on parts of this article. These are my independent thoughts and do not necessarily represent the views of my employer.

A malaise pervades the crypto industry today. On one hand, the regulatory environment has never looked better, and TradFi interest in public blockchains is at an all-time high. Yet internally, crypto feels more stagnant, circular, and cynical than ever. How can that be?

I think it's because crypto today only exists to serve cryptoassets. While the total market cap of crypto nears $3t, very little of that value is exogenous to our industry. The tokenized traditional assets that have come onchain (dollars, t-bills) have been tokenized primarily to serve crypto's needs, not the imperatives of the assets. Crypto has not improved the traditional financial system; yet.

It's true this is partly because crypto hasn't been allowed to change the financial system. The Biden Administration seemed to do everything in its power to prevent adoption of the public blockchain innovation that exploded in 2020 and 2021. It debanked crypto entrepreneurs and companies. It froze all bank experiments with the technology. It investigated or sued the best actors in the space, turning earnest engagement into prolonged litigation.

It's also true crypto has obvious innovations that could improve traditional financial services. Automated market making is an elegant way to improve liquidity for low-volume assets. Collateralized lending extends credit to people with just one dollar of net worth, exactly the people most likely to pay the highest interest rates. Even perps make markets more efficient by making option durations infinitely granular.

But it's also true that crypto hasn’t succeeded, for whatever reason. In fact, these days, it's more common to see crypto fail. Parts of our industry not only tolerate but actually celebrate and justify modern memecoins when they are plainly extractive, circular, and shortsighted. Projects race to "TGE" (Token Generation Event) pre-product, intending only to cash out, which leaves roadmaps half-completed and vaulted promises unfulfilled. Others see government endorsement as an explicit product strategy, which depletes the common stock of credibility we all share.

What is needed is real innovation. A crypto product you don't need to pay people to use. Examples, not explanations. A proof of concept -- yes, a proof! -- not another promise. Justly or not, we must now produce a tangible example of change to break through this malaise.

I think this is required.

I'm also telling you it will come. Not from blind faith, not from naive optimism. But from conviction. It will come because of the work, creativity, and Spirit of a few people -- who dare to change the world.

We believe in something real.

In this blog post, I identify those other things. We can speak more precisely about the nature and benefits of decentralized systems, whether they be smart contract protocols, blockchain networks, or anything else. Many of these characteristics are the primary advantages of the new financial system being built on public blockchains — a system perhaps misnomered “DeFi.”

These are my independent thoughts and do not necessarily represent the views of my employer.

Fairness. Sometimes, people mean that decentralized systems are fair. Fair systems preserve no privileged positions. Satoshi has the same rights within the Bitcoin network as you or I. Fairness is good because it sets everyone equal, empowering everyone with maximum agency.

In a regulatory context, the extent to which someone has a privileged position in a system is essential to evaluating their “control.” If someone has control, it may be reasonable to give them regulatory obligations; but if everyone is equal, singling out a single actor may be arbitrary.

Information symmetry. Relatedly, people sometimes mean that decentralized systems naturally provide symmetric information to everyone. The Hinman Speech explains that the centrality of an issuer or promoter to the success of an enterprise implies disclosure obligations. However, the cause of the obligation is that the central party has asymmetric information that is likely of material importance to investors. It’s information asymmetry that is most relevant, not decentralization purely.

Openness. Sometimes, people mean that decentralized systems are open. Everyone can run a Bitcoin node, compete in the proof of work competition, and broadcast transactions. There are no gatekeepers.

Open systems are more accessible to more people. Lower barriers to entry also facilitate innovation, increasing the pace and possibility of user-beneficial improvement.

Verifiability. Sometimes, people mean that decentralized systems are easily verifiable. When decentralized systems allow anyone to participate in the network, every user can verify the results of a transaction for himself. This increases the trustworthiness of the system.

Relatedly, decentralized systems are often verifiably open source, which means users can know exactly what will happen when they use a program. This enables better risk management and safer, community-reviewed software. “Transparent” could be a synonym for “verifiable.”

Resilience. Sometimes, people mean that a decentralized system is more resilient because it does not require a specific actor to function. If one actor fails, another can take its place. For example, the Bitcoin network continues while just two node operators run the software. Or, users can continue to use the system without the failed actor: users of many Ethereum L2s can withdraw funds and effect transactions on the L2 without having to rely on the sequencer. When there is no single point of failure, systems have higher uptime.

Lack of intermediation. Traditionally, people mean that decentralized systems lack intermediaries. Such systems can decrease costs, trust requirements, and time delays when compared to traditional systems. Many decentralized systems, like Ethereum or Aave, enable complex transactions that are still peer-to-peer.

Immutability. Decentralized systems must also be immutable, because if no one has a privileged position then no one can upgrade the protocol without everyone else’s concurrent adoption. This kind of software is more reliable for users, who can trust that the rules of the game won’t change on them.

Censorship resistant. Perhaps the most important derivative of decentralization is censorship-resistance, which is the ability to execute a transaction in adverse conditions. Because Bitcoin has abundant and diverse node operators, it’s easy to execute a transaction in the face of censorship by finding a few friendly node operators to submit your transaction. This is important for maximizing human freedom.

Decentralization is a spectrum. It’s probably the case that all of The Other Things are necessary for something to be ‘truly’ decentralized, but nothing is sufficient alone.

But who cares? Decentralization is not good for its own sake — it’s good for The Other Things. If a system has intermediaries, such as an intent-based bridge, it may not be purely “decentralized.” But it’s still good for users if it’s fast, cheap, and resilient. Or, if a blockchain has a permissioned validator set (i.e., it is not maximally “open”), it is still safe if users can re-execute transactions with their own full node (i.e., it is “verifiable”) or overcome L2 censorship with an L1 contract call (i.e., it is “censorship resistant”).

It’s also the case that many projects claim to be decentralized when they really aren’t. The full assessment of a project’s technical decentralization is complex and intensive, but it may not even be necessary. Focusing on the specific benefits provided by decentralization, like immutability, verifiability, fairness, openness, and censorship-resistance is a more consumable exercise, and I think it’s more helpful for users. We should focus on whether systems provide users with those benefits rather than whether systems meet some Platonic ideal of “true decentralization.”

These are my independent thoughts and do not necessarily represent the views of my employer. Thank you to some friends who provided comments.