Tempo blockchain deep dive
tl;dr
Currently on a flight from MIA -> SEA. So I read the Tempo (opens in a new tab) docs in their entirety. Here's what I learned in the last 4 hours, and why they're going to eat an extremely large portion of the current stablecoin transaction volume ~$300B (opens in a new tab) and likely rising to trillions within the next 10 years.
The engineering that they're promising is extremely impressive because the protocol has the following characteristics:
- (a) fundamentally reduces volatility to currencies and
- (b) creates primatives to expand on what stablecoins are today.
On the flip side Tempo lacks two major keys to obtaining transaction volume from businesses:
- (i) very little actually useful tooling for people running businesses onchain.
- (ii) privacy will be a major question mark that needs to be solved if they want to actually eat other chains lunch.
Most great businesses, their mission is short and clear. Here is Tempo's.
(opens in a new tab)
As someones who thinks about payments for a majority of my waking hours. This was me, because blockchains are just a mechanism to order and process payments... So making a "payments blockchain" seems like reinventing the wheel.

I still had 4 hours and 59 minutes left on the flight, so I eventually got to the meat and potatoes of the protocol.
Tempo is a chain with native stablecoin arbitrage tools configurable for every user, increasing the amout of Arbitrage opportunities, but increasing the access to tools. This creates a more efficient market. Then it is also a plus that it is being built on top of stablecoins vs. a native crypto asset subject to high volatility.
(opens in a new tab)
They're launching with the main token type being TIP-20 (opens in a new tab) that extends the ERC-20 token standard, which a few interesting specs, some are listed below.
Big ones
TIP-20 Token Standard in General
- Core token standard with native stablecoin features and policy registry integration. Great feature engineering. See a few features below
- They also added a 32 Byte memo field to each transfer. I will likely try and build an entire ERP system with the 32 byte limit and try to compete with Oracle and SAP.

TIP-20 Rewards
I initially drafted this rewards section as a positive, but the more I research, the more confused I got about where the rewards / yield was coming from (which is not a good sign).
- Reward distribution system for token holders with automated yield mechanisms. Every TIP-20 has parameters that are configurable around the yield generation of the token / rewards
- There's no fee-on-transfer logic anywhere in _transfer. There's no automatic skimming from trades. The function is simply: anyone who is authorized under the transfer policy can call distributeReward() and deposit their own tokens into the contract for pro-rata distribution.
- The rewards are likely going to be used by the stablecoin issuers to incentive holding the tokens.
TIP-403 Policies
- Policy registry system for compliance, access control, and token governance for stablecoins. This expands the competetive envirnment around governance protocols, which will be great to see play out
Smaller items
Fees: Multi-token fee payment system with AMM / Onchain order-book for stablecoin conversion. Tempo Transactions: EIP-2718 transaction type with native passkeys, batching, scheduling, and fee sponsorship. Blockspace: Block format and payment lanes. Payment lanes are TIP-20 token transfers, and are allocated 40% of the blockspace, to not clog the pipes on high transaction volume periods
HUGE new feature
Stablecoin DEX: Enshrined stablecoin DEX for stablecoin interoperability. Nice one

What does this solve?
It eliminates volatility through the following tree mechanism, where all stablecoins are likely one to two tokens removed from eachother and tied together through the underlying currency.
(opens in a new tab)
(opens in a new tab)
All TIP-20 are connected via a routing structure that's build into the enshrined DEX-- which is just a fancy way of saying that it's a precompiled smart contract on the different validator implementations. Making it an efficient implementation of a smart contract.
Building an efficient market
My next thought was that with large amounts of routing how does the protocol combat front running?
For transfers, there's a few built in functions that combat this-- with the swapExactAmountIn(Out) functions, and a view function where you can predict the routing. This native tooling is a useful estimation tool, as traded span across ticks of the DEX.
Then when you want to pull the trigger the following happens:
(opens in a new tab)
Liquidity providers
Because this is an onchain order book not an AMM (where the supply sets the price with a bonding curve). The enshrined DEX has liquidity providers to set limit order at specific prices (ticks). But the really interesting part is flip orders.

This is where the Tempo team was really cooking.
A flip order is automated market making without a pool: You place a bid at $0.9990 (tick -100) with a flipTick of $1.0010 (tick 100) Someone sells to you → you buy at $0.9990 Your order automatically becomes a sell at $1.0010 Someone buys from you → you sell at $1.0010 Your order flips back to a bid at $0.9990 Repeat indefinitely
Doubts / Cons
Unclear Strategy for DEX Protocol vs. Payments optimization
A strategic decision was made to have the above DEX tree strucute, to route the stablecoin trade natively. They do this with blockspace guarantees for payment vs. non-payment transactions. These are deteremined to where if the tx.to address is a '0x20...' (TIP-20) then it's a payment transaction-- basically a normal token transfer. However, I just stated above that their design choice of implementing the native dex into their system, which is not a payment transaction. I'm sure they'll get a bunch of data early in the mainnet launch that might result in a change to this configuration.
32 Bytes
I mention above that the 32 bytes we got were great, but within current ERPs, almost all unique ID's are 1000X longer than this. It's clear now that Tempo isn't competing in the space of becoming a business chain, but rather just a banking chain.
Privacy
The general meta in the space is the need for privacy. Which will likely turn into private blockchains if we can't figure out how to encrypt some of this data. This is actually a great reminder that I don't know enough about privacy technology.
If you have made it this far through this far. Thank you for reading, truly. I'd love to chat about any of these items.
Anthony Garrett.RSS