This article is the final draft of the article that was eventually published here. This post is split up into two sections. First, I describe my belief that chain-abstraction infrastructure is vital for consumer adoption of crypto and that intents-based architecture is the best way to engineer chain-abstraction. Secondly, I describe the main obstacle toward broader adoption of intents: solver-network liveness. I end the piece with a solution and introduce the standard that Across and Uniswap have collaborated on, using feedback derived from the CAKE working group. This standard is designed to optimize for the solver UX and lower barriers to entry to a universal solver network that most intents can be routed to. Agenda The problem: Defining the end state: what makes crypto applications "usable" Why "chain abstraction" is a solution to a UX problem that arises out of the fundamental topology of modular blockchains

This is MEV I recently watched this talk and it fundamentally changed my thinking about what MEV is and subsequently led me to think about where MEV is produced in the Across Protocol. What do Smart Contract Engineers do? I, a smart contract engineer, try to build dApps that produce as much value as possible while minimizing MolochEV (the value lost by uncoordination arising from inexpressiveness and a suboptimal mechanism) and MafiaEV (the value extracted by sophisticated agents or the "Mafia" at the expense of unsophisticated ones or "retail"). Also, "Maximizing expressivity" is just a really fun and esoteric way to describe software engineering. In the best case, I create dApps that maximize their MonarchEV, or value that accrues to the protocol in exchange for a valuable service rendered. It’s best that the protocol receives this value, as opposed to it being consumed by sophisticated agents at the expense of unsophisticated ones, or lost into the void. Then, the protocol can distribute the value to those who "deserve" it within its ecosystem, like relayers and LPs in Across (and maybe even ACX holders). So where does Across leak value? Across produces value by charging bridge depositors who want to move their funds to another chain. This value is MonarchEV and is supposed to be paid to relayers and LPs. Any of this value going to unintentional recipients I’ll refer to as value leakage. You can also think of this leakage as MEV produced by Across. For all dapps, value leakage usually occurs when the order of transactions can be swapped by block builders (sandwich attacks) or when more sophisticated uses prey on retail ones (front running).

This article explains Across' architecture succinctly from first principles and then fantasizes about the spaces into which Across will grow 💫 The Across protocol is defined completely by a UMIP and it embodies the UMA way of building decentralized software as hybrid on-chain plus off-chain architectures: Smart contracts are deployed that are able to receive proposals containing state modifications that can be executed after they undergo a challenge window and are optimistically validated Off chain actors interpret an off-chain constitution explaining the rules governing valid proposals. These are UMIPs. These actors compare the proposals against the UMIP to decide whether to challenge a proposal When the proposal passes liveness, the state modifications can be executed by the smart contracts Across is a fluid protocol The Across protocol design has a minimal on-chain footprint and the smart contracts are strategically unopinionated. They instead provide space for protocol rules to be defined off-chain, where they can be more rapidly updated. This means that non-engineers can take on the responsibility for upgrading Across' fee model and capital allocation rules without having to push through contract upgrades on-chain.

In a few weeks, I'm going to meet up with coworkers at a company offsite where we'll be going on a lot of walks and sharing meals together--in-person! This will undoubtedly lead to a lot of spontaneous brainstorming and forecasting. I miss this about the in-office work culture. These are colleagues that I am lucky to see one or two times a year so there's a lot to catch up on. One of my goals ahead of this trip is to bring with me a mostly developed (~75% crystalized) thesis about where the crypto industry is going: What will the crypto user experience look like in 2030? What will the infrastructure look like then? This will help inform answers to the most important existential questions in the industry today:

Fail early, fail often. And when in doubt, fail in the direction of kindness I recently was invited to give a speech at my high school's "Cum Laude" ceremony, comprising the top 20% of the graduating class. I was instructed to give some advice to the students, who are around ten years younger than me. In the process of writing this speech, I realized that there were a few mental models that I have been using consistently since I graduated from college. In my speech, I tried to summarize them: You can become proficient at anything The difficult aspect of the above statement is figuring out what you want to become proficient in To figure that out, try a lot of different things and don't be afraid of being bad at those things at the outset Once you decide what you want to proficient in, practice it consistently and do not give up

Across solves the problem of transferring assets between blockchains by disintermediating the Broker role and introducing a third party validator. Anyone with a blockchain account can participate and be a broker or be a validator and offer the best price for their services. ELIMINATING THE BROKER There exist many blockchains today that do not have natural ways to transfer information or assets to each other so they outsource their inter-blockchain communication channels. This is analogous to the traditional financial system in which different banks from different countries need to be able to wire transfer value to each other. In order to send money to a bank, the recipient bank must speak the same transfer language as you in order to interpret the transfer order correctly. This is why most banks will support multiple transfer networks like ACH and SWIFT, in order to send transfers to other banks on those networks. Transfer networks are legally enforced: ACH transfers are provided for by an American organization and are therefore enforced by the American government, while SWIFT is enforced by a group of international central banks and its transfers are enforced by an international court system. Blockchains could try to tap into existing networks like ACH and SWIFT to transfer funds between blockchains, but imagine how inefficient this would be: Send BTC from Bitcoin blockchain to an exchange like Coinbase

I've spent a lot of time recently writing and reviewing solidity, which has been refreshing. Ironically, life as a Smart Contract engineer doesn't always consist of writing solidity. In fact, it has been almost six months since the last time I was writing this many new smart contracts, so I had to spend some time getting acquainted with the latest and greatest in Solidity tools and best practices. Now that I'm feeling a bit reacquainted with the Solidity landscape, I'd like to document some up-to-date tips for writing smart contracts in 2023. These tips will probably be outdated by 2024, as the smart contract landscape continues to progress at a mind-numbing pace, so I've tried my best to compile advice that could be considered more evergreen. This essay is designed to be read by any developer who wants to launch a contract system on Mainnet. This is the time where your decisions matter the most--decisions about framework (e.g. Hardhat or Foundry), about upgradeability, and about contract architecture. Once you deploy to Mainnet, you go past the point of no (easy) return and you enter the dark and stormy seas where you must defend against MEV monsters lurking below the depths. Spend more time upfront on design and security, and harvet the rewards later. This essay is organized as follows:

Architects are wise to respect the environment on top of which they will build. Smart contract developers who build on Ethereum should similarly iterate on dApp architecture as the blockchain changes. Design for extreme temperatures Design for rising water levels A proposal for how to design dApps that will scale with the rollup-centric future of Ethereum. Ethereum, the most prominent decentralized blockchain, gifted computer programmers a new primitive of “self sovereign data” which unlocked a new era of application development. But Ethereum is changing and application designers should again fundamentally rethink how they architect programs in light of these impending changes. Ethereum is betting on a rollup-centric future where rollups/l2s will be the fast and cheap layers that users interact with while ethereum will be the high security execution and data availability “base” layer for the L2s. This article will: