1. Big wallets are kingmakers. They can easily divert users to chains & apps of their choosing, or even embed their own or their partners' apps.

2. Wallets are UX bottlenecks. It matters little if your chain supports support low block times when metamask is slow as molasses. Or that your chain or app support new amazing RPC methods (for account abstraction, cross-chain interaction, batching, ...) if wallets do not support them. Wallets degrade apps' experience by not displaying details about transactions - forcing users to place high trust in apps.

3. Wallets bottleneck adoption. Installing a browser extension and understanding & saving seed phrases is too long and too hard for normies. Social login or passkeys, with seamless multi-device support must be offered. Onramping must be built-in, or gas sponsorship offered for non-financial apps.

Both apps and chains need a wallet strategy to avoid wallets from cannibalizing their users. This dynamic is only nascent (built-in swaps & NFT purchases, featured apps), but you can count on it accelerating. Both partnerships & diverting users to their in-house wallets (with superior features) are options.

Where wallets UX is crucial or gatekeeps useful features, directing users to a compatible wallet is similarly important.

The winner of the wallets war hasn't been decided yet. The winning wallet will be cross-chain (with chain & gas abstraction: use any token on any chain), cross-form-factor (browser, mobile & embedded, offering seamless onboarding & transitioning between devices) and simplified onboarding & management via social login or passkeys.

A lot of apps have endeavoured to build their own chains. Apps should instead endeavour to build their own wallets. Good wallet UX is less commoditized than block space, and offers better future upside & a competitive moat.

I have a wallet to sell you. At HappyChain, 95% of our engineering effort has been in pursuit of a better wallet. We needed to onboard gamers who never used a blockchain in less than 30s & have them start playing onchain games (= transacting).

Our MVP is a wallet that combines the best of Privy (embedded, social login) and Metamask (multi-app & multi-chain support, fully-featured interface with portfolio view, token transfers, ...).

If you're interested in getting into the wallet game and you need a leg up on the tech, and someone that knows how to build wallets... My DMs are open.

I finally got tired of hearing people say that Velodrome/Aerodrome was a ponzi, and having to correct them. Time to set the record straight, while not hiding from the uncomfortable.

Table of Contents

• Background

  • Disclaimer
  • What's a drome?
  • ve(3,3)? MetaDex? Lockonomics?
  • What's being argued

• Lockonomics explained

  • Basic Plumbing
    • Basic DEX (~ Uniswap)
    • Velodrome
    • An apple-to-apple comparison
  • The key insights behind lockonomics
    • 1. Velodrome imposes a speculation tax on short-term holders
    • 2. Locking is beneficial to trading flows
    • 3. There is a floor underneath the house
    • 4. Emission control makes the system resilient to exogenous shocks
    • Conclusion — For Lockers: Heads I win, Tails I win

• Velodrome in practice

  • Emissions > Revenue
  • Growth & Moats

• Lockonomics beyond AMMs

• Common Objections & Questions

  • Velodrome is a Ponzi scheme
  • Velodrome is printing money out of thin air
  • VELO will inflate to nothing
  • Uniswap is better than Velodrome
  • How does ve(3,3) relate to OlympusDAO's (3,3)
  • What about the rebase?
  • 4 years is forever, so there is no way to cash out of Velodrome
  • Are there other reasons to be bullish on Velodrome?
  • What's the BATMAN token story?

• Dune Dashboards

Background

Disclaimer

I introduced the Velodrome team to Optimism while I was working there, back in the day. So me and them go way back.

None of this is investment or financial advice, which I am not qualified to give.

What's a drome?

Velodrome is the leading DEX on Optimism, and the first successful DEX of the ve(3,3) variety. Aerodrome is the leading DEX on Base, and features the highest-volume ETH-USDC and BTC-USDC pools in all of DeFi.

ve(3,3) was devised by Andre Cronje for a DEX called Solidly, launched on the Fantom blockchain. The Solidly launch didn't exactly go well. Despite rapidly accumulating 2B$ in TVL (this was peak DeFi hype and most of that was in now worthless farming coins on Fantom), there were numerous issues.

First, $SOLID was distributed was to top-TVL protocols on the Fantom blockchain. This lead to a race between Solidly over-layers to take control of the supply and then offer their own "liquid locking" system on top to direct voting power. If this seems confusing, see later for the explanation of how Velodrome works. If you're familiar with Curve Finance, think of these projects as the Convex layer this is not fully accurate, as Solidly does have "bribing" built-in). Unfortunately, the products were not ready for the Solidly launch and suffered numerous issues.

Second, in classical Cronje style, he yeeted the contracts day one with zero centralized control. While this is the ideal end state, it's good to take some precautions with novel systems. The contracts (as far as I know) suffered no bugs, but there was a funny occurrence where control would have come in handy (search “batman” in this doc for more info). This was crowned by Cronje ragequitting crypto (not for the first time — he's back again now) just one month after launching Solidly.

At that time, what would become the Velodrome team was involved with veDAO, one of the teams building on top of Solidly. They thought the idea was too good to waste, and went on to create Velodrome on Optimism (in part thanks to yours truly) and later Aerodrome, now the leading DEX on Base, and one the major leading DEX sporting the highest volume ETH-USDC and BTC-USDC pools in all of DeFi.

In what follows I will use “Velodrome” as stand in for “Velodrome & Aerodrome”, and all my comments about Velodrome apply equally to Aerodrome, unless otherwise specified.

ve(3,3)? MetaDex? Lockonomics?

I somehwat dislike the ve(3,3) moniker. The "ve” part refers to “vote escrow”, which is borrowed from Curve Finance, one of the major inspiration behind Solidly. That part is fine. The (3,3) part is a nod to OlympusDAO.

OlympusDAO... is difficult to describe. I wrote an analysis of it back in the day, because I didn't understand why seemingly smart people were doting on it.

The summary is it's nothing too good. In short, it's essentially a memecoin with sky-high inflation accruing to stakers which was going to invest token sale proceeds into various ventures. Some people call it a ponzi (which is incorrect, see later), but it definitely wasn't a smart investment and there was definitely a fair amount of “suspension of disbelief” involved, if not something worse.

I think the ve(3,3) model does suffer the association, and its contributions to the design are negligible (we'll go back to this later).

The Velodrome team itself has tried to rebrand the model as MetaDex, writing a series of article on the topic.

I think this series of article make a lot of good points, but I don't think they cut right to the core of why the model works, and why people's claims about it are incorrect. It's however an excellent read, and in particular most of what we'll touch on is explained with a different emphasis in Part 4 on Sustainability.

This is my attempt to clarify things, and in the process I'm coining “Lockonomics” for the model followed by Velodrome — which could potentially be extended to other places!

What's being argued

I'll be arguing that lockonomics is a good model, or at the very least an interesting model with interesting trade-offs that is not inferior to more traditional tokens model.

We'll explore this by contrasting how Velodrome compared to how most classical AMM DEXes work, and we'll use Uniswap as a stand-in.

Some people think that AMM DEXes are all bad (because of impermanent loss (IL) or loss-versus-rebalancing (LVR)). This is immaterial to the current discussion, which focuses on which token model works better if we assume that you are running a "classical" AMM DEX as a given.

As we'll see, lockonomics could easily generalize to any other revenue-generating DeFi protocol.

Lockonomics explained

Basic Plumbing

Basic DEX (~ Uniswap)

To understand how Velodrome works, we first need to understand how Uniswap works.

In this model, we consider an AMM pool. Let's imagine that this belongs to a project with a token $P, and that this is an $USDC-$P pool. Let's further assume that the project wants to incentivize the pool's liquidity.

The model features the following actors:

• Users who swap $USDC for $P & vice-versa, paying fees as they do so.
• Liquidity Providers (LPs) who provide $USDC and $P liquidity in exchange for LP tokens (which they can redeem at any time for their share of $UDSC and $P in the pool). LPs receive the fees paid by the users.
• The project, who incentivizes the pool liquidity by supplying $P rewards to a staking contract. LPs can stake their LP tokens and receive a share of the liquidity rewards in exchange.
  • This staking contract is not provided by the DEX, and must be setup by the project team separately. It is not advertised from the DEX's website.

If you've been around DeFI, this is all pretty straightforward.

Note that we do not mention a DEX token. If we're talking about Uniswap, this is fair: the token does not play an economic role (*), and is only involved in governance. More enlightened protocols will typically direct a cut of the fees to DEX token holders.

(*) Though do note it is used to fund some of the protocol's operation's, though this is not strictly required — Uniswap makes enough money on frontend fees.

Velodrome

Now here's how Velodrome works:

The Velodrome model features a new actor: the $VELO locker. They lock $VELO long-term, and in exchange receive voting power that they can direct to AMM pools of their choosing. This occurs every voting cycle, which is one week for Velodrome.

In exchange, they receive the fees paid to the pool, as well as any liquidity rewards setup by the project (now called “bribes” since they incentivize voting).

Instead of fees and liquidity rewards, LPs receive a share of $VELO emissions. These emissions are inflationary to the $VELO supply.

(Note that Velodrome allow LPs to receive fees instead of $VELO emission, albeit with a haircut. I don't believe that this feature is very important in how lockonomics work, so I'm omitting it in this analysis.)

Finally, an important point: how much $VELO is emitted? This was initially following a decreasing inflation schedule to distribute the token and incentivize growth before stabilizing, and is now controlled by the protocol — the rate is currently set by the team and will become governed by lockers in the future.

The emitted $VELO is directed to pools pro-rata to lockers’ votes.

An apple-to-apple comparison

Because of the role of the $VELO token, the system is very dynamic. Let's work our way up to the full complexity by constructing an artificial scenario where Velodrome would work as basically “Uniswap with extra steps”. In this scenario:

• LPs receive $VELO tokens worth exactly the fees paid by user + the bribes paid the project
• $VELO lockers receives fees & bribes that exactly offset the inflation caused by emissions (if we posit that the $VELO market cap is constant). We'll refer to this as “emissions = revenue”.

Is there any point in this basic scenario? Actually there is, and it's due to the facts that:

1. Only a portion of the total $VELO supplied is locked.
2. We can always fall back to this scenario via emission control.

The key insights behind lockonomics

1. Velodrome imposes a speculation tax on short-term holders

In our basic scenario, the $VELO lockers are actually making profit. Where does that profit come from if everyone else (users, LPs and project) are not worse off? It comes from non-lockers.

Every time $VELO is emitted, the $VELO supply is being diluted.

Let's pick some bullshit numbers & make some assumptions to illustrate (real numbers are much much smaller or bigger, this is only to illustrate the dynamics):

• Let's say that 10% of the current $VELO supplied is being emitted.
• We'll assume 1,000,000 $VELO tokens pre-emission, with a value of 1$ each.
• We'll assume the $VELO market cap remains constant.
• We'll assume that 50% of the $VELO supply is locked. (This is actually the case.)
• The value of $VELO drops to 1$*100/110 = 0.909$ after the emissions.
• The value of the emissions is thus 100,000*0.909$ = 90,900$
• Lockers collectively receive fees & bribes offsetting the emission, i.e. 90,900$.
• Given that lockers only owned 50% of the $VELO supply, the collective value of their $VELO dropped by 90,900$/2 = 45,450$. But they made 90,900$ on the fees & bribes, for a profit of 45,450$.

So in our baseline scenario, lockers make profit at the expense of short-term holders.

2. Locking is beneficial to trading flows

... and therefore to price action.

It's not a secret to anyone that has looked at the field for more than 2 seconds that most crypto tokens do not trade on fundamentals.

We could separate the value of any token into a “meme” (flow-driven) value and a “fundamentals” (revenue-driven) value.

(The reality is slightly messy, as revenue can be funnelled into flows, this is for instance the case for stock buybacks or Ethereum-style token burning.)

By trading flows, we simply mean the balance between supply and demand for a token.

An example of flow dynamics at play are “low float high market cap” tokens, where only a tiny portion of the token supply is available for sale at launch, artificially driving the price (and thus the market cap) up.

Long-term locking in Velodrome encourages the same dynamics. You need to lock your tokens for 4 years for maximal voting power, and the voting power decreases as the time on the lock decreases, leading most people to “perma-lock” their token (i.e. the tokens are always locked for 4 years until the locker disables the feature). This is evidenced by the average locking duration on Velodrome currently being 3.6 years.

Locked $VELO is effectively removed from circulation, which tends to be beneficial to the token price.

3. There is a floor underneath the house

The value of the $VELO token is not just memetic: it is supported by real revenue (from fees & bribes). This means that the value of the token cannot drop arbitrarily low, as at some point the APY for lockers would be too tempting to pass up. The principal for lockers is $VELO tokens, but the interest is in other tokens, so as $VELO underperforms, the APY mechanically shoots up, encourage investors to scoop up & lock $VELO.

(Of course, black swan events are always possible, like if the team were to suddenly abandon the project. There is always risk.)

It is important to note too that in the absence of revenue growth, it is natural for the inflationary $VELO token price to go down over time. This is normal, and as we have established, lockers are compensated for this (via fees, bribes, and the dilution of short-term holders) and come out ahead.

But what if $VELO (and thus LPs’ revenue) drop, causing the LPs to leave and fees to dry up? I'm glad you asked!

4. Emission control makes the system resilient to exogenous shocks

You may wonder if our baseline artificial scenario is realistic. I think it is, because of the ability of the protocol to set the emission rate.

If an exogenous (~external, not related to issues with the protocol itself) event would cause the token price to drop, this might potentially be threatening to the protocol, as the reduction in LPs's revenue could cause them to pull out.

This can, in extreme cases, be fought with emission control. Recall that lockers do not care how high inflation is, as long as they are compensated for it in fees and bribes. The protocol can simply increase emissions to the level where they are commensurate with fees & bribes, which will keep it competitive with classical DEXes.

This means that our baseline scenario should represent a worst case that the protocol that can always fall back to.

Conclusion — For Lockers: Heads I win, Tails I win

The key insight behind lockonomics is that it's an engine that incentivizes long-term holding.

Short-term holders get penalized by inflation. The lower the percentage of the supply is locked, the more lockers make profit in this manner. There is however the risk that the token price would go down as there a large supply available to be sold. But there is a baseline value for the token due to the protocol's revenue.

If, on the other hand, the percentage of the locked supply were to go up, then lockers would make less profit — but this would be positive for the token's price action.

In the worst case, emission control can be used to bring the system back to the emissions = revenue state, stabilizing the protocol.

Velodrome in practice

Emissions > Revenue

We've so far examined a baseline scenario where emissions precisely match revenue. In practice, emissions on Velodrome typically exceed revenue, often by as much as 100%.

Velodrome is often described as a Ponzi scheme or as printing money out of thin air — and I believe that this is the reason for those particular accusations.

The higher emissions are, in a certain sense, not ideal: it means that the lockers are getting overly diluted. If the goal is simply to stay competitive with Uniswap-like DEXes, then lower emissions would be sufficient. And the protocol could lower emissions today!

But it's also undeniable that the higher emissions have served to grow the protocol. Higher emissions attract LPs with high APY, increasing liquidity. They also attract projects, who can get more than 1$ of liquidity incentives to LPs for every 1$ spent in bribes.

Lockers haven't really suffered from the extra inflation in practice, as revenue has consistently exceeded the observed price impact from inflation (the token has had its price swings, but they cannot be easily attributed to routine inflation). Lockers are by design aligned with the protocol long-term, so growth is desirable as it represents a bigger future pie.

Over recent voting periods, $VELO inflation has been 15% annualized, which is consistently lower than the yields available to lockers (which have rarely dipped under 20% and have often been much higher).

It's important to understand that emissions > revenue is not sustainable. But everything we laid out before explains that (1) when emissions = revenue, the protocol is sustainable and equivalent to a Uniswap-style DEX, (2) emission control can be used to forcibly bring the protocol to this point.

Basically, by controlling emissions, a lockonomics DEX can choose between sustainable profits or incentivizing growth via incentives. If we hold market cap constant, the latter comes at the expense of lockers in the short-term — though in practice lockers have remained profitable with respect to token inflation.

Part 4 of the MetaDEX series makes the point that "emissions can always exceed fees", which I don't agree with. However, it does clarify the conditions for this to hold, in particular noting the following condition:

The fundamental value of each token depends on the degree to which fee growth outstrips supply growth.

This is exactly our point: as long as emitting more tokens today brings in more fees tomorrow, emissions > revenue is a winning strategy. This probably isn't the case forever, but it has been the case so far, and with the economy coming onchain, this could last a long time. And if or when it stops, you can always revert to emissions = revenue.

Growth & Moats

Growth is only good if it is sticky, and worthless if liquidity were to evaporate when emissions revert to revenues. I argue that a good portion of growth is indeed sticky.

• Migrating liquidity to a different DEX is very disruptive for projects. They have to coordinate LPs to switch, direct users to a new DEX, and fragment (thus lower) liquidity while the migration is ongoing. In practice, DEXes are quite sticky for project.

• Project are encouraged to accumulate $VELO. They will do so naturally if they have protocol-owned liquidity (POL), as they will receive emissions. On a long-term horizon, it is also more advantageous to accumulate locked $VELO because of its yield-bearing nature (if only because of the speculation tax).

  • When emissions > revenue, the situation is particularly favorable to protocols with POL, as they offset the extra inflation by being a recepient of the emissions themselves, letting them accumulate $VELO faster.

  • On Aerodrome, the “flight school” program also incentivizes projects to lock $AERO.

• Users want the best execution, which mostly means the least price impact. This means they will use the pool with the most liquidity (or the most efficient liquidity, which is notably a factor with concentrated liquidity pools). Liquidity thus translates into fee revenue, and as a pool accumulates liquidity, it requires more and more external incentives to attract LPs and displace the pool.

• It's of course possible for a new DEX to come onto the scene with a shiny new token to farm, but we can observe that well-managed DEXes have a lindy quality. Uniswap is a prime example, as despite the lack of protocol-specific incentive compared to the competition, they have remained a force to contend with.

Based on these observations, I think that one can indeed consider that growing the protocol is a worthwhile investment and not an unsustainable short-term “propping-up” of liquidity & token price.

Lockonomics beyond AMMs

The lockonomics model does not need to only apply to AMMs. In fact, it can work with any project that has real revenue (this could be lending, perps, launchpads, options, ...). Here's the playbook:

1. Direct the revenue to the lockers.

2. Compensate the users that would normally receive the revenue via project token emissions instead.

3. (Optional) Let lockers direct the inflation (i.e. in a lending protocol, to lenders in specific lending pools).

   • This is optional because you could simply direct emissions to be proportional to the revenue generated. However, there are advantages on letting the lockers vote: it incentivizes projects to accumulate locked token to incentivize "things" related to them (e.g. lending pools). This does not however apply to every revenue-generating project.

4. Let lockers vote on emissions, deciding between a growth-orientation (more incentive to the users that would normally receive revenue) and a stable profitable equilibrium (revenue = emissions).

5. Profit.

I'm surprised this model hasn't been tried more widely before (or maybe it has and I'm simply not aware).

Common Objections & Questions

Velodrome is a Ponzi scheme

A ponzi scheme is when money from new investors is used to pay older investors in a way that is unsustainable. When new money stops coming in, the system collapses.

The term is often extended to systems that are not strictly Ponzi schemes in this sense, like memecoins: when new buyers stop coming in, everyone rushes for the exit.

But Velodrome does not need new buyers: in the worst case, the inflation causes the token price to go down over time, for which lockers are compensated.

As long as revenue (fees & bribes) doesn't drop precipitously, a drop in price provides a buying incentive, as the locking APY goes up.

The ability of the protocol to control emissions ensures that the system can always be brought to a baseline where emissions are commensurate to fees & bribes, which is a stable equilibrium.

Velodrome is printing money out of thin air

This criticism comes from the fact that, so far, Velodrome emissions have been systematically higher than protocol revenue (fees + bribes), often as high as 2x.

I elaborate on this in the “Emissions > Revenue” section, where I make two important points:

1. The protocol does not not depend on emissions > revenue for sustainability, and can always stabilize to become Uniswap equivalent (emissions = revenue).
2. The higher emissions incentivize growth, and a good portion of this growth is sticky (just like how Uniswap has been sticky).

VELO will inflate to nothing

In the absence of growth, yes the token price will go down over time. As we painstakingly established above, lockers are fully compensated for this and can even turn a profit. For non-lockers, this is indeed bad news, but that's the whole idea of lockonomics: incentivize & enforce long-term holding via a speculation tax on short-term holders, enacted via inflation.

Uniswap is better than Velodrome

Velodrome can be made functionally Uniswap-equivalent (emissions = revenue) via emission control. In that scenario, it remains much better than Uniswap for token holders. $UNI token holder accrue zero value from Uniswap, while $VELO holders are currently making a good return, even as emissions (and thus inflation) exceeds revenue. As we've seen, lockers remain profitable even when the system stabilize to emissions = revenue, via Velodrome's implicit speculation tax.

In the current growth era of Velodrome (emissions > revenue), it is also better for LPs (who make more revenue).

If we move beyond mechanism, the Velodrome team is better aligned with $VELO lockers than Uniswap ever was with its token $UNI holders. Despite dangling the carrot of a “fee switch” (that would direct a portion of fees to $UNI holder) for years, the Uniswap DAO has failed to pass the measure, as most of the delegated token supply is held by the team, VCs, and close affiliates. There are other issues with Uniswap DAO governance, but this isn't really the theme of this article and you should do your own research.

My suspicion is that Uniswap Labs (who makes 9 figures in frontend fees every year, none of which goes to token holders) resents having a token, which they only created as a reaction to the emergence of SushiSwap, and which is convenient to maintain the semblance of decentralization.

On the flip side, the entire $VELO supply was released from the get go, and the team is incentivized via locked $VELO.

Finally, note that 40% of the $UNI supply is not yet in circulation, and unlike Velodrome lockers, $UNI holders are not compensated for inflation.

How does ve(3,3) relate to OlympusDAO's (3,3)

(3,3) is a relatively stupid meme inspired by game theory that OlympusDAO stumble upon and ran with. It says in essence “if nobody sells we all get richer”. Of course you've got to sell to realize these profits, which is when the whole thing collapses.

From OlympusDAO, ve(3,3) takes two inspirations:

• First, the rebase mechanism. This is mostly a meme in Olympus, but serves some purpose in ve(3,3), while being non-essential. See next section for an explanation.

• The realization that you can operationalize a mature version of “if nobody sells we all get richer” via the trading flows that we talked about earlier. Two conditions need to be satisfied for this to work.

  • There needs to be real revenue underlying the protocol, otherwise you are pursuing an exercise in futility (even Olympus paid lip service to this with the prospect to invest in various projects).

  • You need to enforce the “don't sell” part, which is done via locks, and incentivize it correctly so that locking actually makes sense.

I still generally dislike the association to OlympuDAO. While there is a throughline between trading flows and a meme like “if nobody sells we all get richer” (the grotestque extreme extrapolation of the concept), nuance is not in high supply and the association is likely to lead to misunderstandings. I think the (temporary) overperformance of low-float high market cap tokens is a much better way to explain how trading flows positively impact a token's price.

What about the rebase?

One feature of the Velodrome we didn't talk about is the “rebase”, which is basically extra $VELO emissions that are distributed to lockers.

The rebase is in my opinion completely anecdotic, and is just a cute slider that can be used to further tax short-term holders. Emission control could be used to do the same, although since the token price cannot be directly controlled, this could have the not-so-dramatic effect of overpaying LPs compared to what would be optimal.

It's a useful tool, and probably worth keeping, but ultimately the system doesn't need it to be sound.

4 years is forever, so there is no way to cash out of Velodrome

Locked $VELO is placed into a veNFT that is freely tradeable. The NFTs trade at a discount to the $VELO market price. They are also being traded OTC on the Velodrome Discord server.

That being said, it is undeniable that locked your $VELO requires a long-term orientation that is not the norm within DeFi.

Are there other reasons to be bullish on Velodrome?

I am biased, but I think the team is top class, and the results speak for themselves. Despite their success, they continue to work hard and have high ambitions that run long-term.

There are reasons to be bullish in the short term too.

Regarding Velodrome specifically, it now supports liquidity and cross-chain swaps accross major chains in the Optimism Superchain. With the advent of Superchain interop, these cross-chain swaps will become even faster and cheaper.

Aerodrome on the other hand benefits from the success of Base as one of the two major L2 chains and on the Coinbase's effort to foster its success. All tokens listed on Aerodrome are now listed in the Coinbase app.

And because Base lacks a token of its own, $AERO often serves as a way for people to bet on Base's future success.

What's the BATMAN token story?

When Solidly launched, it also naturally had emissions > revenue. Someone realized that, under these conditions, the best return on $SOLID was achieved in a way that didn't grow the protocol.

What our trickster did was create two ERC-20 tokens whose supply was fully owned by them. One of these tokens was called BATMAN, and the other one ... in my memory it was SPIDERMAN, but I did some research and found one article mentioning SUPERMAN and one mentioning ROBIN. So I don't know! Crazy that these events are seemingly lost to easily retrievable history.

Then, our trickster used his existing $SOLID to direction emissions to his own BATMAN-SPIDERMAN pool, receiving more emissions in this way than the fees + bribes he would have received otherwise.

This wasn't a terrible death knell to the protocol, but it is rather sub-optimal that, while “honest” lockers were being diluted under emissions > revenue, a part of these emissions did not grow the protocol in any useful way.

And this also explains why, so far, pool deployment on Velodrome have been permissioned.

Note that Aerodrome will soon feature a permissionless pool launcher that allows permissionlessly launching pools in the basic "Uniswap-like" model, which can then graduate to the full lockonomics model (where approval is still permissioned).

Dune Dashboards

I really recommend digging into the following Dune dashboard if you want some data into Velodrome & Aerodrome:

• https://dune.com/0xkhmer/velodrome
• https://dune.com/0xkhmer/aerodrome

I, however, have been busy, working at Optimism on Bedrock and Cannon.

A lot of the action has instead been on my Twitter. See in particular this thread collecting the biggest hits.

For discoverability and archival purpose, I've ported some of these tweet threads on the block, backdated to the original date. Here they are:

• ZK Rollups vs Optimistic Rollups
• How Cannon Works
• Design of the $DJED Stablecoin
• Velodrome and why it's a superior system for incentivizing liquidity
• AMM Meditations 🍃

This is all sourced from my reading of the Nitro whitepaper, and my intimate sensual knowledge of the Bedrock design.

This actually started a Twitter thread, but grew way way too big for that.

This gets very technical. If you want to follow & get confused, I recommend referring to the Bedrock overview and my presentation on our Cannon fault proof system, and of course the Nitro whitepaper.

With this out of the way, let's dive in!

First of all, the whitepaper is great and was a pleasure to read. I recommend checking it out for all interested.

Going into this, my impression was that Bedrock and Nitro share roughly the same architecture, with some smaller differences.

The paper by and large confirms this. Still, there are quite a few differences, including a few I didn't expect. These are what this thread is about!

(A) Fixed vs variable block time

One of the most interesting and consequential things is that Nitro will work like the current version of Optimism, which has one block per transaction, and variable time between blocks.

We moved away from this because it was a departure from how Ethereum works, and a pain point for devs. Bedrock will have "real" blocks with a fixed block time of 2 seconds.

Irregular block times make quite a few common contracts wonky, because they keep time using blocks instead of the timestamp. This notably includes the Masterchef contract for distributing LP rewards that originated with Sushiswap.

I'm not sure why these contracts keep the time with blocks instead of timestamps! Ethereum miners have some leeway in manipulating timestamps, but clients will by default not build upon blocks that are too far away from the wallclock time (15s in Geth), so no problem.

Anyway, on Optimism this caused the StargateFinance incentives to run out months ahead of other chains, because they didn't account for this peculiarity!

The "one block per transaction" model has other issues. First, it's a lot of overhead for storing the chain (one block header per tx). Second, it means the state root needs to be updated after each individual transaction.

Updating the state root is a pretty expensive operation, whose cost is amortized when done over multiple transactions.

(B) Geth as a library or as the execution engine

Nitro uses Geth "as a library" which is minimally modified with hooks to call the proper functionality.

In Bedrock, a minimally modified Geth runs standalone as the "execution engine" which receives instructions from the rollup node in the same way the execution layer receives instructions from the consensus layer in Eth2. We even use the exact same API!

This has some important consequences. First we’re able to use other clients than Geth, applying a similar minimal diff on top of them. This is not just theory, we already have Erigon pretty much ready.

Second, this lets us reuse the whole Geth (or other client) stack, include at the networking layer, which enables things like peer discovery and state sync, without almost any additional dev work.

(C) State storage

Nitro keeps some state ("the state of ArbOS") inside a special account (itself stored within the Arbitrum's chain state), using a special memory layout to map keys to storage slots.

(This is purely architecture, with no user impact.)

Bedrock doesn't really have much state in that sense, and what little it has is stored in ordinary EVM contracts (to be fair, you could implement the ArbOS state layout using the EVM, though that's not what I think they are doing).

When determining/executing the next L2 block, a Bedrock replica looks at:

• the header of the head of the L2 chain
• data read from L1
• some data in EVM contract on the L2 chain, currently only the L1 fee parameters

In Bedrock, nodes can crash and immediately gracefully restart. They don't need to maintain an extra databases, because all the necessary information can be found in L1 and L2 blocks. I assume Nitro works the same (the architecture makes this possible).

It's however apparent that Nitro does a little more bookkeeping work than Bedrock.

(D) L1 to L2 message inclusion delay

Nitro processes L1 to L2 messages (what we call "deposited transactions" or just "deposits") with a 10 minutes delay. On Bedrock, they should usually be with a small confirmation depth of a few blocks (maybe 10 L1 blocks, so about 2 minutes).

We do also have a parameter called "sequencer drift" that allows the timestamp of an L2 block to drift ahead of its L1 origin (L1 block that marks the end of the L1 block range from which batches and deposits are derived).

We still have to decide the final value but we're leaning towards 10 minutes also, meaning the worst case is 10 minutes. However, this parameter is meant to ensure liveness of the L2 chain during temporary loss of connection to L1.

Usually however, deposits will be included immediately after the confirmation depth.

The Nitro paper mentions that this 10 minutes delay is to avoid the deposits from disappearing on L1 due to a re-org. This made me curious about an aspect that the paper does not talk about, and which is: how does the L2 chain handles L1 re-org. I think the answer is it doesn't.

This isn't unreasonable: post-merge there is an L1 finality delay of about 12 minutes. So if it's okay for deposits to lag 10/12 minutes behind, then this design works.

Because Bedrock tracks closer to L1, we need to handle L1 re-orgs by re-orging L2 if needed. The confirmation depth should avoid this happening too often.

Another minor difference there is that if the Nitro sequencer does not include a deposit after 10 minutes, you can "force include" it via an L1 contract call.

On Bedrock, this is not necessary: it's invalid to have an L2 block without including the deposits of its L1 origin.

And because L2 can only be 10 minutes (sequencer drift) ahead of the origin, a chain that does not include deposits after 10 minutes is invalid, will be rejected by validators and challengeable by the fault proof mechanism.

(E) L1-to-L2 messages retry mechanism

Nitro implements "retryable tickets" for L1-to-L2 messages. Say you're bridging, the L1 part of the tx could work (locking your tokens) but the L2 part could fail. So you need to be able to retry the L2 part (maybe with some more gas) or you've lost your tokens.

Nitro implements this in the ArbOS part of the node. In Bedrock, this is all done in Solidity itself.

If you use our L1 cross-domain messenger contracts to send a transaction to L2, the transaction lands in our L2 cross-domain messenger which will record its hash, making it retryable. Nitro works the same way, it's just implemented in the node.

We also expose a lower-level way to do deposits, via our L1 Optimism Portal contract.

This doesn't give you the safety net of the L2 cross-domain messenger retry mechanism, but on the flip side, it means you can implement your own app-specific retry mechanism in Solidity. Pretty cool!

(F) L2 fee algorithm

On both systems, fees have an L2 part (the execution gas, similar to Ethereum) and an L1 part (cost of L1 calldata). For its L2 fee, Nitro uses a bespoke system, while Bedrock re-uses EIP-1559. Nitro has to do this because they have the aforementioned 1 tx/block system.

We still have to tune the EIP-1559 parameters to make it work well with the 2 second block time. Today, Optimism charges a low & flat L2 fee (the L1 fee is 99% of the price anyway). I think we might have surge pricing too, but it never kicks in in practice.

An advantage of reusing EIP-1559 is that it should make it marginally easier for wallets and other tools to compute fees.

The Nitro gas-metering formula is pretty elegant though, and they seem to have put a lot of thought in it.

(G) L1 fee algorithm

What about L1 fees? This is a bigger difference. Bedrock uses backward-looking L1 basefee data. This data is pretty fresh, because it is delivered via the same mechanism as deposits (i.e. it's almost instant).

Because there's still a risk that the L1 fee will spike, we charge a small multiplier of the expected cost.

Fun fact: this multiplier (which we have lowered multiple times since launching the chain) is where all the current sequencer revenue come from! With EIP-4844, this will shrink, and revenues will come from (UX-preserving) MEV extraction instead.

Nitro does something rather much more complicated. I don't claim to understand all the intricacies of it, but the basic gist is that they have a control system that gets feedback from how much fees were actually paid on L1.

This means sending transaction back from L1 to L2 with this data. If the sequencer underpaid, it can start charging users less going forward. If it overpaid, it can start charging users more.

As an aside, you may wonder why we need to transmit fee data from L1 to L2. It's because we want the fee scheme to be part of the protocol, and open to challenge by fault proofs. Otherwise, rogue sequencers could DoS the chain by setting arbitrarily high fees!

Finally, transaction batches are compressed in both systems. Nitro charges the L1 fee based on an estimation of how well the transaction will compress. Bedrock currently doesn't do this, though we plan to.

Not doing this worsens the perverse incentive to cache data in L2 storage, leading to problematic state growth.

(H) Fault proof instruction set

Fault/fraud proofs! Quite a few differences between what Nitro does and how Cannon (the fault proof system we're currently implementing to sit on top of Bedrock) will work.

Bedrock compiles to the MIPS instruction set architecture (ISA), Nitro compiles to WASM. They seem to do quite a few more transformation on the output than we do, owing to compiling to a subset of WASM which they call WAVM.

For instance, they replace floating point (FP) operations by library calls. I suspect that they didn't want to implement the gnarly FP operations in their on-chain interpreter. We do this too, but the Go compiler takes care of it for us!

Another example: unlike most ISA that only has jumps, WASM has proper (potentially nested) control flow (if-else, while, etc). The conversion from WASM to WAVM removes this to go back to jumps, again probably for the sake of interpreter simplicity.

They also compile a mix of Go, C & Rust to WAVM (in different "modules"), while we do Go only. Apparently WAVM allows "the languages' memory management not to interfere", which I interpret as each WAVM module getting its own heap.

Something I'm curious about: how they deal with concurrency and garbage collection. We're able to avoid concurrency fairly easily in minigeth (our stripped down geth) so maybe that part is easy (more on how Bedrock and Nitro use geth at the end of this article).

However, one of the only transformation we do on MIPS is to patch out garbage collection calls. This is because garbage collection uses concurrency in Go, and concurrency and fault proofs don't go well together. Does Nitro do the same thing?

(I) Bisection game structure

The Bedrock fault proof will work on a run of minigeth that verifies the validity of a state root (actually an output root) posted to L1. Such state roots are not posted frequently, and a such encompass the validation of many blocks/batches.

The bisection game in Cannon is played on the execution trace of this (long) run.

In Nitro, on the other hand, state roots are posted with each set of batches (RBlock) posted to L1.

The bisection game in Nitro is split in two parts. First find the first state root that challenger and defender disagreee on. Then, find the first WAVM instruction they disagree on in the validator run (which only validates a single transaction).

The trade-off is more hashing during Nitro execution (see (A) above), but less hashing during the fault proof: each step in the bisection game over an execution trace requires submitting a Merkle root of the memory.

Structure the fault proof like this also reduces the concern that memory will balloon in the validator, potentialy exceeding the 4G memory limit we currently have for running MIPS.

This isn't a hard problem to fix, but we need to be careful in Bedrock, whereas there is probably no chance that validating a single transaction can ever approach the limit.

(J) Preimage oracle

The validator software used for fault proofs need to read data from L1 and L2. Because it will ultimately "run" on L1 (though only a single instruction), the L2 itself needs to be accessed via L1 - via the state roots & block hashes posted to L1.

How do you read from the state or chain (whether L1 or L2)?

A Merkle root node is a hash of its children, so if you can request a preimage, you can traverse the whole state tree. Similarly, you can traverse the whole chain backwards by requesting the preimage of a block header. (Each block header contains the hash of its parent.)

When executing on-chain, these preimages can be presupplied to the WAVM/MIPS interpreter in advance. (When executing off-chain, you can read the L2 state directly!)

(Note that you only ever need to access one such preimage, because on-chain you only execute one instruction!)

So that's how you read from L2, both on Nitro and Bedrock.

You need to do something similar for L1 however. Because transaction batches are stored in L1 calldata, which is not accessible from L1 smart contracts.

Nitro stores the hashes of its batches in an L1 contract (which is why their "Sequencer Inbox" is a contract and not an EOA like for Bedrock). So they at least need to do that, I'm not sure why it wasn't mentionned.

In Bedrock, we don't even store the batches hash (leading to some gas savings). Instead, we walk back the L1 chain using the L1 block headers, then walk down the transaction Merkle root to find the batches in the calldata.

(Again, on-chain, at most a single preimage needs to be supplied.)

Section 4.1 ends with a paragraph that reminds us that Arbitrum invented the "hash oracle trick". Credit where credit is due. Insecurity shouldn't be a reason to forget about the Arbitrum team's contributions!

(K) Large preimages

The paper also tells us that the fixed upper bound for an L2 preimage is 110kb, but does not quote the figure for L1.

In Cannon, we have something called "the large preimage problem", because one of the potential preimage to invert is the receipts preimage, which contains all the data emitted by Solidity events ("logs" at the EVM level).

In the receipts, all the log data is concatenated together. This means an attacker could emit a ton of logs, and create an incredibly large preimage.

We need to read logs because we use them to store deposits (L2-to-L1 messages). This is not strictly necessary: Nitro avoids the issue by storing a hash of the message (it's more complicated than this, but the end result is the same).

We don't store a hash because of the significant cost to compute and store it. Around 20k gas to store and 6 gas per 32 bytes to compute. An average transaction is about 500 bytes, making a batch of 200 transactions cost about 20k gas to hash as well. At 2k$ ETH and 40 gwei basefee, the extra hashing and storage costs 3.2$. At 5k$ ETH and 100 gwei that's 20$.

Our current plan to solve the large preimage problem is to use a simple zk-proof to prove the value of some bytes within the preimage (since that's all an instruction needs to access in practice).

(L) Batches & state roots

Nitro ties batches with state roots very strongly. They post a set of batches in an RBlock which also contains a state root.

Bedrock on the other hands posts its batches separately from the state roots. The key advantage is again reduced cost to posting batches (no need to interact with a contract or store data). This lets us post batches more often, and state roots less often.

Another consequence is that with Nitro, should an RBlock be challenged, the transactions it contains will not be replayed on the new chain (new correct state roots).

In Bedrock, we're currently debating what to do in the case where a state root gets successfully challenged: replay old transactions on top of the new state roots, or full rollback? (The current implementation implies a full rollback, but it’s likely to be changed before fault proofs are rolled out.)

(M) Misc

Smaller, less consequential differences:

(i) Nitro allows individual transactions posted by the sequencer to be "garbage" (invalid signatures, etc). To minimize the changes to Geth, we always throw out batches that contain any garbage.

The sequencer is always able to find those in advance, so lingering garbage entails either misbheaviour or bug. The sequencer runs the same code as the fault proof, so their definitions of what's invalid should be identical.

(ii) Nitro introduces precompile contracts, notably for L2-to-L1 message passing. We currently don't use any precompiles, preferring them "pre-deploys", i.e. actual EVM contracts that exist at special addresses from the genesis block.

Turns out we can do what we need just fine in the EVM, and this makes the node logic slightly simpler. We're not religiously opposed to precompiles though, maybe we'll need one at some point.

(iii) The Nitro fault proof does a d-way dissection. The proof-of-concept Cannon implementation uses a bisection, but we'll probably move to a d-way dissection too.

There is a very nice formula in the paper that explains the optimal value of d based on fixed and variable costs. I wish they had included concrete examples of how they estimate these costs in practice however!

Coda

No grand conclusion! Or rather: draw your own :)

If you enjoyed this, follow me on Twitter for more of the same and be notified of new articles.

I've only slightly reformatted the text (mostly links), otherwise this is the original version.

1/ I wonder how many people realize a volatile-vs-stable AMM position is an anti-leveraged position whose value varies with the square root of the change in price of the volatile asset. (In exchange for this reduced exposure, you get yield.)

2/ If the price of ETH is multiplied by X (e.g. X=4 or X=1/4), the value of an ETH-USD position will be multiplied by sqrt(X) (e.g. 2 or 1/2).

3/ Why? Because of the x*y=k equation. Assuming x is the volatile and y is the stable: If x is multipled by X (selling a bunch of the volatile), y must be divided by X such that x*X*y/X=k.

4/ The price of the volatile is given by y/x. After selling the volatile: (y/X)/(x*X) = (y/x)/X^2.

The value of the LP position is initially 2*y. After selling the volatile: 2*y/X.

So the price is divided X^2, but the LP position value only by X.

5/ However, the impermanent loss is only (1 + X)/2 - sqrt(X), because only half of the initial LP position's value was in the volatile asset.

(This number is a multiplier of initial LP position value.)

6/ How bad does impermanent loss get?

On the up side, ~2.5% for a 50% price increase, ~8.5% for a 2x, 50% for a 4x.

On the down side, ~4.2% for a 50% price decrease (halving), 12.5% for a 75% decrease (price divided by 4).

7/ Notice the asymmetry: you lose less on the down side, but that's because you can never lose more than 50% of the initial LP value (if you held and the volatile went to 0, you'd be left with 50c on the dollar).

8/ You can ask google to plot this function btw (make sure to zoom out the plot).

9/ Note that these numbers are slightly different (larger) than what you'd get with a calculator like https://baller.netlify.app, because they're multiplier (%) of the initial LP position value, whereas the calculator gives you a % of the asset value if held.

10/ Anyway, what do these numbers mean? It means that if you expect that the price could move 4x up or down, you should be getting 50% APY. In a world where $ETH can do that, so can most tokens.

11/ But who's getting that? Maybe if you're lucky and you're super early to a good project. Otherwise LPing on a inflationary shitcoin that is slowly or not-so-slowly going to 0 — but then you have another problem.

12/ LPing a a volatile-stable pair is a a sucker's game, and I do not get why people do it.

UniV3 was going to fix this, but it's not clear anybody is consistently beating impermanent loss in ETH-USDC (500M+ TVL).

13/ On the other hand, stock market (order book) market makers consistently make money. On-chain liquidity that does not rely on off-chain agents IS NOT A SOLVED ISSUE.

I've only slightly reformatted the text (mostly links), otherwise this is the original version.

1/54🧵 Thread on @VelodromeFi and why it's a superior system for incentivizing liquidity.

2/ Liquidity is super important for project tokens. A lack of liquidity makes the token price too volatile. It also prevents investors for exiting, which makes them wary to invest in the first place.

3/ (And more cynically, such a liquidity pool also doubles as another use case for the token, to prevent excessive selling.)

4/ The problem is that, for unpegged pairs, being a liquidity provider (LP) sucks, because of impermanent loss (IL). Price goes up? You would have been better holding and not LPing. Price goes down? Same thing.

5/ As an LP, you are the counterparty of adversely selected trades. You end up owning more tokens when price decreases, and less tokens when price increases.

6/ The IL numbers are not egregious, but can easily outpace fee APY. You can play with this app to get a sense: https://baller.netlify.app/

7/ For this reason, projects need to incentivize liquidity. Usually, this is done by bestowing tokens on LPs, to increase APY and make IL risk worthwhile.

8/ In this context, Velodrome and its predecessors/competitiors (@CurveFinance + @ConvexFinance, @solidlyexchange) offer two things:

1. A marketplace for liquidity: no need to roll you own pools & incentive logic, easy to advertise to prospective LPs

9/

2. The opportunity to purchase 1$ worth of incentive for less than 1$ worth of project token.

10/ How does that work? Every voting period (one week for Velodrome), token rewards ($VELO) are emitted and distributed amongst the LPs of the liquidity pools on velodrome.

11/ The amount of rewards per pool is decided by a vote. A pool receives an amount of reward proportional to its share of the total vote. To vote, users have to lock their $VELO (for up to 4 years, longer locks beget more voting power).

12/ Multiple strategies are possible. Projects can just acquire $VELO directly and lock it: this lets them direct a stream of future emissions to their pools. The point being for the price paid for $VELO will be less than the value of all future emissions.

13/ This can also be good if projects are more confident about the future price of $VELO than of their own token's. Instead of printing more and more token for liquidity rewards (creating a death spiral), they can simply rely on the emissions.

14/ Alternatively, they can "bribe" existing lockers for their votes, by assigning them rewards in their project tokens. This can be appealing to projects, even early on, because they don't need to sell a big chunk of project token at once to finance the purchase of $VELO.

15/ Here too, there is a possibility to get 1$ of $VELO LP reward for less than 1$ of project token bribe.

To make a profit (and ignoring at the moment fees and rebases), lockers want to earn more per locked $VELO than the dilution created by the $VELO emissions.

16/ Each emitted $VELO dilutes holders by (1 / (oldTotalSupply + 1)). So the minimum non-dilutive bribe per $VELO bribed is (veloPrice * veloEmitted * (1 / (oldTotalSupply + 1)).

17/ If every $VELO was locked and its vote was bribe-sensitive, you'd have to bribe one $VELO worth per $VELO emitted.

The key to capital efficiency for projects here is that not all $VELO is locked (only ~50% atm, I expect this to increase).

18/ Furthermore, not every locker is bribe-sensitive: project that bought $VELO to incentivize their pool will not vote on other pools.

Also $VELO locked for less than 4 years does not get maximum voting power.

19/ Therefore, in the worst/best case (depending on whose perpective you adopt), projects get a discount by diluting non locked $VELO, bribe-insensitive $VELO, and (to a smaller extent) short-duration $VELO lockers.

20/ We should also mention that $VELO lockers also benefit from a "rebase": token accrued every voting period that are supposed to protect them from dilution. The rebase amount for each voting period is given by this formula:

21/ (veVELO.totalSupply ÷ VELO.totalsupply)³ × 0.5 × Emissions

So if half of all $VELO is locked, lockers will collectively received 1/16 (6.25%) of all emissions as extra $VELO. This would be 36% at 90% locked and 50% at 100% locked.

22/ Why do I say "supposed" above? Well just like in OlympusDAO, rebases just make you run in place faster.

However, they do have the net effect of diluting non-locked $VELO faster compared to locked $VELO.

23/ Note that bribe-insensitive $VELO lockers (usually projects) are not necessarily worse for wear: as stated above, the purchasing assumption was that the total value of future emissions would exceed the initial purchase price.

24/ $VELO non-lockers could also be alright, assuming they are $VELO LPs (the only other use case for $VELO at the moment) and that sufficient emissions are directed toward their pool.

25/ The (veloPrice * veloEmitted * (1 / (oldTotalSupply + 1)) formula (which actually needs to be adjusted for the rebase!) from above merely represents a level of interest for bribes.

26/ This level is not particularly an attractor however. Prices could be lower if there too much emissions compared to projects appetite for liquidity rewards.

If that's not the case, the bribes total should be higher as projects compete for these emissions.

27/ In fact, if the demand for incentives outpaces the $VELO emissions, this should in theory drive the bribe per $VELO emitted close to the price of $VELO. Or even slightly above — as there is value in the convience of a turnkey liquidity mining solution.

28/ Note here that $VELO being locked has an impact. If it wasn't, then bribes being below the level of interest above for too long (because demand for liquidity reward is too low) would cause people to sell $VELO.

29/ A falling $VELO price cause the total values of emissions to fall, which would bring it back towards demand.

That system would be self-regulating, which the current one isn't because of the lock. I'm not sure which one is actually better for the long-term price of the token!

30/ So we've just described a system where projects save money, lockers make money and LPs (include $VELO LPs) make money.

Have we broken financial common sense? Is this a good old ponzu? Who foots the bill?

31/ For one, users via fees, which accrue to the lockers. But that's far from the whole story in the short/medium-term.

Instead I think most of these profits come from the value of the $VELO token itself.

32/ Just like $BTC (or in fact $USD) are not "backed" by anything, so is $VELO. i.e. there is no redemption guarantee beyond what you can get on the market (within the limitation of available liquidity, underscoring again why this is so important).

33/ Instead, a good tokenomics analysis must look at reflective loops, especially under extreme conditions.

34/ So what could go wrong? The price could tank. (e.g. as a bear market rolls around)

35/ One bad thing about $VELO (and $CRV) is that its cashflows are mostly effectively denominated in $VELO. i.e. the willingness of projects to bribe is proportional to the market value of of emissions. So when the $VELO price tanks, so should bribes.

36/ The iron rule (in a rational world...) is that the total value of bribes should never exceed the value of $VELO emitted through the vote of bribed lockers (+ a small premium representing the usefulness of the service, and eventually some inertia).

37/ Now if the total bribe value is lower than the emitted $VELO (through bribed lockers), then the total bribe value does not need to decrease.

However I would rate this unlikely in the long term, if we consider a situation where the price just decreased significantly.

38/ (Somewhat similarly, projects saving money on accumulated $VELO depends on the value of all future emissions.)

39/ This is somewhat mitigated by the fact that fees are independent of $VELO price. This could help moderate downdrafts, or at least help establish a price zone where $VELO is "cheap".

40/ This is a place where Velodrome (& Solidly) markedly improve on Curve, as the fees accruing to the lockers brings price-independent value to the token.

41/ As an interesting data point, over the past 14 days, Votium bribes for Convex lockers were ~7.6M while total curve fees were ~1.1M.

42/ Another moderating force on the downside is that projects may be driven to accumulate when the price decreases.

Why would they do this?

43/ For one, the original thesis remains unchanged: since emissions are denominated in $VELO, the savings remains similar given a flat price.

(And even better if they anticipate the price slump to be temporary.)

44/ The second reason is that the drop in price likely saturated the bribe capacity it wasn't already (see "iron rule" above). Emissions can no longer be purchased without overspending. Accumulating $VELO is the only avenue left to secure discounted liquidity rewards.

45/ (In this case, by amortizing the initial purchase over time via the value of future emissions.)

46/ So as you can see, there are some moderating factors on the downside, and no downwards spiral type effects.

47/ However I don't love that returns are mostly $VELO denominated. This means that outside of periods of very low price (where fees effectively set a floor) and periods of accumulation, the price is mostly beholden to external forces (macro & cycles).

48/ That being said, it's quite possible that we are entering one such period of accumulation as Velodrome just launched and Optimism is growing rapidly.

49/ There are many other interesting things I'd love to think & talk about on the subject of Velodrome (e.g. how $VELO is locked as veNFT and what that entails, or what a Convex-style layer could look like), but this is already super long, so I'll stop here.

50/ I hope I did convince you that Velodrome is a good liquidity incentive system, and that it at least deserves your attention!

51/ Obviously, none of this is financial advice. Don't trust what a random internet stranger has to say, validate.

Disclaimers: I have small positions in both $VELO and $CRV/$CVX. I also worked with the Velodrome team in my capacity as an OP Labs employee.

52/ A few useful links to conclude:

• Dune dashboard with TVL & usage metrics
• vfat Velodrome farming calculator
• Emission schedule

I've only slightly reformatted the text (mostly links), otherwise this is the original version.

1/16/ Earlier this week, @liamihorne asked if anybody knew about the design of the $DJED "algorithmic" stablecoin from @COTInetwork

I was curious, so I gave it a look...

2/ The stablecoin is not so much algorithmic as it is overcollateralized in a way that separates minting from collateralization.

3/ On the minting side, users can mint $DJED (stable) for collateral at 100% capital efficiency, if the supply is at least 400% collateralized (otherwise, you can't mint). In this case, the collateral is $ADA, so if $ADA is worth 100$, you get 100 $DJED back per $ADA.

4/ On the collateralization side, users can mint $SHEN for $ADA. As I understand, $SHEN represents ownership of the $ADA held by the protocol on top of 100% $DJED collateralization, and can be redeemed for that underlying.

5/ To preserve stability, $SHEN cannot be redeemed when the collateralization ration (CR) falls under 400%. It also cannot be minted when CR is over 800% (to avoid dilution of existing holders).

6/ This design is perfectly safe (as far as my basic understanding goes): the stablecoin is overcollateralized, and if you fall below 400% CR, $SHEN holder can't remove collateral.

7/ At that point it would take a 75% $ADA price drop for $DJED to be uncollateralized. I must also assume the $ADA can be liquidated if approaching 100% CR (potentially pretty bad for $ADA price if the protocol is successful).

8/ Additionally, every action from this point onward can only improve the CR:

• If users redeem $DJED for $ADA, CR goes up.
• If users mint $SHEN, CR goes up.

So quite the opposite of a death spiral.

9/ For users, this is just a fairly unremakable overcollateralized stablecoin. One exception: if you're a whale, you can get a lot of stables for your $ADA without incurring slippage.

10/ There is also an argument that this avoids liquidaton cascades. I'm not entirely convinced, since you still have the problem in extreme cases (which is when cascades occur) when you approach 100% CR.

11/ For $SHEN minters — if I'm understanding is correct — you're essentially levered long $ADA. If $ADA goes up, you own your share of the > 100% pot when you joined + what passes into this pot due to price increase.

12/ e.g. if people bought $DJED for $ADA at 100$, and $ADA goes up to $200, then only half the original $ADA is necessary to collateralize the $DJED at 100%, the other half passes to the part of the collateral that can be redeemed by $SHEN holders.

13/ On the flip side, if $ADA drops, you're bearing not only the losses of the > 100% pot, but also the losses of the $ADA that uses to 100% collateralize the $DJED.

14/ $SHEN minters also have a claim to (some of?) the fees generated by the protocol.

15/ Something interesting is that due to the fact that $SHEN cannot be redeemed < 400% CR, you probably can buy it at a discount on an AMM at that time (the discount accouting for the lack of liquidity). This is actually a good thing that promotes recollateralization.

I've only slightly reformatted the text (mostly links), otherwise this is the original version.

With the Cannon bug bounty out, it's time for me to take my best stab at describing what it is, and how it works.

Cannon is our next-gen EVM-equivalent fault proof system. It's what will keep your funds secure when you use Optimism. Read to know more!

1/44 What to expect?

• Recap on optimistic rollups / fault proofs
• Short history of fault proofs at Optimism
• Most thorough explanation of Cannon (fault proofs?) to ever grace Twitter — quite technical, but approachable
• My longest twitter thread to date

LET'S FUCKING GO

2/ Optimistic rollups in brief: users send txs to sequencer. Sequencer executes transactions and creates L2 blocks. It also (a) "rolls up" transaction into batches submitted to L1 (as calldata) and (b) submits output hashes (which we'll equate to L2 block hashes here) to L1.

3/ Validators follow the L1 chain, get txs from batches, re-execute them, and compare the resulting block hashes to the ones submitted by the sequencer.

If there's a mismatch, they challenge the incorrect block hash via a fault proof. This is where Cannon comes in.

4/ (I'm simplifying on purpose here, you can also send L1-to-L2 and L2-to-L1 txs, such as deposits and withdrawals. But this is isn't crucial to this explanation.)

5/ A rollups' fault proof system is a way to prove on the L1 chain (i.e. trustlessly) that processing the txs from an L2 block doesn't yield the block whose hash was submitted by the sequencer.

6/ (Crucially, the L2 block includes the state root: a hash of the L2 state after executing the txs in the block. This will typically be apple of discord.)

7/ The easiest way to perform a fault proof is to re-execute the whole block on L1. This is what Optimism's previous fault system attempted to do.

Unfortunately, this system had many issues.

8/ To keep costs manageable, every block carried a single transaction. This would have had very bad consequences for the scalability of the rollup in the long term. Not to mention, it's very different from how L1 does things.

9/ Second, interpreting EVM bytecode onchain is just too expensive.

This led to the original OVM: a system to deploy L2 bytecode as L1 bytecode.

10/ The original OVM design works well for simple things, but not when "context" is needed. For instance, you can't translate the L2 NUMBER opcode (returning block height) to the L1 NUMBER opcode! These opcodes needed to be translated into calls to special contracts.

11/ Similar issues played out for things like L2 contract calls.

Replacing opcodes & calls by larger EVM routines & contract calls also meant that the max size of contracts on L2 was smaller the max L1 contract size!

12/ (And indirectly this also caused the choice of requiring a patched Solidity compiler. Though it must be said other designs were possible there.)

13/ The original OVM design was a good first attempt, but it was also clear it wasn't a good long term solution.

14/ After the team (h/t @karl_dot_tech @ben_chain) & @realGeorgeHotz came up with the idea for Cannon, it was decided to drop the old fault proof system to start from a sane foundation. This was the OVM 2.0 re-genesis.

15/ (I wasn't at Optimism at that time and wasn't consulted, but these names are pretty terrible. The OVM 1.0 (just like Arbitrum's AVM) is only a VM in the most abstract sense — it's a modified instruction set translated to run on the EVM. The OVM 2.0 is not a VM in any sense.)

16/ So how does Cannon prove a [txs → block hash] mismatch if it does not execute the whole block on chain?

The solution is in two parts:

1. The challenge game
2. The single step execution

17/ The challenge game is a binary search over the execution trace of the "fault proof program".

In our case that program is one that, in first approximation, takes the L2 chain state and some transactions as inputs and emits an L2 block hash.

18/ George called this program "minigeth".

In reality its input is a set of L1 blockhashes, and the input will be a set of L2 blockhashes. I'll skip the details here as they get into the weeds of Optimism Bedrock and not super relevant.

19/ The important thing is that the input L1 blockhashes are a commitment to all the inputs we actually care about: the L2 state and the transactions. We can prove these things against the blockhash. For instance, we can prove that a batch was posted to one of these L1 blocks.

20/ To retrieve the transactions & L2 state, minigeth uses a component called "the preimage oracle".

This is a generic component that lets you go from a hash to a preimage. This is normally impossible to compute for cryptographic hashes.

21/ So the trick will be to get these [hash → preimage] mappings from somewhere. I'll explain later how the preimage oracle is implemented on & off-chain. But take it for granted for now.

22/ So we have minigeth with our preimage oracle (which btw entirely replaces geth's usual database).

We compile this to some instruction set, and execute it for our L1 blocks. This yields an execution trace, which is the list of every instruction executed during the execution.

23/ During the challenge game, both the challenger and the sequencer do this, and then perform a binary search to find the first instruction whose result they disagree on.

24/ It's a binary search because they start by looking a the result of the instruction 1/2 of the way through. If they disagree, they'll look at the instruction 1/4 of the way through, otherwise the instruction 3/4 of the way through, etc...

25/ They'll keep narrowing the range until they zero in on a single instruction they disagree on.

(Note that the challenger and the sequencer don't actually need to agree on the size of the execution trace.)

26/ What's the "result of an instruction"? What do they agree/disagree on? It's simply a Merkle root of a snapshot of the minigeth's memory!

27/ George decided to compile minigeth to MIPS. So every step in the execution trace is a MIPS instruction.

Why MIPS? It was one of the simplest instruction for which to implement an interpreter on-chain, and Go can natively compile to MIPS!

28/ To do all of the above, we need to be able to run minigeth off-chain, to (1) get the execution trace and (2) generate MIPS memory snapshots.

This is done by running the MIPS minigeth binary on the QEMU CPU emulator, and hooking into the emulator.

29/ Off-chain (in MIPS-on-QEMU), the preimage oracle is implemented via calls to a JSON-RPC endpoint (i.e. querying an Ethereum node). In minigeth, each oracle use is tagged with its type, so we know which JSON-RPC call to emit.

30/ (The most common JSON-RPC call is "eth_getProof", used very creatively to retrieve storage slots and trie nodes.)

31/ Alright, so the challenger and sequencer have agreed to disagree on a single instruction.

Next comes the single step execution.

The goal is to execute that single instruction, on the L1 chain.

32/ For this, we need:

1. An on-chain MIPS interpreter to interpret any instruction
2. Any location in MIPS memory that the instruction might read
3. Any preimage that the instruction might request

33/ (1) was simply written by George.

For (2), we already have a Merkle root of a memory snapshot taken right before the instruction (from the challenge game). We can use it to prove any memory location we might need to supply.

34/ For (3), we simply presupply the [hash → preimage] mapping by supplying the preimage, and then the hash is derived on-chain.

Note that minigeth off-chain is also instructed to save all the [hash → preimage] mappings it uses, so we have those handy.

35/ Obviously, "preimage requests" are not a native MIPS instruction. Instead, it's encoded as a read to a pre-defined memory location, which "magically" has the preimage of the hash that was previously written at another pre-defined memory location.

36/ This behaviour is implemented in the MIPS interpreter on-chain, and in the QEMU hooks off-chain.

37/ Alright, so finally we can use our pre-supplied memory and preimages to run the single MIPS instruction on the on-chain MIPS interpreter. This yields a new memory snapshot Merkle root, which can be compared to the root asserted by the challenger.

38/ If its Merkle root is the same, the challenge is valid, and the challenger wins.

We haven't talked about this here, but in this case the challenger would receive the sequencer's "bond" as a reward.

39/ And that's most of what there is to it!

‼️ A very important note before I give you some further reading.

The current implementation of Cannon DOES NOT allow you to challenge L2 blocks. Instead, it's a proof-of-concept that allows you to challenge L1 blocks.

40/ So minigeth is currently a program that takes a blockhash as input and verifies the validity of that block by re-executing it on top of the previous state.

Obviously, no L1 block should ever be invalid, meaning no challenge should ever succeed.

41/ At least that's the theory we're putting on the line in our bug bounty program. Break this assumption and make 50k$ !

42/ That was a looong thead, but I still had to simplify quite a bit and ommit some details.

So, were can you learn more about Cannon? I'm glad you ask!

43/

• There's the github repository
• A high-level overview
• A more detailed overview]detailed

44/ Now, go forth and spread the chant

cannon cannon cannon

Cannon! Cannon! Cannon!

CANNON CANNON CANNON

If you're jumping aboard this wagon, OlympusDAO is a decentralized app that turned quite a few heads due to the high promised APY, sharp price increase, and even sharper market cap increase.

Last time we looked at what the protocol did mechanistically (the findings will be recapped shortly). This time, we're looking at the consequence of the mechanisms for price, market cap, valuation, etc.

(It goes without saying that all of this is a fun educational analysis, and none of it is financial advice.)

The Bottom Line

I won't tease you further, here are the basic conclusions (presented out-of-order compared to the main text):

1. OHM (Olympus' token) has extremely high programmed inflation, but the staking product protects stakers against dilution.

2. At first look, it looks like staking also increases ownership over the total OHM supply when less than 100% of the supply is staked. In practice, it seems likely that most of the unstaked supply is made out of liquidity pool reserves owned by the protocol, meaning any increase in ownership is compensated by a dilution of the treasury (which underpins the value of owning the protocol!).

3. As a result staking is very much useless (economically neutral) as a mechanic, besides as a way to drive narrative and hype (high APYs!!).

4. As a first approximation, the treasury value offers a floor price on OHM's market cap — however this notion is thwarted by the fact that the OHM treasury contain OHM tokens (in the liquidity pools underlying the LP tokens). So when the price of OHM goes down, so the does the market value of the treasury.

5. In reality, there exists a price > 1$ such that the OHM market cap is equal to the market value of the treasury. Let's call the treasury value at that price the sustainable value.

6. The sustainable treasury value must exist becau

   • The treasury value decreases slower than the market cap (notably because it contains stablecoins), so if the price keeps dipping, at some point the market cap "catches up" with the treasury value.

   • Part of the treasury is denominated in stablecoins, and these were collected when the OHM price was much higher than 1$. Meaning the equilibrium (sustainable) price is > 1$.

7. In any case, the "backing per OHM" advertised by Olympus and the "treasury value" advertised by Wonderland are misleading since these value go down when the price goes down.

8. If the high inflation (rebase) rate persists, OHM will eventually go down to 1$, at which point a backstop in the inflation logic prevents further inflation until the price increases again.

9. Bond sales are the real interesting mechanism. They are a programmed way to raise funds for the treasury via further inflation. Wether this is inflation is dilutive to OHM stakers depends on whether the bond sales discount is lower or higher than the current price premium (see below).

10. When discussing Olympus valuation, it will be much more useful to use gOHM (indexed OHM — i.e. wrapped staked OHMs that do not dilute due to rebases) as a reference.

11. A useful model to value Olympus' market cap is to assume it should trade at a premium to the sustainable treasury value. This premium is justified by the fact that gOHM is essentially (a) a voucher for ownership of part of the treasury + (b) a call option on the gOHM price. The call option part is the premium.

12. The premium essentially depends on the sustainable backing per gOHM + the expected future premium.

13. The backing could increase for multiple reasons: yield farming with the treasury, VC-like investments with the treasury, or new products that increase the treasury, like Olympus Pro.

14. The backing also naturally increases through bond sales, as long as the bond sales discount is lower than the current premium.

15. Because the current premium depends on the expected future premium, the process is reflexive (it's a "Keynesian beauty context" or "a fixed-point calculation"). Each participant must try to guess how every other participant will value OHM.

16. Ignoring this issue for now, what price should you be willing to purchase OHM at. i.e. what premium are you willing to accept?

17. I propose the formula: maximum_purchase_price = expected_sustainable_treasury_backing * (1 + expected_premium) - current_price * (risk_free_rate + risk_premium) (We already discussed all terms except the risk-free rate and the risk premium.)

18. The risk-free rate is the return rate you could get without taking risk. No such thing as "risk-free" in crypto, but you could set that to the lending rate on Aave or Compound for instance. (Or just use the US bonds rate!)

19. The risk premium is the return rate you demand to be compensated for the risk that you are taking.

20. See the article for an example of thow this computation can be borne out in practice.

21. I also briefly discuss the relationship between the premium and the treasury size. Mostly, as the treasury grows, it's natural to expect that the premium should decrease: the team doesn't scale linearly with capital, and investment opportunities become scarcer.

22. It's important to note that the Olympus team is aware of some of these issues. See this whitepaper by Zeus and Indigo, which proposes "an evolution from the existing staking-centric model in favor of a bond-centric model". The goal are to truly lock away part of the supply (which staking doesn't do) and enable selling "internal" OHM-OHM bonds (just like US treasury bonds but with OHM instead of USD) at high volume without adversely affecting the OHM price.

23. The team also came up with the Olympus12 roadmap, which outlines a strong (imho) and extremely interesting action plan for bolstering the economics of OlympusDAO going forward. I do think the success of the plan hinges on whether they will manage to convince projects and people to effectively treat OHM (more like gOHM) as a token to put on the balance sheet / in their long-term portfolio, and not just speculation & arbitrage. With the right mix of incentives and interesting use cases, they might be able to.

Table of Contents

• The Bottom Line
• How Olympus Works: Recap
• Example
• OlympusDAO Valuation
  • Olympus' Assets
  • Treasury as Market Cap Floor
  • Sustainable Value
  • The Floor in Practice
  • The Premium, Risk-Free Rate and Risk Premium
  • Pricing gOHM
  • Evolution of the backing per gOHM
  • Modelling the Premium
• Olympus in the Long Run
• On the Uselessness of Staking
• On the Usefulness of Bonding
• Coda

How Olympus Works: Recap

If you missed the previous article, here is a copy of my (fairly detailed) summary of OHM's mechanisms. This should be all you need to follow along!

1. The total supply of $OHM inflates at the staking reward rate every ~8 hours. This inflation is redistributed among stakers. The inflation distribution event that happens every 8 hours is called a rebase.

2. The staking reward rate is set by the OlympusDAO policy team. For the longest time, this reward rate was 0.35%. It is currently 0.2%, on its way down to a target of 0.16%. At 0.35%, this implies an inflation of 4487%. This is also the minimum staking APY in OHM (if 100% of the OHM is staked, otherwise it will be higher). At 0.16%, this implies a 475% inflation (yup — exponentials are weird).

3. OlympusDAO has a treasury composed of stablecoins and OHM-stablecoin [liquidity pool (LP) tokens][lp-tokens]. The treasury is constituted by selling bonds (see below).

4. A central concept is the "risk-free value" (RFV) of the treasury. This is simply 1$ for stablecoin. For LP tokens, it is the price the token would take if the OHM price fell to 1$. Controversially, this means that part of the RFV of the treasury is made of OHM tokens (in the liquidity pools).

5. Rebases can only go through if there is 1$ of risk-free value in the treasury for each OHM in existence including the newly-minted ones. This sets a soft-floor if 1$ on the OHM price, assuming that the OHM market cap should always be at least as large as the risk-free value of the OHM treasury.

6. The protocol maintains a metric called "the index" which is how much OHM you would own if you staked a single OHM on the day the protocol launched (currenty 74). Recently, Olympus launched the gOHM ("governance OHM") which "wraps" the indexed amount of staked OHM. The main avowed purpose was to enable the trading of staked OHM on other chains.

7. Staking comes with an optional warm-up period (currently disabled) which forces people to wait a configurable amount of time before their OHM tokens are staked.

8. At any time, people can purchase OHM bonds using various stablecoins and OHM-stablecoin LP tokens. The policy team can add, remove or tweak these bond markets. The bonds are usually sold as a small discount to the OHM market price. The bonds grant newly minted OHM tokens to the buyer. These tokens vest over a configurable period, which has always been 5 days.

9. The DAO takes a (configurable) fee over every bond sale, although this is currently set to 0, and it's rather hard to search historical state to see if it was ever set differently.

10. Bond pricing uses a notion of risk-free value (RFV). The risk-free value of stablecoins is equivalent to their market value. For LP tokens however, Olympus assumes a worst-case scenario where OHM is worth 1$, and prices the LP tokens accordingly.

11. Bonds are priced differently depending on the token used to purchase the bonds. The bond price is determined by the formula bondPrice = min(BCV * debtRatio + 1, minimumPrice), where:

    • One bond grants one OHM after the vesting period.

    • For simplicity, I ignore the decimals on minimumPrice and bondPrice (assume those are infinite precision numbers), and assume that debtRatio is a value between 0 and 1.

    • BCV is the bond control variable, set by the policy team for each token

    • debtRatio is a ratio between (a) the risk-free value of all tokens used for bond purchases (tallied at the moment of purchase) scaled by the remaining vesting time; and (b) the total OHM supply.

      Note that the numerator and the denominator have different units (risk-free USD and OHM), and consequently, the debt ratio rises faster when the OHM price is high.

    • minimumPrice — as the name indicates. However, once a bond purchases occurs above the minimum price, it is then set to 0, allowing subsequent purchases to occur below the bond price.

    There is maximum amount of debt (denominated in risk-free value) allowed per token, preventing the emission of too many bonds, and offering some protection against attacks (e.g. if a stablecoin was to lose his peg).

    Because the formula is not based on the market price of OHM, the bond price can occasionally exceed the market price!

Example

To make things more concrete, I'm also copying verbatim the example from last time in this section. This will help you have a better sense of the mechanisms that we are discussing.

Let's assume that

• OHM is worth 70$ (as it was when I wrote this example)
• the OHM-DAI liquidity pool contains 100 OHM (and therefore 7000 DAI, which we'll write 7000$ for convenience)
• the ownership of the pool is split accross 100 LP tokens, each of which is worth 0.01 * 2 * 7000 = 140 $
• the current debt ratio for the OHM-DAI bond depository contract is 5%
• the bond control variable (BCV) for the OHM-DAI contract is 207 (as it is at the time for writing)
• the (thrice-daily) rebase rate is 0.24% (as it was when I wrote this)
• the DAO fee is 1%. This is currently 0% in both v1 and v2 bonds, and it's particularly difficult to find historical values (you'd have to run your own node and re-execute transactions, since value changes are not even logged).
• the RFV backing per OHM is about 26$ (as it was ...)
• the market-rate backing per OHM is about 60$ (as it was ...)

Under these condtions, the risk-free value (RFV) of such a DAI-OHM LP token is 0.01 * 2 * sqrt(100 * 7000) ~= 16.73 $.

If a user uses a single LP token to purchase bonds, he would get back bonds that would grant (16.73 * 100) / (100 + 5 * 207) == 2.32 OHM. This represents a "premium" of 0.73 OHM compared to the market price, which is equivalent of an effective OHM price of 140 / 2.32 = 60.34 $, or an effective discount rate of 14% compared to the market price.

A more realistic discount assessment would also consider that during the vesting period of 5 days, the OHM supply will inflate by around 3.7% (1.0024^(3*5) ~= 1.037), so the effective discount is closer to 10%, assuming the buyer redeems at the end of the vesting period (of course, Ethereum transaction prices makes the amounts we're discussing completely unreleastic, but whatever).

We'll note that v2 bonds solve this issue by staking the granted amount immediately, and so there is no loss due to inflation.

So in this example, 2.343 OHM are emitted (1.01 * 2.32 to account for the DAO fee), backed by 140$ of market value and 16.73$ of risk-free value (7.14$ per OHM).

In this case, the RFV backing per minted OHM (7.14$) is significantly less than the current RFV backing per OHM (which is 26$). This means that each OHM emitted in bonding decreases the backing per OHM.

This is an inherent property of LP bond sales. Stablecoin bond sales, on the other hand, tend to increase the RFV backing per OHM.

OlympusDAO Valuation

The central question in our analysis is going to be "how should OlympusDAO be valued?". Meaning: what should the market cap on the OHM supply be?

As we shall see, this is not an easy question, given that on one hand the treasury value is in flux, and the highly dilutive nature of the token on the other hand.

There is of course no definitive answer to that question, but we can give many clues as to what an answer can look like.

A lot of the data I'm going to use in this analysis, come from the excelent Dune dashboards by shadow (Olympus' policy lead), in particular the Olympus dashboard and the Olympus Policy dashboard.

Olympus' Assets

OlympusDAO has three "assets":

• the treasury
• the DAO funds
• its "team members" (i.e. the people paid by the DAO to develop OlympusDAO, either by means of code, marketing, business development, ...)

First, let's precise the difference between the treasury and the DAO funds.

The treasury is by design a reserve that backs the value of OHM. There is no peg, and so this reserve is allowed to be less than the market cap of OHM (as it has been for most of its history), or even greater (though this should only be a temporary aberration, as we'll argue shortly).

The DAO funds are accrued via the DAO fee perceived during a bond sale. They are managed by the DAO's multisig signatories, which used to be the de facto leaders of the project. With the introduction of the gOHM token, token governance now has a purview on how the DAO spends those funds.

Although I haven't looked into it, DAO funds are traditionally used to pay the team and perform other interventions (e.g. usage incentives, strategic token acquisition, such as CRV or TOKE, etc...).

However, if the DAO pulls in enough fees to properly fund development, it is perfectly possible that it could redistribute part of the fee cashflows to users in various ways (dividends, token buybacks, or a combination of both *).

*) In Olympus' case, there is an extremely elegant way to do this: use DAO funds to purchase bonds, then deposit the received OHM in the staking contract where it will automatically be distributed amongst all stakers (cf. previous article to see how this distribution works on a nuts-and-bolt level).

The team members should only be considered an asset insofar that users are confident that they are working to accrue value to token holder, whether by growing the treasury, accruing DAO fees to be redistributed, or other mechanisms like airdrops.

Treasury as Market Cap Floor

So, how do we value this?

Well, Olympus must at least be worth as much as the treasury + the portion of DAO funds that hasn't been yet earmarked for a specific use. The DAO fee percent is currently 0, and though I don't have the data, I don't believe it was ever very high. We'll thus make the simplifying assumption that its value is negligible compared to the treasury.

The project must be worth at least as much as the treasury because, in the worst case, token holders can vote to dissolve the treasury and compensate OHM and sOHM holders in proportion of their holdings.

However, things are not entirely as simple as this, because the treasury does contain OHM tokens (underlying half the value of the LP token). So when the price of OHM goes down, so the does the market value of the treasury.

The market value doesn't work as a price floor, but neither does the risk-free value (RFV, the value when OHM is priced at 1$). That price is actually too pessimistic.

In reality, there exists a price > 1$ such that the OHM market cap is equal to the market value of the treasury. Let's call the treasury value at that price the sustainable value.

Sustainable Value

In this section, I will show why the sustainable value exists. We'll illustrate how a decreasing OHM price decreases the market value of the treasury, then show that this decrease is less than the price decrease, meaning that at some point, the market cap falls below the market value of the treasury. The market value of the treasury at this point is what we call the sustainable value.

(If you accept this premise and are not interested in getting more supporting intuition as to why it is true, feel free to skip this section.)

The Olympus treasury comprises a lot of LP tokens. The market value of those is made by half by OHM tokens. This means that as the OHM price drops, so does the market treasury value.

Even simple x*y=k AMMs are not intuitive, so I'll avoid off on giving a full exposition. However, to give some intutition, as the price falls and people sell OHM into the liquidity pool, these three things happen:

• The market value of the OHM reserve of the liquidity pool drops.
• The OHM reserves of the pool increase.
• The stablecoin reserves of the pool decrease, by the amount of OHM sold to the pool at some "average" price between the old OHM price and the new OHM price.

So that's not great: not only does the value of the whole OHM part decrease, but the stable reserves also decreases, and decreases more than compensated by the increase in OHM reserves valued at the new market price.

Let's do a simple example for illustration's sake.

• Assume a liquidity pool with 100 OHM valued at $69 each.
• The pool is thus worth (2*100*69 == 13,800$).
• Using the x*y = k AMM formula, we get k == 690,000.

Now assume someone sells 10 OHM into the pool.

• We have 110 OHM, so to preserve the value of k, the new amount of stablecoin becomes 690,000 / 110 == 6,272,72.
• The new value of the pool is the double of this, i.e 12,544.44.
• The new token price is 6,272,72 / 110 == 57.022.

Consequently:

• The token price dropped 17.36%
• The pool's total value dropped by 9%.

Note that the relationship between those things is not linear and depends on the parameters (e.g. the impact of a 10 OHM sale would have been smaller on a bigger pool, although the impact of a sale 10% the size of the pool would have been the same).

Using the Olympus Dune dashboard, we can see that (at the time of writing) the treasury market value is $484,110,067, while the risk-free market value is $237,941,247.

The dashboard does warn that the values might not be accurate because of the v2 migration. There is some discrepancy from the Olympus app. For instance, the market cap on dashboard is $710M while it is $680M on the app. The app seems to put the market value of the treasury (as determined form the backing per OHM seems a few 10s of % higher).

So let's be conservative and say that the RFV of the treasury is 2-4x lower than its market value.

So as the OHM price decreases so does the market value of the treasury, albeit potentially slower than the price.

Also, the treasury also contains stablecoins in addition to LP tokens, which means it will fall even slower percentage-wise than the OHM price.

Because this market value of the treasury decreases slower than the price, it means there must necessarily exist a price (the sustainable price) such that the OHM market cap is equal to the market value of the treasury.

Because part of the treasury is denominated in stablecoins, and these were collected the OHM price was much higher than 1$, it does mean that the sustainable price is higher than 1$, and hence the sustainable value is higher than the RFV.

As simple way to see that is that this is like solving the equation 100 + 10x = 100x (e.g. imagine the treasury holds 100$ and 10 OHM and the market cap is 100 OHM, and x is the OHM price). In this case x = 100 / 90 > 1.

What this analysis shows is that the "backing per OHM" advertised by Olympus (as well as the "treasury value" advertised by Wonderland) are misleading since these value go down when the price goes down. However, the RFV value of the treasury is too pessimistic as a floor price, since there exist an intermediate "floor price" where the market cap is equal to the market value of the treasury.

The Floor in Practice

Interestingly, the theory that the market cap should never dip below the market price (the point at which it dips below being the sustainable price) has been put to the test recently, as OlympusDAO and its forks experience an accelerating crash over the past few weeks.

OlympusDAO is currently hovering at 25% over the market value of the treasury. Wonderland, Olympus' biggest and most famous fork, actually dipped under the market value of its treasury and a vote was held to dissolve the treasury, which failed narrowly, but with a majority of holders against dissolution.

For context, in addition to the price crash, Wonderland was shaken by the revelation that "Sifu" — its treasury manager — was a former convicted scammer.

(As an aside, I consider this vote rational and see it as mostly a vote of confidence. Since Sifu was removed, as long as you trust the rest of the team with the treasury, there is no reason to not wait to recapture a premium over the treasury value. Such rebounds are common in crypto if the project does not immediately implode. If things don't improve, the treasury can still be unwound later — there is a no-cost upside in waiting a little bit.)

The Premium, Risk-Free Rate and Risk Premium

If the sustainable value of the treasury represents a floor for the market cap, what causes it to rise above that level? This is what we'll call the premium.

Basically, in the case of OlympusDAO, a big part of the premium comes from the team and the possibility of future earnings. If team members roll out new features or new products that will accrue value to token holders, this possibility should be captured in the token price.

The easiest way to think about the premium is that when you buy the token, you really buy two things: (a) a voucher for a slice of the treasury at its current (not sustainable) value; and (b) a call option representing the potential for the sustainable value of the treasury to increase. This call option part is the premium.

In particular, the call option part represent the expectation that the treasury backing per inflation-indexed token (gOHM) will increase. It's important to only consider gOHM, not OHM, because there is no expected backing increase per OHM — since it inflates so much due to the rebases.

There are a few ways the backing per gOHM could increase:

1. new initiatives increase the value of the treasury without dilution
2. yield farming with the treasury
3. venture capital investments with the treasury
4. bond sales, as long as the current premium is higher than the bond discount

Olympus actually rolled out an initiative that increased the treasury value at no cost or dilution to token holders, in the form of OlympusPro, a side product that allowed other protocols to conduct their own bond sales based on the Olympus model. The Olympus treasury captures a 3.3% fees on every bond sale conducted on Olympus Pro.

Another potential source of premium is the utilization of treasury funds to generate yield.

Here we need to be careful, because it wouldn't make sense to say that the treasury funds can be used for yield farming (e.g. lending on Aave for a 5% APY) and thus the premium should increase accordingly.

The idea here is that the yield farming opportunity is also open to you. Say you have stablecoins sitting around, instead of buying gOHM (or equivalently, buying and staking OHM), you could yield farm yourself. The premium should only capture returns in excess of that yield.

In traditional finance, this notion is known as the "risk-free rate" and is typically given by the yield on AAA-rated treasury bonds, in particular the US treasury bonds.

(If you're interested in treasury bonds and how they behave, see my previous article on the topic: one, two.)

This is not to say Olympus shouldn't yield farm. Quite the opposite: it's much easier to produce excess return on the risk-free rate if you just happen to have funds that you can yield farm with to produce this rate in the first place.

In fact, Olympus is yield farming (see also this remark).

Now, there is nothing such as a risk-free return in crypto. You're always at least taking smart contract risk (bugs, hacks).

However it's fair to consider that buying OHM high abvoe the sustainable rate is riskier than yield farming on Aave. If we consider that both projects have been extremely well audited, then OHM additionally exposes you to price (premium!) volatility. You need to be compensate for that risk, and that is the risk premium (not the same thing as the OHM price premium over the sustainable price!).

Finally, another source of premium would be to conduct venture capital (VC) investments using the treasury. Here the premium stems from a few factor:

• The treasury is large, which makes OlympusDAO a privileged partner compared to poorer individual investors.
• The treasury is also large enough that it can diversify by betting on numerous projects, which is central to the sustainability of the venture capital model (where you only have a few winners that make up for all your losers).
• The OlympusDAO team is talented and probably better able to determine a project's odds of success than the average OHM holder.

Though it has been discussed online, there is no indication at the moment that the Olympus team intends to engage in venture capital investments.

Last, but not least, the sustainable backing per OHM increases naturally via bond sales, as long as the discount price is lower then the current premium, i.e. as long a bonds are sold for more than the sustainable backing per OHM.

This mechanism is the main driver of treasury growth, and we will revisit it below. Unlike the previous mechanisms, it is "dilutive" in the sense that it mints new tokens — although if the backing per gOHM increases, this is not really a problem.

Pricing gOHM

Let's put all the pieces from the last section (premium, risk-free rate and risk premium) together and attempt to see if we can come with a "fair" price for gOHM, given our assumptions as investors.

Let's assume, for simplicity sake, that the sustainable price of gOHM is 100$ at present, and you expect the sustainable price to increase by 50$ over your investment horizon (say one year). How much should be willing to buy gOHM for?

A naive (and wrong) answer to this would be to say that any price under 150$ is fine, as it will net you a you profit. This is wrong for a two reasons:

• At your point of reference in the future, gOHM should still trade at a premium, so if the sustainable value is 150$, the price of gOHM will be higher than that.
• If on the other hand, if we assume that the premium will be 0, it's still wrong to purchase at say 149$, because you're only making a 1/149 = 0.6% return. This is much less than the risk-free rate (e.g. 5%).
• But buying so that you make exactly the risk-free rate is also wrong. You're taking significantly more risk by buying OHM, therefore you should expect higher returns to compensate you for that risk (the risk premium).

Therefore your buy price should be any price under:

expected_sustainable_treasury_backing * (1 + expected_premium) - current_price * (risk_free_rate + risk_premium)

Where expected_premium, risk_free_rate and risk_premium are percentages (quantities between 0 and 1).

Therefore, to value gOHM, you need to make the following predictions/decisions:

• How much will the (sustainable) treasury backing per gOHM increase?
• How will the premium change?
• What are my "risk-free" alternatives? i.e., what do I use as risk-free rate?
• How risky is the investment? i.e., what risk premium do I demand in order to feel like the potential upside is worth the risk?

Let's plug in some numbers. Say the current premium is 25% (so the price is 125$) and I expect this to remain stable. Say I consider 5% to be my risk-free rate, and I'd like to be compensated at 10% for the risk I'm taking. Then you get:

150 * (1 + 0.25) - 125 * (0.05 + 0.1) = 168.75

Since the current price (125$) is less than 168.75$, you should buy gOHM, and if all your predictions are uncannily accurate, the token will be worth 150 * 1.25 = 187.5$ in a year. You will sell for a 62.5$ profit, which is a 50% return rate — as expected since the backing increased 50% and the premium didn't change. This is higher than your desired 15% return rate (5% risk-free rate + 10% risk premium).

Evolution of the Backing per gOHM

The formula above asks you to predict the future sustainable backing per gOHM. Let's now look at how you could do that. The value actually depends on a couple of factors:

1. The percentage of the OHM supply staked (this has been fairly stable at 90% for most of of Olympus' history, though it has dipped to the low 80s over the last month. The lower the percentage of the supply staked, the faster stakers (hence gOHM holder) accrue ownership over the total supply at the expense of non-stakers. At 90%, the return rate is 6.6%.
2. The dilution incurred by LP bond sales.
3. The amount of bond token sales, and their discount rate.

One big question to solve here is "who are the non-stakers?". I actually expect that a significant part of the non-staked supply is made of the OHM token backing the LP tokens owned by the treasury!

This explanation fits perfectly the fact that the staking percentage decreased over the last month: as OHM price decreased, the amount of OHM underlying the LP token naturally increased (as OHM was traded in in exchange for stablecoins)!

This means that even the increased ownership for stakers comes at the expense of the treasury (whose OHM tokens keep diluting). I think it's fair to model the return on staking as essentially nil, but preventing rebase-induced dilution.

So we're left with bonding.

The sustainable backing by gOHM can either increase or decrease from bond sales, depending on whether the increase in the sustainable treasury value compensates the dilution incurred by the bond sale.

It depends on the current premium and the bond discount: if the discount is smaller than the premium, then the backing per newly minted OHM is higher than the current sustainable backing per OHM (therefore very slightly increasing to total backing per OHM). If on the other hand the discount is higher than the discount, then the backing per OHM decreases.

Modelling the Premium

There is one question that all of the above doesn't really answer directly — how large should the premium be?

Well, imagine all investors run the above calculation. Each of them will come up with their own "acceptable" premium. In our example that would have been 68.5% ((168.5 - 100) / 100). The actual premium will be the premium such that no one will sell any investor OHM with a premium lower than their premium of choice.

In (the messy and complex) reality, investors will need to try to anticipate what this premium will be in order to price their own premium of choice. This makes the whole market pricing affair a reflective process known as a Keynesian beauty contest. If you're more mathematically inclined, you could also say the market price is the result of a fixed-pointed computation.

Now, we could also look at the premium from another angle. And that is: how is the premium expected to change as the treasury increases or decreases?

The key question is whether the premium should be flat (since the team's ability to deliver new successful projects is only very weakly correlated with the size of the treasury), or proportional to the treasury size (in the case of venture capital investments).

Since both of these make sense, a simple model of the premium would be one where the premium decreases as the treasury grow. In this model, the excess value incurred by the premium (i.e. premium * sustainable_treasury) grows along with the treasury, but at a decreasing rate. Think of square-root like functions.

This decrease in growth represents the fact that the team's potential does not increase linearly with the treasury (you could hire more people, but it's well established that company productivity does not scale linearly with the number of hires). It also represents the fact that there are diminishing returns when you sling around a large amount of capital: the yield farming returns tend to be lower, which decreases your edge on the "risk-free" rate. Similarly, quality venture capital opportunities might dry up.

A more complete model should probably take into account that if the treasury value is low, then the premium should grow faster than the treasury (as it enables new essential hires, new venture capital opportunities, etc). However, Olympus' treasury is already large ($484M), so we'll eschew this part of the model.

Ok. All good and fair, but concretely, what would a good premium be for Olympus today?

One answer to that is that you just run the price calculation from above. But to do that, you need to estimate what the premium will be!

Well, I'm a bit of a loss here.

First of all, investors are not rational, and I feel fairly confident to say many (most?) of them never really did understood how Olympus worked. The price is still a reflective process of investor's willingness to pay, but without common knowledge (such as this blogpost! though at this point I have to wonder how many investors will read this novel I have written), it's hard to know what investors will think — more likely their willingness to pay will be ruled by momentum, hype, FOMO and FUD.

The current premium of 25% over the market rate doesn't feel particularly extreme to me, neither does it feel particularly low. Note that this is a premium over the market value, not the sustainable value (which I haven't computed — reach out if you feel like doing that!).

Looking at Olympus Pro, it has so far yield about $2M in fees, or about 0.5% of the treasury size. Since it was introduced 4 months ago, we can extrapolate that it will yield about 1.5% of the treasury value over a year. If the Olympus team introduces some new products, these returns could start adding up.

Additionally, one should look at the returns that OlympusDAO is getting on its yield farming activities.

If you have opinions on this (backed with data) — I'd be interested to talk to you!

Olympus in the Long Run

How can we expect Olympus to behave in the long run?

Well, the fact of the matter is that OHM is designed to inflate until its price drops to 1$. This path could however be stretched indifinitely if the team decides to drastically lower the rebase rate. If they lower this rate enough, then the earnings from fees on bond sales (both from Olympus and Olympus Pro), the treasury value could increase faster than OHM dilutes.

In the case where the rebase rate stays high, then OHM will decrease in price until it reaches 1$. This is not super relevant: as I've argued before, it's the price of gOHM (indexed, inflation-protected OHM) that is relevant!

When the price of OHM reaches 1$, a backstop prevents any further inflation, whether via discounted bounding or via rebasing. This would be rather crippling for the protocol so I would expect the team to take some measures before that happens (whether that's curbing the rebase rate, or something else).

Other than that... it could continue chugging along and raising money via bond sales. At the end of the day, gOHM is a voucher to a portion of the underlying treasury and a call option to speculate on the fluctuation of the premium.

The real question for Olympus and OHM holders is what the team is going to come out with next! The team has plans, see the Further Reading section!

As for questions of price, there are two questions of interest:

1. How fast can the sustainable treasury value increase?
2. How will the premium evolve?

At present, the answer to (2) is purely a question of market psychology, meaning keeping a finger on the pulse of the hype. Crypto markets are not super mature yet, and Olympus is still relatively niche amongst crypto markets.

More surprisingly, (1) similarly depends and on the premium, and thus on hype. When the premium is high, the sustainable treasury value increases rapidly. Similarly, I would expect more bonds to be sold when the hype is high and the price is on the uptrend.

On the Uselessness of Rebases

At this point, I want to emphasize something that has been implied, but hasn't been made crystal clear at this point: staking and rebases are absolutely useless in Olympus, and serve no purpose besides creating hype and a narrative based on widespread misunderstanding of Olympus' mechanics.

As an Olympus dev says: "I think one of the biggest mistakes the DAO made was allowing the APY become the focus of anything."

Basically, staking protects the inflation created by rebases. It's both the poison and the cure.

Since not 100% of the supply is staked, staking does entail a transfer of ownership from non-stakers to stakers. But as mentionned before, it's likely that most of the unstaked supply lives in LP pools whose tokens are owned by the Olypus treasury. Which means the small ownership increase gets cancelled by a loss of value of the treasury.

One thing this achieves, however is to disincentivize anyone but Olympus to provide liquidity. I'm not sure how good or bad that is... On the one hand, Olympus can monopolize the transfer fees, on the other hand, that's just less liquidity period.

This last point is also moot with the introduction of gOHM since you can now provide liquidity for gOHM which wraps staked OHM.

In general, the whole existance of gOHM calls the usefulness of rebases into question, since it abstracts away the whole rebase/staking mechanic.

I think rebases (inherited from Ampleforth) were included because OHM was envisioned as some kind of stablecoin. But at present, Olympus doesn't perform rebases that lower user balances (which would be necessary to let the price dip below 1$ and bring it back to that level).

On The Usefulness of Bonding

We haven't talked about this much, but one of Olympus' big idea was "buy liquidity, don't rent it".

This is based on the observation that liquidity providers can be quite mercenary, and will move their liquidity elsewhere once incentivization stops. Hence you're only ever "renting liquidity". And as we all know, in the long term, renting is more expensive than buying outright.

The idea makes a lot of sense, and for projects where you can expect a high enough premium, bonding can make a lot of sense.

It solves two fundamental problems:

• Raising all the capital upfront means good project get a bad deal. Since your project is completely unproven, it will necessarily be valued with a lot of circonspection. (Although sometimes, the opposite is true, where project is overvalued on the basis of hype...) Raising money as you go with bonds, in a way that is not (or not very) dilutive to token holders can make a lot of sense for growth-oriented projects.
• It removes the problem of deciding when, how, how much, and from who to raise. (Olympus' founder Zeus made this very same point). Instead, the decision is made by a pre-determined algorithm. An hybrid mode is possible, where a project decides on a number of bonds to be sold, and lets the algorithm figure out the execution.

Now, some caveats.

First of all, not every project is shaped as Olympus, i.e. as a big pot of money. Many project pass their revenues directly to the users, and only keep a small amount in the treasury (which are equivalent to the Olympus's DAO funds). The model can still work for these project, but the premium has to be modelled on the basis of return on capital instead.

Second, it's not quite clear that the way Olympus does bond sales (on the basis of the bond control value and the debt ratio) is necessarily the best way. I can imagine much simpler mechanisms to achieve the same goals (e.g. a Dutch auction where each successful purchase bumps the price back up). The model is not obviously wrong either, it's just not obvious (to me) that it is the best.

I do expect that Olympus Pro offers more flexibility on this matter, but I haven't reviewed that codebase.

Further Reading

• A correct model of OlympusDAO: A harsher (but oh so much terser) criticism of OlympusDAO than I make, to which I nevertheless subscribe excepted for valuation purposes. The memes criticized here are not dead though, as evidenced by this presentation of OHM (which isn't bad, but parrots the kool-aid a bit too much).

• Zeus on Healthy Debt: the cascading liquidations of loans secured against an OHM collateral was a big driver in the OHM price crash.

• Liquid Interest Rate Markets through Olympus Bonds (+ governance discussion): A whitepaper by Zeus and Indigo from the Olympus team. It proposes "an evolution from the existing staking-centric model in favor of a bond-centric model", showing that the OlympusDAO leadership is aware of the issues raised in this piece. I'm under the impression they willingly downplay (or maybe are still deluded about) the uselessness of staking while at the same time phasing it out in favour of "internal OHM bonds" which are fixed-term bonds purchased in OHM that give a return in OHM (just like US treasury bonds, but using OHM instead of USD). The big advantage there is locking away the part of the supply used to purchase bonds (whereas staking if fully liquid — users can stake and unstake instantly). Another one is that you can emit many more bonds (and thus grow the treasury faster), because it turns out most bond purchasers unstake & sell OHM to buy bonds (I had no idea!), essentially arbitraging bonding against staking. This whitepaper covers much more and honestly deserves its own article!

• Olympus12: Building a Strong Ecosystem Around a Web3-Native Reserve Currency: outlines a strong (imho) and extremely interesting action plan for bolstering the economics of OlympusDAO going forward. I do think the success of the plan hinges on whether they will manage to convince projects and people to effectively treat OHM (more like gOHM) as a token to put on the balance sheet / in their long-term portfolio, and not just speculation & arbitrage. With the right mix of incentives and interesting use cases, they might be able to.

Coda

And that's a wrap! Thanks for following this far! If you've liked this, you might like some of my other finance writings. If you want to keep up with my new stuff, subscribe to the RSS feed or follow me on Twitter.

I hope that after reading this, you'll understand a bit better how Olympus behaves economically and how it can be valued.

To conclude with some more personal opinions, I think OlympusDAO was a project whose theory was pretty ill-conceived. You can tell by the confused discourse around it (including the official discourse), and the uselessness of staking as a mechanic. Ironically, this confusion and the high APY hype allowed it to be successful.

Nevertheless, the bonding mechanism is pretty solid and interesting. And am I impressed by the humility of the team and the plan they are making to further improve the project. I would be surprised is this is the last we heard of OlympusDAO.

I've only slightly reformatted the text (mostly links) and updated the line of code statistics.

1/ At EthDenver, people keep asking me on my perspective on optimistic rollups vs zkRollups. Unfortunately, zkRollups have managed to occupy the whole narrative space, so here's a take that is a bit more nuanced!

2/ The first advantages of zkRollups is a lower L1 calldata part of the fee. There a two important caveats:

• The advantage is probably less than you think, see this thread to understand why.
• Optimistic rollups have an advantage in non-calldata L1 cost, and in L2 cost.

3/ A zkRollup needs to run the prover for every transaction, which has massive overheads (~ 10000x). On the other hand, Cannon's MIPS-compiled validator has 10x overhead, and this would disappear if we ran it on MIPS hardware.

4/ zkRollups also need to verify the zk proof on chain, which entails L1 gas costs on top of the calldata. The next version of Optimism (Bedrock) is going to be almost 100% calldata cost.

5/ We're working hard to lower L1 calldata costs for all rollups. We want to help bring "blob-carrying transactions" to Ethereum in the Shangai hardfork.

See Vitalik Buterin's explanation of blobs for more details.

6/ With blobs, calldata costs would likely lower 1Norswap 🏴‍☠️🔴✨ @norswap · Feb 1800x (since rollups would be the only ones seriously competing for this calldata space).

Suddenly, non-calldata costs would become dominant, and opRollups would have the upper hand!

7/ To be fair, this would likely revert in the long term as rollups become the dominant way to transact.

But it's still not clear to me that zkRollups will necessarily be cheaper, and it's downright doubtful they will be significantly cheaper.

8/ As an aside, blobs are like a primitive version of "danksharding" (named after the wonderful @dankrad ), which is itself an easier version of full sharding. Find all about this here.

9/ The second advantage of zkRollups is the absence of a withdrawal period.

This advantage is also a curse. You might know that Optimism recently paid the largest bug bounty in history (2M$) for an infinite money bug.

10/ But if the bug had been exploited, the withdrawal period would have allowed us to rollback the chain to mitigate the damage.

11/ At the moment this is possible because the system is permissioned (as are all rollups), but in the future, some form of governance could easily take this decision within 7 days.

12/ Economic bridges provide enough liquidity for most uses, and would be rekt in case of such a hack, but they do not have enough liquidity for an attacker to drain the chain.

13/ If this happened on a zkRollup instead, the exploiter could just immediately drain the whole rollup.

The zkProof wouldn't save you: it's happy to prove a buggy program/contract ran correctly.

14/ What about some advantages of opRollups?

For one, they're much simpler to understand and audit.

They are only a handful of people in the world capable of auditing the zk prover and verifier logic.

15/ Not only that, but optimistic designs can be incredibly tiny and elegant.

In Bedrock, we're on track to implement the system with less than one thousand lines of code on top of Geth.

16/ The node itself (the part responsible for deriving the L2 chain from L1) is less than 20k lines of code.

We could probably cut that a lot if we weren't using Go and its notoriously verbose error-checking 😁

17/ To be clear, I like zero knowledge proofs. We're not shy about using them, if and when it makes sense.

e.g. I'm thinking about using a zkProof to aggregate ECDSA signatures & reduce our calldata size. (Hit me up if you know how!)

18/ I wish a lot of success to our zk competitors. The improvement they make to the technology is a net positive for all of us.

But to claim that ZK is the only way in the future (and even moreso, the only way now) is intellectually dishonest. The truth is much more nuanced.

19/ tl;dr

• opRollups are cheaper on non-calldata cost
• opRollups will be cheaper with blobs transactions
• long-terms fees are less clear, but there shouldn't be a huge difference
• the withdrawal period is a protection against attacks
• opRollups MUCH easier to audit

OlympusDAO describes itself as a "decentralized reserve currency". In the non-crypto worlds, a reserve currency is a foreign currency held by other governments to back and stabilized their own currency. Interestingly, OHM is itself a currency backed by a reserve ("the treasury") of other assets (mostly stablecoin and OHM-stable LP tokens, but also some ETH). I don't think Olympus works as a reserve currency at all, but I will defer this discussion to another article.

In this article, I want to look at what Olympus actually does, and I want to do so by digging straight into the code.

I'm doing this because OlympusDAO has been the subject of a lot of talk over its short history, but I never really manage to understand how it works. There is a lot of narrative to be found, but very little mechanistic explanations — at least not enough to answer most of my question. What I read about it also didn't seem to make sense from an economic standpoint, but this was impossible to determine without establish ground truth on OlympusDAO's inner workings.

So why were people talking about Olympus you ask? First, look at this chart:

Quite volatile (up 4x, down 6x, up 6x, down 12x), but nothing extraordinary for crypto. No, what is incredible is that this is while OlympusDAO was offering stakers interest rates (aka APY) of thousands of percents (> 1700% as we speak). These interest rates are, importantly, denominated in OHM. Who wouldn't be enticed?

However, all of this comes with a caveat, in a word: inflation.

Over the last week, OlympusDAO (and its forks, most notably Wonderland) have come under fire for the massive drop in prices they have experienced, putting the market cap of OHM very close to the value of its treasury (which logically is the smallest possible price, just how a company should at least be worth at least at much as its assets minus its debts). Wonderland even periodically dipped under its treasury value.

The market capitalization chart (which is in many ways much more relevant than the price charts, because of inflation) for OHM tells of its meteoric rise, and recent fall:

In a subsequent article, I will dive deep into the economics of OlympusDAO and how the current situation is not all that surprising. I will say right now that I do not think Olympus is a scam or a ponzi scheme (which many people accuse it of being). I do think the communication about the project has been somewhat deceitful. At the very least, impressive elements — like the OHM-denominated APY — have been emphasized, while immense caveats have been ommitted from the discourse.

Summary of Findings

This is going to be a long and technical article. For those that are just interested in the take aways, here they are:

1. The total supply of $OHM inflates at the staking reward rate every ~8 hours. This inflation is redistributed among stakers. The inflation distribution event that happens every 8 hours is called a rebase.
2. The staking reward rate is set by the OlympusDAO policy team. For the longest time, this reward rate was 0.35%. It is currently 0.2%, on its way down to a target of 0.16%. At 0.35%, this implies an inflation of 4487%. This is also the minimum staking APY in OHM (if 100% of the OHM is staked, otherwise it will be higher). At 0.16%, this implies a 475% inflation (yup — exponentials are weird).
3. OlympusDAO has a treasury composed of stablecoins and OHM-stablecoin liquidity pool (LP) tokens. The treasury is constituted by selling bonds (see below).
4. A central concept is the "risk-free value" (RFV) of the treasury. This is simply 1$ for stablecoin. For LP tokens, it is the price the token would take if the OHM price fell to 1$. Controversially, this means that part of the RFV of the treasury is made of OHM tokens (in the liquidity pools).
5. Rebases can only go through if there is 1$ of risk-free value in the treasury for each OHM in existence including the newly-minted ones. This sets a soft-floor if 1$ on the OHM price, assuming that the OHM market cap should always be at least as large as the risk-free value of the OHM treasury.
6. The protocol maintains a metric called "the index" which is how much OHM you would own if you staked a single OHM on the day the protocol launched (currenty 74). Recently, Olympus launched the gOHM ("governance OHM") which "wraps" the indexed amount of staked OHM. The main avowed purpose was to enable the trading of staked OHM on other chains.
7. Staking comes with an optional warm-up period (currently disabled) which forces people to wait a configurable amount of time before their OHM tokens are staked.
8. At any time, people can purchase OHM bonds using various stablecoins and OHM-stablecoin LP tokens. The policy team can add, remove or tweak these bond markets. The bonds are usually sold as a small discount to the OHM market price. The bonds grant newly minted OHM tokens to the buyer. These tokens vest over a configurable period, which has always been 5 days.
9. The DAO takes a (configurable) fee over every bond sale, although this is currently set to 0, and it's rather hard to search historical state to see if it was ever set differently.
10. Bond pricing uses a notion of risk-free value (RFV). The risk-free value of stablecoins is equivalent to their market value. For LP tokens however, Olympus assumes a worst-case scenario where OHM is worth 1$, and prices the LP tokens accordingly.
11. Bonds are priced differently depending on the token used to purchase the bonds. The bond price is determined by the formula bondPrice = min(BCV * debtRatio + 1, minimumPrice), where:

• One bond grants one OHM after the vesting period.

• For simplicity, I ignore the decimals on minimumPrice and bondPrice (assume those are infinite precision numbers), and assume that debtRatio is a value between 0 and 1.

• BCV is the bond control variable, set by the policy team for each token

• debtRatio is a ratio between (a) the risk-free value of all tokens used for bond purchases (tallied at the moment of purchase) scaled by the remaining vesting time; and (b) the total OHM supply.

  Note that the numerator and the denominator have different units (risk-free USD and OHM), and consequently, the debt ratio rises faster when the OHM price is high.

• minimumPrice — as the name indicates. However, once a bond purchases occurs above the minimum price, it is then set to 0, allowing subsequent purchases to occur below the bond price.

There is maximum amount of debt (denominated in risk-free value) allowed per token, preventing the emission of too many bonds, and offering some protection against attacks (e.g. if a stablecoin was to lose his peg).

Because the formula is not based on the market price of OHM, the bond price can occasionally exceed the market price!

I tried to explicitly stay away from the economical implications. As said before, these will be the subject of a subsequent article!

In what follows, I will dive into the contracts themselves. Together, we'll learn where all of the above functionality is implemented, and how.

Table of Contents

• Top
• Summary of Findings
• Olympus v1.1 vs Olympus v2
• Contracts
  • v1.1 Contracts
  • v2 Contracts
  • Upgrade Paths
• Basics & Staking
  • Intro to Rebases & sOHM Balances
  • Staking & Unstaking
  • Rebases in Depth
  • Locker
  • sOHM Index
• Bonding
  • Stablecoin Bond Pricing
  • Liquidity Token Bond Pricing (This section explains the Risk-Free Value computation for bonds.)
  • Bonding in Depth
    1. Checking against the maximum debt
    2. Calculate the bond price
    3. Calculate the market-value USD bond price
    4. Calculate the payout and DAO fee
    5. Mint OHM for payout and DAO fee
    6. Pay the DAO and perform book-keeping
  • Example

Olympus v1.1 vs Olympus v2

The present investigation was on conducted on the 1.1 version of the protocol. This is because I started this a long time ago in mid-December, and didn't realize that the v2 of the protocol was already launched, excepted the v2 bonds (which are now live too).

Olympus v1.1 was apparently intended as an intermediary milestone to facilitate the deployment of v2.

The particular code I investigated is the 1.1 codebase as can be found in the Version-1.1 branch on Github.

Annoyingly, it looks like not all the code of that repository was deployed as such. For instance, the OHM contract is not identical to its first deployment (verified in March 2021) nor to its second deployment (verified in December 2021 and matching the v2 code).

If you want to investigate the latest deployed v2 codebase, check out the tree at this commit, which merges in the v2 bonds.

That being said, as far as I was able to determine, the protocol did not change significantly between v1.1 and v2. The major change seems to be that bonds no longer vest linearly but immediately stake OHM which can be redeemed at expiry (this will be repeated below, in the appropriate context).

The other change is the start of on-chain governance via the gOHM token (representing an indexed amount of sOHN, as mentionned in the take-aways). This doesn't affect the behaviour of contracts, however.

If you follow throught this article, you'll have a thorough enough understanding that understanding the v2 contracts should be a breeze.

The v2 codebase seems vastly improved, and most likely assuages some of the complaints I make below!

You might also want to read this deep dive on Olympus v2 bonds for an alternative analysis, focused on v2.

Contracts

Before we dig into the protocol's internals, let's inventorize the contracts, both for v1.1 and v2 deployments. In particular, the OlympusDAO documentation is not yet updated to list the addresses of the v2 contracts.

If you consult the doc, you'll note that some contracts have many versions which are dubbed v1, v2, v3, v4, ... It goes without saying that these version bear no relationship to the protocol versions (v1.1, v2, ...).

As said earlier, the v1.1 source does not always match the deployment (some contracts were tweaked that were not deployed), so it may happen that the source file I link does not match the deployed contract. You can check this by comparing the verified source code in the contract/code tab agains the GitHub source.

v1.1 Contracts

• OlympusERC20.sol (source)
  • Owned by this EOA address
• sOlympusERC20.sol (source)
• Staking.sol (source)
• StakingHelper.sol (source)
• StakingWarmup.sol (source)
• StakingDistributor.sol (source)
• Treasury.sol

In v1.1, there is one bonding contract per token that can be used to purchase bonds. I will only list the DAI and OHM-DAI contracts, to serve as examples:

• List of Bond Contracts
  • e.g. DAI Bond
  • e.g. OHM/DAI LP Bond
• Bond Calculator Contract
  • older deployment used by the newest OHM/DAI LP bond
  • newer deployment used by the newest OHM/FRAX LP bond
  • the code in those two are exactly identical!

There are also some contracts related to governance and operations:

• DAO
  • Proxied to Gnosis Safe (github source)
  • List of signers (4 of 7)
• Policy
  • Also proxied to Gnosis Safe
  • List of signers (3 of 5)

v2 Contracts

• OlympusAuthority.sol (source)
  • This replaces the "Policy" from v1.1 and also owns the ERC-20 contract.
• OlympusERC20.sol (source)
• sOlympusERC20.sol (source)
• Staking.sol (source)
  • v2 does not have separate warmup & helper contracts — instead the functionality is merged in Staking.sol
• StakingDistributor.sol (source)
• Treasury.sol (source)
• BondingDepository.sol
• gOHM (source)
• The DAO contract is the same as before.

A big difference in v2 is that there is a single deployed bonding contract, which handles all tokens (unlike v1.1, which has one deployed contract per token).

v2 has also other contracts, but I haven't reviewed those, so I'll limit myself to establish this mapping will the old contracts. Also note that the v2 codebase splits interface and imports away from the main contract to be deployed, unlike 1.1.

Upgrade Paths

Olympus uses very few proxy (only for the DAO and the v1.1 policy contract). Yet they were able to deploy many new versions of contracts.

These upgrade paths are not explicit in the code (which is a shame), but I do believe some thoughts went into them.

Often, upgrades entails co-existence. For instance, the v1.1 staking contract still "works" if you staked your OHM in it and haven't migrated to v2. However, the old contract does not accept new stakers anymore (this can be achieved by setting some configurable values (e.g. addresses) so that new attempts to stake on the old contract revert).

In the future, it's possible that Olympus might be able to "disable" some old contracts. For instance, it could suspend rebases in the old staking contract (by modifying the address of the distributor), forcing people to migrate if they want to keep earning yield.

That being said, the lack of proxys does not mean that the protocol is "decentralized". In fact, the policy/authority multisig has the ability to change a lot of variables, including contract addresses!

Basics & Staking

Let's begin our dive into the contracts! First, let's get the easy stuff out of the way:

• The OlympusERC20.sol contract is a straightforward ERC-20 token contract implementation. It is owned by an EOA (Externally Owned Account). This is not very secure, but is fixed in Olympus v2, where the owner is remplaced by the Olympus authority contract, which is in turn controlled by a multisig Gnosis safe.

  Minting privileges are given to the "vault" which is the Treasury.sol contract.

• The DAO contract is simply a Gnosis safe, which lets a majority of signers do whatever with the funds held by the DAO contract.

Intro to Rebases & sOHM Balances

The sOlympusERC20.sol contract is also an ERC-20 implementation, this time for the staked OHM token (sOHM, which you receive in exchange for your OHMs after you stake). However, the contract also implements part of the "rebase" logic.

In Olympus parlance, a rebase is the thrice-daily inflation event. It used to be set at 0.35% for a long time, but is now sitting at 0.2%, subject to changes by the Olympus policy team. During each rebase, the newly minted tokens are auto-staked and distributed to the stakers proportionally to their existing stake.

Because of the frequent rebases, sOHM balances are constantly in flux. They change automatically, without users needed to submit transactions to claim.

The way this is implemented is rather ingenious. The contract does not maintain sOHM balances: this would be too expensive, as every rebase would need to touch every single balance. Instead it maintains a balance of "gons" (I don't know where the term comes from). Whenever a rebase occur, the gon balance does not change — only the total pot of OHM owned by the staking contract is increased. A user's sOHM balance is the fraction of the OHM pot equal to its gon balance divided by the total gon supply. This is also the amount of OHM the user would receive if unstaking his whole sOHM balance (one sOHM always corresponds 1-1 to one OHM in the staking contract).

The sOHM contract itself defines only part of that logic. It has a rebase(uint256 profit_, uint epoch_) function, callable only by the staking contract. The profit_ here is the amount of sOHM that is to be distributed in the rebase. The logic in that function ensures that the sum of the balances of all stakers is increased by this amount.

Now we must tackle a peculiarity in the contract code I cannot quite explain. Instead of letting the staking contract mint the sOHM whenever it receives OHM, the sOHM contract allocates 5*10^15 (or 5 million billion) sOHM to the staking contract. Whenever the staking contract receives OHM, it sends a corresponding amount of sOHM from his own balance to the staker. I assume there must be a reason for this, but it is not obvious. The contract also calls sOHM "fragments", though I'm not quite sure why. (It could be to better differentiate them from gons, and avoid using ambiguous terms like amount, but the contract does that sometimes anyway.)

EDIT: iND1G0 points out the terminology is inherited from Ampleforth, an algorithm stablecoin. This explanation from the home page is pretty eloquent:

When Price > $1, wallet balances Increase proportionally When Price < $1, wallet balances Decrease proportionally

This sOHM allocation to the staking contract also means that the sOHM contract must distinguish between the total supply and the circulating supply (which excludes the staking contract's balance), and that the rebase function must inflate the total supply by more than the profit_ parameter, in order for the circulating supply to be inflated by profit_ and be effectively accrued to the stakers. The staking contract balance inflation is irrelevant (since it's only ever exchange for OHM that was staked, or to reward lockers — see later).

An interesting thing to note is that the staking contract's sOHM balance is not backed by underlying OHM. This is fine because (a) when staking, users exchange OHM for sOHM 1-1 with the staking contract and (b) when rebasing, the distributor contract mints OHM for the staking contract 1-1 with the reward (see later).

Staking & Unstaking

The abstract idea of staking is pretty easy: you send X OHM to the staking contract, and the staking contract sends you X sOHM in return. Unstaking is the same, but in reverse.

In pratice, it's a bit more involved because the contracts introduce a notion of warmup, which is not currently used.

To stake, you call the stake(uint _amount, address _recipient) function, which receives your OHM, and sends sOHM to the StakingWarmup.sol contract on your behalf. Then, after the warmup period (warmupPeriod, currently 0), you can call claim (address _recipient) to transfer the sOHM locked in the warmup contract to your own balance.

Because the warmup period is currently 0, you could do both calls in a single transaction. For this purpose, Olympus has deployed the StakingHelper.sol contract whose stake(uint _amount) function does exactly this. Additionally, the recipient is implicitly the sender.

You can cancel the warmup period and reclaim your OHM with the forfeit() function, and you can prevent other people from staking OHM for you using toggleDepositLock() (my best guess is that this is just for extra protection, so that a contract that you've authorized to handle your OHM can't unstake your sOHM).

Rebases in Depth

Rebases are initiated by calling the rebase() function of the staking contract. Anybody can call the function, as long as a rebase is due. The function is also automatically called when someone stakes some OHM!

rebase() does four things:

1. Check if a rebase is due via the current epoch (see below), otherwise return.
2. Call sOHM.rebase(uint256 profit_, uint epoch_)
3. Call distributor.distribute() (if distributor != 0)
4. Update the current epoch.

The current epoch, held in the epoch variable tracks the length of the epoch, its number, its deadline endBlock (indicating when rebase() can be called), and distribute (the amount of sOHM to be distributed during the rebase).

In the first step, we simply check epoch.endBlock <= block.number. If that's alright, we call sOHM.rebase(epoch.distribute, epoch.number), which works as described above.

Then we (possibly) call distribute() on the distributor contract. Here is how the documentation misleadingly describes it:

The distributor contract receives minted OHM from the treasury in order to drip-feed rewards to stakers. The reward rate target as of time of writing is set to 3500, which translates to 0.35% of total supply, since the reward rate is defined in tens of thousands. Note that the reward rate determines the rebase rate and that the rebase rate determines the APY. Below are listed distributor contracts by version, where the latest version represents the currently active contract.

This makes it sound like the distributor is the one that gives out rebasing reward. As we've seen before, this would be too expensive, and it's actually done by the sOHM contract.

In reality, the role of the distributor is to send OHM to the staking contract in a way that is commensurate with the rebase amount (profit_ from above). However this mechanism is fully generic and does not encode a direct dependency on the staking contract. Let's see how it works briefly.

Skipping over the fine details, what distribute() does is distribute OHM rewards (minted from the Treasury contract via its mintRewards(address _recipient, uint _amount) function) to "recipients" which are added/removed through the addRecipient and removeRecipient functions. These functions are only callable by the policy multisig (which is the current value of _policy in the distributor contract). addRecipient also takes an individualized reward rate for every recipient.

If you query the latest version of the distributor contract on Etherscan, you'll see that the (latest version of the) staking contract is currently the only recipient.

An important detail about mintRewards is that it will refuse to mint OHM if the risk-free USD value of the reserves is inferior to the OHM supply (denominated in OHM), effectively setting a lower bound price of 1$ on OHM, fully backed by the treasury. Fun fact: mintRewards reverts in that case, which means any attempt to trigger further rebases or to stake more OHM will revert too. (This could be sidestepped by removing the staking contract as distribution recipient, but it would be useless to stake in the absence of rebases anyhow.)

Is the staking profit_ connected in any way with the treasury's reward? Actually yes. This is done during step 4 of the rebse, when updating the current epoch.

The distribute field of the epoch is set to the OHM balance of the staking contract minus the circulating supply of sOHM (remember the circulating excludes the staking contract's own sOHM balance). This ensures that we can only distribute staking rewards if there is more OHM in the staking contract than owned by users, guaranteeing that every sOHM can be redeemed for an OHM.

As a consequence of calling distribute() earlier, this OHM balance of the staking contract increased, distribute will be set to the the OHM reward from the distributor, and will be distributed as sOHM during the next epoch.

The distributor contract also has logic handling what it calls "adjustments" which are a way to smooth a reward rate transition from the current rate to a target rate, with the reward rate being updated incrementally during each epoch (when distribute() is called) until the target rate is reached.

Locker

A little mystery lives in the v2 staking contract (the one from Olympus v1.1 that we are considering here): the notion of "locker".

The contract has a function giveLockBonus(uint _amount) which transfers a sOHM "bonus" to a "locked staking contract" (the locker contract variable). This function is only callable by the locker, which can also ostensibly return the bonus via returnLockBonus(uint _amount).

The locker does not appear in either the v1 or v3 contract, and is now set to the zero address in the v2 contract. My best guess is that it is a crutch used to upgrade the Olympus deployment, though I'm not sure how and why.

sOHM Index

If you go to the Olympus DAO App, you can see it features the "current index" (74 at the time of writing), with the description:

The current index tracks the amount of sOHM accumulated since the beginning of staking. Basically, how much sOHM one would have if they staked and held a single OHM from day 1.

This notion also appears in the sOHM contract. The index is set once (via setIndex(uint _INDEX)), to an initial sOHM amount, which is converted to a gon balance and stored internaly as INDEX. (Remember, gon balances do not change when rebasing and are used to track fractional ownership of all the sOHM.)

Calling index() returns the amount of sOHM now controlled by this initial sOHM amount, if it was staked at contract inception.

During the first sOHM contract deployment, the initial INDEX was the gon value for 1 sOHM. Each time the sOHM contract is upgraded, the value returned by index() needs to carried over as the new INDEX value in the new contract.

Bonding

The goal of bonding is to sell OHM at a small discount (at least, usually) in the form of bonds that vests linearly over a small period of time (currently 5 days).

"Linear vesting" means that after one day you can already withdraw 1/5 of the OHM, etc (at the time resolution of blocks ~= 13s).

The bond purchaser makes a small profit, but takes on price risk. More on the purpose of bonding in the economic analysis part.

In "bonds v2", there is no longer linear vesting. Instead the purchased OHM is staked and can be claimed at the end of the period. This increases risk for bond holder who can't dump at least part of their OHM before expiry, but solves the problem that the discount rate is actually misleading because the OHM supply inflates during the vesting period (by about 3% at the current rebase reward rate).

Bonds are sold for various assets (called principle or sometimes reserve in the contracts), which are either stablecoin or OHM-stablecoin LP tokens. There is one contract for each asset, instantiated from the BondDepository.sol file. For instance:

• DAI Bond Contract
• OHM/DAI LP Bond Contract

v2 only has a single contract to handle all bonds.

We'll look at how bond prices are determined, starting with stablecoins, then moving on the more complex pricing of LP tokens, then looking at what the bonding process actually does (hint: more inflation!).

For a given bonding contract, the bond price is computed by the view bondPrice() method. There is also the _bondPrice() method, which is the one actually called during bond purchases. The difference is that the _bondPrice() can modify the minimum bond price, as we'll see.

Stablecoin Bond Pricing

First of all, bonds are fractional, i.e. you get a claim on OHM proportional to the value of the tokens you use to purchase bonds, without unit limitation.

This means that "one bond" maps to 1 OHM. However, it can also appear that "one bond" maps to 100 OHM because bonds are represented with 2 extra digits of precision: the payoutFor(uint _value) function of the depository contract divides the value by the bond price, obtaining a number with 36 digits of precision, but dividing only by 10^16, hence 100 times more than the expected 18 digits precision. The reason for the extra precision is that the bond price is expressed in risk-free USD with 2 digits precision (though it's not clear why that particular choice was made).

I must say that dealing with significant digits was by FAR the most tricky and painful part of reading the contracts. It almost completly threw me for a loop multiple times, and the devs did an horrendous job at documenting the assumptions. In fact, I even found what I must assume is a mistake in one of the comments.

The formula to determine the bond price (with two digits precision, so the obtained number will be 100x the price) is bondPrice = min(BCV * debtRatio + 100, terms.minimumPrice), where:

• BCV is the "bond control variable" (terms.controlVariable in the code). This value is tweaked for every principle by the Olympus DAO policy team, and can change over time.

• debtRatio is the ratio (in percent) of the total bond debt (the OHM to be paid out for bonds still have to vest) over the total OHM supply. It's a bit weird however, because it's actually a ratio between the "risk-free" value of the debt in USD (we'll explain this in the next section) and the supply in OHM! A consequence of this is that the debt ratio increases faster when the OHM price is high.

  The debt ratio can be obtained by calling debtRatio() which returns the ratio with 9 significant digits of precision (so 1B = 100%). This debt ratio is different for each bond contract (i.e. for each token).

• terms.minimumPrice is a minimum price for the bonds. This is useful as otherwise the first bond sales would be done at a very steep discount, as debtRatio is effectively 0. The minimum price is only intended for this ramp-up: the first time the price exceeds the minimum price in _bondPrice, terms.minimumPrice is set to 0.

As the debt ratio increases, so does the bond price, and vice-versa. This automatically throttles the rate of bond emission, and incentivizes bond purchase when few bonds are being sold.

As a side-note, the Olympus DAO glossary defines BCV as follows:

Bond Control Variable, is the scaling factor at which bond prices change. A higher BCV means a lower discount for bonders and higher inflation by the protocol. A lower BCV means a higher discount for bonders and lower inflation by the protocol.

I find this statement frankly puzzling, since you would expect that when the discount is higher, more bonds are sold, and so inflation is higher. I think the explanation here is that "inflation" doesn't refer to the increase in supply, but to the loss of value: when more bonds are sold, each bond sale tends to increase the backing per OHM, which means that OHM will decrease in value more slowly. More on this in the economic analysis part.

Liquidity Token Bond Pricing

The formula for determining the bond price when purchasing using liquidity tokens (with two significant digits) is the same as before: bondPrice = min(BCV * debtRatio + 100, terms.minimumPrice) (see previous sections for important details). This expresses an amount of USD, not an amount of liquidity tokens.

But not so fast! When purchasing bonds using LP tokens, Olympus first converts bonds to their risk-free value (RFV) and then only uses this RFV to determine the number of bonds purchased.

The RFV assumes a "worst-case scenario" where 1 OHM is worth 1$. This is a worst-case scenario because the mintRewards function of the treasury contract ensures a minimum backing per OHM of 1$.

(This computation is slightly sketchy because at 1$ it means OHM is partly backed LP tokens whose value is made up in half of OHM valued at 1$. Close enough.)

The RFV is computed by the valueOf(address _token, uint _amount ) method of the treasury contract, both for stablecoins and LP token. For stablecoins the RFV value is trivially computed as the amount of stables. For LP tokens, the function defers the computation to the valuation(address _pair, uint amount_) function of an instance of the StandardBondingCalculator.sol contract (e.g. the instance used by the OHM-DAI contract).

The formula to compute the RFV of the whole liquidity pool is 2 * sqrt(k), where k = ohmInPool * stableInPool (this is the classical x * y = k equation of Uniswap v2 pools).

This makes sense: at 1$ = 1 OHM, ohmInPool == stableInPool == sqrt(k), hence ohmInPool + stableInPool == 2 * sqrt(k).

To compute the RFV of any amount of LP tokens, you simply multiply the liquidity pool RFV by the fraction of the pool controlled by the tokens.

The bonding calculator also has a markdown function which indicates how discounted the RFV is compared to the actual price. The actual price for the whole pool is the amounts of stable times 2 (since by definition the values of one side of the pool equals the value of the other side). Then to get the markdown, you divide this by the RFV value of the whole pool.

Bonding in Depth

To purchase a bond, you call the deposit(uint _amount, uint _maxPrice, address _depositor) method of the BondDepository.sol instance of your choice (e.g. [the DAI bond contract][dai-bound]).

• _amount is the amount of tokens (stable or LP) you're sending for your purchase
• maxPrice is the maximum USD price (using the decimal precision of your stablecoin (*), usually 18) you're willing to pay per bond. This is intended to protect against slippage.
• _depositor is the address of the depositor (this is useful in case a contract is calling this method on your behalf).

(*) If purchasing a bond with LP tokens, this will be the precision of stablecoin in the pair.

Here are the various steps taken by the function:

1. Verify that the max "debt" is not exceeded, as set by terms.maxDebt.
2. Calculate nativePrice — the bond price in "risk-free USD", with two digits of precision.
3. Calculate priceInUSD — the bond price in "market-price USD", using the stablecoin's decimals.
4. Calculate the payout (amount of OHM the bonds can be redeemed for) and the DAO fee.
5. Call the deposit(uint _amount, address _token, uint _profit) function of the treasury contract to mint the OHM for the payout and for the DAO fee.
6. Pay the DAO fee, and perform book-keeping: update bond info, total debt and perform adjustments.

Let's go over some these things in more details.

1. Checking against the maximum debt

The variable terms.maxDebt indicates the maximum allowable debt for the contract. Intuitively, the debt is the amount of granted OHM yet to be vested. However, terms.maxDebt is denominated in risk-free USD ("RFV USD") instead.

First the total debt held in the variable totalDebt is decayed by calling debtDecay() removing the value of the tokens that have vested since the last time the debt was decayed.

Decaying it is done on a proportional basis: for instance if 50% of the vesting period (so 2.5 days) have passed since the last decay, the totalDebt is split in half.

totalDebt is also denominated in RFV USD. As we've already mentionned, this makes the debtRatio a ratio between a value in RFV USD and OHM, which is peculiar, but has the effect of increasing the debt ratio (and hence the bond price) faster when the OHM price is high.

2. Calculate the bond price

As explained earlier, the bond price is computed by using the formula rfvBondPrice = BCV * debtRatio + 100, where debtRatio is a whole integer representing a percentage (so for 5%, we'd multiply BCV by 5).

The bond price, held in the variable nativePrice inside the function, is denominated in USD, but the RFV of the tokens will be used to "pay" for this price. Hence I will say it is denominated in "risk-free USD" or "RFV USD".

I will refer to this value as rfvBondPrice to be clearer.

As we have said earlier, rfvBondPrice is a value with two significant digit (instead of the usual 18).

3. Calculate the market-value USD bond price

Since rfvBondPrice is a risk-free amount, the function also computes the market price of a bond. This will later (see section on boo-keeping) be recorded in the bond information.

Since bond sales affect bond prices, this value — as well as the RFV bond price — will be recomputed later and included in an event called BondPriceChanged.

For LP bonds, the value is computed as rfvBondPrice * markdown / 100 (cf. section on LP token pricing for info on the markdown). Here, unlike in many other places, I've included the / 100 which adjusts the digits. If you're thinking of amounts as real numbers, feel free to ignore it.

4. Calculate the payout and DAO fee

First, the deposit function (of the bonding depository contract) computes the payout, the amount of OHM to grant. This is obtained by computing the RFV value of the amount deposited (using the valueOf of the treasury contract) and dividing this by the bond price.

The DAO receives an OHM-denominated payout equal to a percentage of the payout, set by terms.fee.

5. Mint OHM for payout and DAO fee

Next, the the deposit(uint _amount, address _token, uint _profit) function of the treasury contract is called. This function's purpose is to mint OHM for the payout and for the DAO fee.

The function takes a _profit parameter, which is completely different from the rebase "profit" that we talked about before. In this case, the profit is computed as profit = rfvValue - payout - fee. The only purpose of this _profit is that the treasury deposit function will subtract it from the RFV values of the tokens to obtain a _send value: _send = rfValue - profit = payout + fee. This determines the amount of OHM minted to the bond depository contract, to be paid to the DAO and to be granted by the emitted bonds. If you think it would have been immensely simpler to sent something like _mint = payout + fee... you would be right. It makes very little sense, given for instance that rfvValue is denominated in USD while the payout and the fee are denominated in OHM.

6. Pay the DAO and perform book-keeping

The book-keeping part is important: this is where we actually record that the user is entitled to redeem the payout!

We also increase the total debt by the RFV value of the tokens supplied. This is necessary to check the maximum debt and compute the debt ratio.

Finally, just like the distributor contract, bond depository contracts have some "adjustment" logic, used to smooth a transition in the value of the BCV. Unlike the distributor, which adjusts during each rebase epoch, a depository contract adjusts during every bond sale, which means changes can be relatively fast if many bond sales occur in rapid succession.

Example

To make things hopefully a little bit clearer, let's work through a bonding example.

Let's assume that

• OHM is worth 70$ (as it was when I wrote this example)
• the OHM-DAI liquidity pool contains 100 OHM (and therefore 7000 DAI, which we'll write 7000$ for convenience)
• the ownership of the pool is split accross 100 LP tokens, each of which is worth 0.01 * 2 * 7000 = 140 $
• the current debt ratio for the OHM-DAI bond depository contract is 5%
• the bond control variable (BCV) for the OHM-DAI contract is 207 (as it is at the time for writing)
• the (thrice-daily) rebase rate is 0.24% (as it was when I wrote this)
• the DAO fee is 1%. This is currently 0% in both v1 and v2 bonds, and it's particularly difficult to find historical values (you'd have to run your own node and re-execute transactions, since value changes are not even logged).
• the RFV backing per OHM is about 26$ (as it was ...)
• the market-value backing per OHM is about 60$ (as it was ...)

Under these condtions, the risk-free value (RFV) of such a DAI-OHM LP token is 0.01 * 2 * sqrt(100 * 7000) ~= 16.73 $.

If a user uses a single LP token to purchase bonds, he would get back bonds that would grant (16.73 * 100) / (100 + 5 * 207) == 2.32 OHM. This represents a "premium" of 0.73 OHM compared to the market price, which is equivalent of an effective OHM price of 140 / 2.32 = 60.34 $, or an effective discount rate of 14% compared to the market price.

A more realistic discount assessment would also consider that during the vesting period of 5 days, the OHM supply will inflate by around 3.7% (1.0024^(3*5) ~= 1.037), so the effective discount is closer to 10%, assuming the buyer redeems at the end of the vesting period (of course, Ethereum transaction prices makes the amounts we're discussing completely unreleastic, but whatever).

We'll note that v2 bonds solve this issue by staking the granted amount immediately, and so there is no loss due to inflation.

So in this example, 2.343 OHM are emitted (1.01 * 2.32 to account for the DAO fee), backed by 140$ of market value and 16.73$ of risk-free value (7.14$ per OHM).

In this case, the RFV backing per minted OHM (7.14$) is significantly less than the current RFV backing per OHM (which is 26$). This means that each OHM emitted in bonding decreases the backing per OHM.

I'll discuss this more in the economic analysis part, but this is an inherent property of LP bond sales. Stablecoin bond sales, on the other hand, tend to increase the RFV backing per OHM.

Coda

That's it! This ended up much longer than I expected, and also took longer to write, but I learned a lot doing the research. I hope you enjoyed the deep dive, and learned something!

I contend that the essence of blockchain is that they are decentralized trust engines.

Decentralized trust has a lot of benefits, but the one I'm personally excited about is that it enables permissionless innovation.

Below I explain what the hell I mean by decentralized trust and permissionless innovation.

Who do you trust?

Whenever you perform some action online, you're always implicitly trusting some entity.

For instance, if you run a computation on Amazon Web Service (AWS), or even in Google Sheets, you trust Amazon and Google not to alter the result of the computation.

If you host files on Dropbox, you trust Dropbox not to alter their content, and to not arbitrarily destroy your backup.

You trust that Google won't return you completely fabricated search result to get you to take some specific decision (e.g. a purchase) that is in their interest. (They certainly influence search results, but they don't (yet?) fabricate them.)

You trust that your bank won't take your money. You trust that your insurer will actually compensate you in case of accident.

You might also trust all of these companies with the privacy of your data.

Etc, etc...

You might object that these companies won't do these shady things. They stand to lose a lot, including reputation, customers, future revenues, etc! As for banks and insurances, they are heavily regulated.

That's true — although I will say these companies have gotten away with a surprising number of things. But more importantly it means you can only deal with entities that either (a) have something to lose or (b) comply with draconic and time-consuming regulations — and mostly that means big entrenched companies. We'll explore this when we talk about permissionless innovation.

Also consider that companies might be forced to do something, probably by some government.

"Decentralized" trust?

The fundamental proposition of blockchains is the following: What if you did not have to trust a single entity, a single company?

In blockchains, there is a network of nodes (aka verifiers, validators, stakers, miners, ...) that verify the operations of the blockchains. As long as a majority of these nodes are honest (e.g. 50% of them, this changes between blockchains), you can trust that anything that happens on the blockchain follows the rules of the blockchain. And dishonesty has dire consequences for validators — because of sunk costs, or because of explicit penalties.

This changes your trust assumption from trusting a single entity to trusting that a majority of validators are honest.

The more validators there are, the less collusion is likely. Said otherwise, the more decentralized the system is, the less trust you need to put in the system.

It is also of paramount importance that anyone be able to become a validator of the network. Otherwise, the network is really controlled by the gatekeeper of the validation rights. This is less easy than it sounds — you have to make validation costly enough, otherwise an attacker could just spin a huge number of nodes and take over the network — a sybil attack. Preventing sybil attacks is the main technical breakthrough of blockchain technology. I explain the solutions (proof-of-work and proof-of-stake) in my article: Freaking blockchains: How do they work?

Applications & Trade-Offs

Let's go back to our examples. Am I saying that blockchains will supersede AWS, Google Sheet, Google Search, Dropbox, banks and insurances?

Not necessarily.

In reality, there is a trade-off. Nothing is truly trustless or riskless. Running most web apps on AWS is really fine, because the risk that Amazon is going to manipulate your results is close to zero, and the downside if they do is very low. Even if you're running with a brand-new competitor, you're not risking all that much.

But for some applications, trust and security are a really big deal. In particular, where money is concerned. It's not by accident that finance is stringently regulated. And similarly, it's not an accident that most popular applications of blockchains right now deal with money. It's doubly important when you're dealing with anonymous blockchain developers with no pre-existing reputation (more on this in the section on permissionless innovation).

Permissionless Innovation

Finally, we come to what is to me the most exciting consequence of decentralized trust: permissionless innovation.

On computation-centric blockchains, like Ethereum, the network certifies computation, and the code of the computation is a public smart contract stored on the blockchain, you can trust the contract to do what its code says, nothing more and nothing less.

This means that anybody can deploy a new smart contract, and other people can use it as long as they trust the code. The contract author does not need to have resources, a reputation or even to comply with regulations (1) to deploy his contract, or for you to trust that the contract will be executed faithfully.

(1) He has to, legally speaking, but blockchains being novel, it's unclear which rules apply in the first place. Such FUD would normally stifle innovation — but not on the blockchain where the barrier to entry is low, and many developers are anonymous.

This is super exciting! It has already led to numerous innovations in the financial realm, such as automated market makers (AMM), as well as many new forms of clever incentivization mechanisms such as liquidity mining, liquidity purchases via bonding, and more.

Besides brand new constructions, it also makes opportunities available to everyone that were previously available only to a few. Option protocols such as Lyra make it possible for everyone to profit from market-making the option market: a process where the market maker sells an option, which is hedged by the underlying, in order to pocket the option premium. (If this is Chinese to you, see my articles on options and on gamma squeezes.) Previously, this lucrative and relatively safe opportunity reserved to big investment banks. On-chain, everyone can add their money to a pool and participate!

And this is just an example amongst many. Another one would be lending to overcollateralized borrowers.

Hopefully, more areas can benefit from this innovative drive besides finance. One area that looks promising at the moment is gaming. Increasingly, game development is financed by the sales of in-game assets (skins, character customizations, convenience features, ...). One could be hesitant to buy into a relatively unknown game. Using the blockchain to encode these assets incurs many benefits: it can be made certain that they won't disappear at the whim of the developer, that they are tradeable without the developer investing any resources to make them so. Even better, another developer could decide to reuse the assets, and give them a function within his own game.

I think the use of blockchain in gaming is at the same stage where peer-to-peer (P2P) technology used to be some 20 years back. P2P had a terrible reputation as a thing used only to download copyrighted material. Yet only a few years later it became a common way to distribute big games and their updates, proving invaluable at handling the load on release day.

Or maybe crypto gaming doesn't work out. Who knows? There are many other areas in which people are building on the blockchain at the moment. Most projects will fail, but those who succeed might create immense value (I'm talking about usefulness, not money), and these wouldn't have gotten built without the blockchain.

Conclusion

I'll simply recap the thesis: blockchain are decentralized trust engines. Instead of trusting a single service provider, you trust a majority of the validators to be honest — and they are incentivized to be.

On decentralized computation blockchains like Ethereum, this enable anybody to deploy a smart contract, and anybody else to trust that the code will be executed faithfully (it still requires reading and understanding the code!).

This enables permissionless innovation: anybody can innovate, not only big companies with a reputation, or with government sign-off — even when money is involved.

It also enables anybody to port existing constructions to the blockchain, for all to take advantage of (e.g. option market-making).

Hopefully, these innovations will spread outside finance in the future.

PS

The subject seems to be momentous, and here are two excellent recent pieces that harp on the value of decentralization:

• Avoiding Internet Centralization talks about the importance of decentralizing the internet's infrastructure, but many of its arguments are valid arguments against centralization in general. (It also makes clear that blockchains aren't really the solution for low-level internet infrastructure.)
• Is Web3... anything? is similar to this post and explains blockchains as "a protocol/architecture for near-trustless commitments".

Ethereum's limited resources, specifically bandwidth, computation, and storage, constrain the number of transactions which can be processed on the network, leading to extremely high fees. Scaling Ethereum means increasing the number of useful transactions the Ethereum network can process, by increasing the supply of these limited resources.

But how do rollups increase these resources? To understand this, we first need to give some details about layer-1 (L1) Ethereum.

State in L1 Ethereum

The size of the L1 state as per summer 2021 was around 35GB. However, during execution, the state needs to be stored in a Merkle Patricia Tree (MPT), which takes the effective stored size to 100GB. This size is expected to grow by 50GB per year, assuming the Ethereum gas limit stays constant. These amounts does not even include historical state, some of which must be kept to be able to process chain reorganizations. A node must also keep at least some recent block header data.

Currently, core developers are not increasing the gas limit because we expect higher throughput to cause faster state growth.

Still these numbers are manageable. 4TB SSD drives can be purchased for 400$ or less. So why don't we just increase the gas limit?

Why not increase the gas limit?

There are two reasons. The first is a commitment to keep Ethereum as decentralized as possible, which includes making it possible for as many people as possible to validate the network. We could increase the gas limit and require every validator to spend a few thousand dollars to participate and this wouldn't really decrease the security of the network. However, the same kind of reasoning could be repeatedly applied to take us to a situation where you'd need to rent in a data center to validate the network. This is extremely undesirable, because it would let a small number of majority actors (e.g. staking pools) collude with very few people noticing.

Let me give just one possible scenario. A majority cabal of staking pools could claim to run a jointly-developed custom client, which so happened to have a "subtle bug" that associates of the pools are able to exploit for profit. The few remaining honest actors need to detect and then identify the problem — are the pools or the other validators correct? The pools could make this investigation difficult, and by the time the "bug" surfaces, the chain has moved on so far that a fork becomes unthinkable. The pools can maintain plausible deniability by claiming this was an innocent bug.

Like a lot of things in the blockchain space, this is a social problem as much as a technical one. One reason more eyes on the chain is better is because it can cause more outcry in case of fraud, and give legitimacy to the correct fork.

The second reason we don't want to increase the gas limit is light clients. Light clients are clients that can validate the network but are not required to store the state. Instead they can request the state from the network and validate it against state roots stored in recent block headers. Light clients allow reducing the reliance on centralized state providers like Infura.

Aside: how light clients work

A light client needs to start with a trusted block header (either coming from an initial sync or trusted source). Let's assume that this hash is a semi-recent block hash, updated each time you use your light-client-enabled wallet. Then, the next time you use your wallet, you need to get all the block headers between that trusted header and the current head of the chain. There are solutions to validate these headers in both proof-of-work and proof-of-stake, but let's focus on the latter, as it is Ethereum's future.

To verify a block header, you'll need to determine that the block was indeed signed by known Ethereum validators (stakers). The validator data is small enough that it could be kept locally, or you can request it from the network and validate it against the trusted block header.

Once you're caught up with the chain (which should be fast unless you haven't opened your wallet in months/years), you can speculatively execute transactions locally, or even execute whole new blocks yourself. During these executions, you'll need to request the state from the network, which you can again validate against the state Merkle root in the most recent block header.

This state can even be obtained from a centralized provider. The difference is that you do not need to trust him anymore: now you can verify the state against block headers, and you run the computations yourself.

Light clients are expected to run on user's machines (laptops, cell phones) and only sporadically (e.g. when using a wallet). Clearly this puts a limit on storage, computation and bandwidth. The storage is solved by getting the state from the network, but this further constrains bandwidth.

Increasing the gas limit too much would overwhelm light-client's ability to catch up and keep up with the chain, in terms of bandwidth and computation.

Finally, light clients help keep Ethereum decentralized by creating more validators. Light clients associated with wallets are a formidable deterrent because it means these wallets won't transact on fraudulent chains, even if they are supported by a majority of miners/stakers. Vitalik Buterin makes this point here.

Enter Rollups

I first want to acknowledge the fact that how rollups scale Ethereum — while preserving its security guarantees — is not as straightforward as it is often made out to be.

The scaling property of rollups falls out from two facts:

1. A rollup needs orders of magnitude less validators than L1 to maintain its security. As long as a single honest validator does its job, the network will remain secure.
2. State growth can be spread between multiple independent rollups.

Let's look at (1) first. In an optimistic rollup, the rollup will be secure if there is always a validator that can submit a fraud proof for every detected sequencer fraud. Therefore, it is okay to increase the requirements needed to run these validators, as long as motivated entities and individuals are able to run them. Note also that many entities have a vested interest in running these validators, because they derive value from the rollup: data and insight providers like Infura, The Graph, Dune Analytics; as well as projects building on top of the rollup. Unlike in my "evil staking pools" scenario, a majority of bad actors is no longer able to get away with fraud!

In a zk rollup, you do not need validators at all for security (you might need them for data availability however, depending on the architecture of the rollup), but you need to trust the code of the zk verifier smart contract. While no external validators are needed, the requirements on the prover (the zk pendant of the sequencer) are extreme, as building the zk proofs is very costly.

Regarding (2), this lets different validators verify different parts of the state, hence not imposing the burden of the extra state of every rollup on every validator. Because of (1), we know that it's okay for each rollup to have many less validators than L1. This is also the insight behind sharding — though in this case the reduced validator requirement does not apply and is solved with random committee selection instead.

In Summary

We can't just raise the gas limit to scale Ethereum, because that would raise hardware requirements for validators, and the chain needs to be validated as broadly as possible to avoid a collusion of majority actors. It would also preclude the introduction of light clients to break our reliance on centralized data providers.

Rollups help scale Ethereum because they require order of magnitude less validators than L1 to stay secure (via the use of fraud proofs or zero-knowledge proofs), hence the requirements for validators can be increased. Additionally, the state growth between multiple rollups that can be validated separately.

In June, I took a leave from my Job at Oracle to take part in the Ethereum Core Developer Apprenticeship for four months. I learned a ton — here's a recap of what I did there.

By the end of the program, I was sold, and I joined Optimism to work on scaling the Ethereum blockchain. My first task there will be to help specify and prototype the new version of the Optimistic Ethereum rollup. It's been a blast so far!

Expect more content soon, especially blockchain-related. If you hate blockchains — I'm so sorry.

Cobra Kai

• TV
• Season 3
• previously: Season 1 & 2

In my review of the first season, I said the show was constantly toeing the line of overuse on its narrative ropes. I really enjoyed the third season too, but it's clearly the season where the line gets crossed.

Rest of the review behind the spoiler tag!

Lupin

• TV show
• Part 1 (6 episodes)

Lupin is the first French TV show I've watched in forever. And, oh shock, it's actually pretty good.

The story centers around Assane Diop (played by the excellent Omar Sy), a professional thief. When he was young, his father was framed for a theft he didn't commit — something Assane only learns at the start of the season. We then follow his struggle against his mighty enemies, in order to get justice for his father.

Assane is inspired and emulates the character of Arsène Lupin — the gentleman burglar. This leads to a series of clever plans, tricks and deceptions that make the show quite entertaining.

Besides the great story, the show also benefits from the insane charisma of Omar Sy, who really sells the character.

Truly, a pleasure to watch.

Pragmatic Capitalism

• Book, by Cullen Roche

This was a book I enqueued on my read list when I started to learn about finance. I have mixed feelings about it.

The book is mostly concerned with discussing the monetary system, with some investment portfolio advice thrown in the middle. This is not capitalism, it's not finance, it's macro-economics. Fine, but what not what I expected from the book.

The description of the monetary system itself is well-meaning, but falls short for me. I'm not quite sure who the intended audience is. Roche keeps emphasizing some points — common misconceptions that seem to be his pet peeves — and to his credit that is very clear, though a little preachy. More advanced topics are unfortunately not that well-explained and seem to assume some familiarity with the system already.

You can tell Roche means well, but its content would have worked better as a series of blog posts. It would be hard to me to recommend it to anyone. It's too long to be an introduction, doesn't go far enough to be textbook, and doesn't explain the advanced concepts well-enough anyway. The portfolio advice is also well-meaning but all the same, I don't particularly recommend it.

It's not a bad book, but I'm not sure what it's trying to achieve. Meh.

FFF-Class Trashhero

• Webtoon
• up to chapter 86

Another entry in the leveling genre. In this one, we join the hero (that has been summoned to another world to defeat the demon king, nothing unusual) after he defats the demon king. However, it turns out that his performance is being graded, and he fails, because he actually murdered his party before confronting the demon king. So now he has to start all over again.

Why did he do such a thing? From his point of view, he was being abducted against his will, and the people in this fantasy land actually mistreated him pretty badly, beating him to toughen him up, having him run nonsensical errands, etc.

The story is fairly comedic in nature, there's some slapstick humor à-la-Konosuba!, albeit much less charming. But it sits uneasy between its dark premise and the comedic element. The hero's character is terrible, but the story is earnest in telling us that he has good reasons for it — he's not just being silly. At the same, the story also depends on its dumb factor. The hero starts being evil from the get-go in his second attempt, even as that's obviously not the correct way to succeed.

At some point, it also veers into a weird over-the-top power trip, and I'm not sure how the author will extirpate himself from this mess.

I enjoyed this, but I would have enjoyed it much more if the comedic element was dropped and the premise was left to shine. What could a bitter hero have done to try to pass while being subjected to the rules (or break free in other ways, or get revenge)? And there are already plenty of elements that could have made that good (for instance, how good or bad is it to kill a king to avoid a war?).

Still, everything before the power trip was engaging enough.

Kill The Hero

• Webtoon
• up to chapter 53

A fairly classical leveling-genre entry. The setting is very similar to Solo Leveling (modern-day South Korea, dungeons appear, some people get power, and a whole semi-corrupt industry of "heroes" springs up). The twist is that the protagonist is also a returnee that was betrayed in his previous life (another super common trop of the genre). Hence "kill the hero", where the "hero" is actually this scheming villain that everybody thinks is good. I was hoping the title was referring to some story-telling twist or some unusual perspective, but not really.

This one is bog-standard, but indubitably well done.

The Great Mage Returns After 4000 Years

• Webtoon
• up to chapter 82

Another "leveling" story that takes some of the basic genre building blocks and arranges them in yet another configuration. In this one, a very powerful mage (just like in I am The Sorcerer King) dies and returns in the future, this future is not modern-day South Korea, but instead some kind of medieval fantasy.

In his previous life, the mage was defeated by a demigod, some kind of malevolent super-powerful entity. In his new life, the mage seeks to find out what happened to his companions and to take on the demigods.

The story is a bit more earnest than average, and the tone reminded me of The Beginning After The End, which is great since that's one of the best leveling webtoons out there. Recommended.

Your Throne

• Webtoon
• up to chapter 67

Finally, a webtoon that's not about people powering up! This one follows two noble lady — Medea and Psyche. The cold ruthless Medea was promised to the crown prince, before the engagement was broken and he chose to get engaged to the sweet innocent Psyche. Medea swears to have revenge and retrieve what is rightfully hers. And then a lot of things happen but I don't want to spoil you.

This is pretty well done. One criticism I have is that it's at times a bit confusing. Another one is that it departs from the traditional arc format. While I applaud initiatives to be less formulaic, arcs are used because they work, and this works less well. What would have been arcs in other stories instead blend into one another. And I don't mean this in the positive, "story expertly woven" way. Instead, we're not given the time to breathe, assimilate what happened, participate in the protagonist's happiness, sadness, triumph or defeat and instead we're immediately trust into the next thing.

I think saying the story doesn't breathe enough is maybe clearer. As a result, it becomes much more emotionally muted than it could be. Its high points don't take you that high, and its low points don't take you that low. Which is too bad, because the story has potential.

Akudama Drive

• Anime

I watched on the recommendations of a few friends who said it was one of the best anime of the Fall 2020 season (this was a particularly dry season for me, I don't think I watched a single other anime from it, excepted giving Jujutsu Kaisen a try).

I ended up nonplussed. Like, it's not bad. It's not that great either. It's annoying because there are a lot of great things about it. I really dig the aesthetic, the character design is top-notch, the animation looks very good, the music is quite nice. But the story never really got me invested or even interested. The stakes are not that much, character development is meh-meh-meh, the ending is unsatisfying.

I think I'd recommend it if you really dig the outrun/retrowave/neon sci-fi aesthetic or if you watch anime for the eye candy. If you're story-driven, this will leave you hungry.

unOrdinary

• Webtoon
• up to chapter 235

This one looks straightforward, but I actually found it to be quite weird. In this world, most people get a special ability (usually fighting-related — I appreciated how straightforward they all were), and the strong trample on the weak in a very hierarchical society.

The story follows John, who doesn't have any ability, as he has a hard time at his high school, being unpowered as he is but still rather proud. Many twists ensue.

So what makes this weird? Well, first, the society being depicted is despicable. Unrealistically, and unsustainably so, in fact. By the way, fair warning, if you don't want to see kids beat each other meanly and bloodily for 200 chapters, you probably shouldn't read this. There's bullying on every second panel.

Still, surprisingly, no one ever dies — even after someone uses their head to bash some concrete. Nobody ever goes for the eyes somehow. In a world so full of bullying, there also isn't a single mention of suicide. Honestly, the world is so bad that you'd expect that to pop up, and also strong people to be murdered in their sleep.

But alright, none of that happens, and to enjoy the story you really got to take as a premise that it is the way of that particular world to be like this.

This has another awkward consequence, which is that almost everyone in the story is despicable. Yes, even the main character. There are maybe two main characters that are not loathsome, but they were strong and uncaring in a world where you can't walk through two hallways without finding some bullying, which uhhhm ... eeeeh. Some people start to improve towards the end, and to the credit of the writing, this is done in a subtle way.

You know what else is strangely lacking in a high-school setting? Nobody seems to have the slightest interest in romance and/or sex.

Webtoons often shy away from these themes, for what I ignorantly assume must be weird Korean cultural reasons? Although seeing that K-Drama is a thing, this at least makes no sense for romance. Often, there is some romance slapstick, like unreciprocated crushes, tsundere moments, and even the occasional lewd event where the male MC's head lands on some woman's breasts. I really don't get the absence of these themes, which are interesting and complex and inherently interesting to us humans. Someone please enlighten me.

Anyway, unOrdinary doesn't even have the slapstick. Nobody expresses even a iota of romantic intentions or sexual tension. And that's just weird.

With all that said, unOrdinary's story is quite gripping. Despite its characters being often (or at least initially) loathsome, it's a character-driven story and the characters are well-written. They have clear motivations, personalities, and as alluded earlier, there is real character development. The broader story is also solid enough that it makes you want to keep reading to know what will happen and how the characters will end up being implicated in it.

I'm conflicted about this one. On the one hand, I found it hard to put down once I got started, and there is objectively a lot that it does well on the story-telling front. Perhaps my problem with it is a lack of relatability to the characters, given the problems with the setting.

Second Life Ranker

• Webtoon
• up to chapter 84

Yet another formulaic leveling webtoon. A confusingly-named one at that, since in this one, the MC does not return from his previous life, but instead goes by the notes left by his deceased brother.

I don't have much else to say, it's fairly classic as an entry, but quite well done. You'll like this if you like the other leveling webtoon, and vice-versa.

Raid

• Webtoon
• up to chapter 95

Yep, another level webtoon! This one is of the Solo Leveling "monster gates spawn all over Korea" persuasion, though with less emphasis on RPG mechanics (no skill windows!) and less of a fantasy theme (no orcs and goblins and the rest of the fantastic bestiary, just plain old demons).

Aaand, it's okay. Entertaining, but clearly a notch under Kill The Hero and Second Life Ranker as far as not-particularly-original entries go.

Castlevania

• Anime
• Season 4
• Previously: Seasons 1-3

In its final season, Castelevania keeps being good, but imperfect, but damn entertaining.

Compared to the previous seasons, I feel like this one steps up the game in terms of animation. These last few fights are really impressive. On the other hand, maybe we didn't need quite that much fighting? When you get 4 fights back to back, it kind of undermines their weight.

Story-wise (and you know I'm a story guy), it's not bad — I was engaged through — but could have been better. The big conclusion didn't really feel woven/foreshadowed. I expected some big reveal, and I guess there was some reveal, but it fell flat.

For the final season, I also expected some confluence of the storylines. More after the spoiler tag.

I'm curious to watch the spinoff.

Overcoming Gravity

• Book

I picked this up as a book about bodyweight exercise. What I got is not what I expected.

The book tells less about bodyweight training than I'd hoped. Sure, there are instructions and cues, etc. But it's relatively terse. You can easily find more detailed write-ups on Google, and some good tutorials on YouTube.

But, on the other hand, it's an impressive compendium of knowledge of the basic factors that affect strength and hypertrophy training, of how to setup a workout routine etc. In fact, this occupies most of the first half of the book — you only get to details on specific bodyweight exercises at around page 300...

Despite being well-written and interesting, I wouldn't recommend the book for the purpose of creating a routine either. Not unless you have a few years of training (and crucially, experimentation with your routines) under your belt and/or are coaching other athletes. It's written in a very encyclopedic style. I don't mean this in a bad way: it's a presentation of facts. But that means that the book does not read linearly. Despite the presence of "stop reading, take action" sections, the book offer little opportunity to actually start planning a routine until the whole has been read.

So, it's not bad, but unless you're looking for a routine-building reference, I'd try other places first.

Trading Volatility

• Book

Trading Volatility is a book, available online for free about trading in volatility-related products, in particular options.

I started reading the book as parts of my efforts to learn about finance. In the end, I decided to drop it after the first chapter, as it becomes too technical, and not particularly applicable to me.

A lot of the strategies presented later in the book seem to require stock-based hedging, for which you need zero commissions and taxes on stock transactions, as well as some way to automate trading (i.e. a broker with an API). I don't fit these conditions. It also discusses instruments that are not readily available to the retail trader.

It does look very interesting however, but I currently have much more useful things to learn, so I shelved it.

Tales of Demons and Gods

• Manga
• Up to chapter 348

In my quest to find more webtoons in what I've dubbed "the leveling genre", I came across Tales of Demons and Gods. The particularity of this one is that the original is in Chinese.

How much of a difference does it make? Some. Clearly the tone and the attitudes of the characters are different. It's still closer to Korean webtoons than to anything western I've seen however. The tropes of the genre are pretty-well respected: in this case there is a reincarnation, growable powers, a magic school, world-threatening elements, ... There are few added cultural element, e.g. the people grow their "soul power" by "cultivating", a term I've seen popped up in other Chinese media (notably Mo Dao Zu Shi, which I didn't enjoy so much).

As far as the story goes, it's really long, and it's pretty decent. Details are woven throughout, so it's not just choppy arc after choppy arc, but you can still expect the leveling hustle to take up most of the space compared to the intrigue. It might be tiresome after a while — this one is definitely not a literary masterpiece, but it's fun enough.

True Detective

• TV Show
• Season 1

After hearing so much about it, we finally took the leap and watched the first season of true detective. There is a second season, but the characters and story are completely different — it's just reusing the same principle. People say it's less good, but since I haven't seen it, I can't comment.

The story revolves around a pair of cops, one of which is new (where have I seen that before?) as they investigate a murder steeped in voodoo spiritism.

What really makes the show is it's grisly, bleak and oppressive atmosphere. It really doesn't make you want to move to Louisiana where the story takes place. The characters are dark and conflicted.

Putting together this atmosphere in a way that's interesting and keeps you engaged is really the show's greatest strength. It is a somewhat unique experience, I must admit.

As for the plot itself... it's decent, I suppose? I kept expecting more twists, more reveals, some acceleration of the intrigue, and in the end I was pretty let down. I think a great plot would have elevated this from an interesting show to a masterpiece.

Still, as-is, it's well worth watching. If you're afraid it's not your jam, just watch the first episode — if you don't like it I doubt it's worth going any further.

Koi to Yobu ni wa Kimochi Warui (Kokoimo)

• Anime

We were looking for something more romcom-ish to watch with Sasha and landed on kokoimo.

The dangerous-sounding plot is a young salaryman falling in love with a high-school girl, pursuing her as best he can.

The shows ends being quite inoffensive. It's decent enough I guess, though I lack points of comparison in the genre (which is not my forte). Still I have watched it and not hated it. I also didn't think it was particularly interesting.

That Time I Got Reincarnated as a Slime