Before Ethereum’s transition to proof-of-stake (PoS), Miner Extractable Value (MEV) was primarily captured by searchers and miners. Today, on Ethereum, network stakeholders known as builders and validators compete alongside searchers for MEV revenue. In the future, there will be even more participants fighting over MEV. This begs a few questions: How is MEV currently distributed between participants? What is the total size of the MEV pie today? What will the total MEV market and its distribution look like going forward?

MEV is Endemic

MEV is the surplus value extracted from blockchain systems. As long as there is value transacting through a permissionless system, there is MEV. For example, if a trader sets too high of a slippage setting, a searcher can sandwich their transaction. In this case, the searcher captures MEV at the trader’s expense. To explore the factors that shape MEV, it is essential to have a taxonomy that understands the growth and declines of distinct MEV segments.

Although MEV often has negative connotations, MEV can feed into the ecosystem’s health. MEV can create incentive alignment for the system’s actors. For instance, without searcher liquidations and arbitrage running between venues, protocols would accrue bad debt, and users would face larger spreads, receiving worse execution onchain.

Observable MEV is The Tip of The Iceberg

While calculating MEV’s Total Addressable Market (TAM) is challenging, we estimate the lower bound of annual MEV extracted from Ethereum is between $300M — $900M, based on estimates from various data providers [1].

This MEV TAM is the summation of value lost by MEV. For example, if a transaction is worth 100 units of value and the user only ends up with 90 units of value, 10 units of value is leaked to MEV. In practice this is calculated by identifying MEV transactions (e.g., arbitrages, sandwiches, or liquidations) then determining searcher revenue. This number can be further split into searcher profit, builder profit, and net new money to validators.

However, we would estimate that the true MEV TAM is larger than the $300M — $900M spread, and that the 2022 MEV TAM could exceed a billion dollars. Calculating MEV’s true TAM is difficult since MEV analytics are best at identifying MEV that follow predictable or deterministic patterns, such as arbitrages, sandwiches, and liquidations. This does not capture the long tail of MEV with NFTs and other DeFi applications, hence the real TAM is actually larger than the estimates. Today, market participants are increasingly sophisticated as they compete with each other. For example, off-chain hedging cannot be tracked, Multiblock MEV is challenging to identify, and probabilistic MEV is almost impossible to detect.

Validators Capture the Majority of MEV

The status quo is that validators (also known as proposers or block producers) capture the majority of Observed MEV. Over time, we have seen profitability shift from searchers to validators and recently back to searchers. Revenue compression is especially apparent for sandwiches and liquidations, as these types of MEV opportunities are highly competitive. Searchers must bid most of their expected value to block producers to ensure transaction inclusion.

However, validators may be taking a smaller slice in practice as the Total MEV is much greater than the Observed MEV. Additionally, the universe of Unobserved MEV tends to be less competitive. Therefore, searchers will not have to bid as much for transaction inclusion.

Who Will Capture MEV in the Future?

The standard today is that three parties capture MEV — block producers, searchers, and builders. However, there is a prevailing narrative that MEV originators, often the transaction originators, should get rebated for the MEV they generate. MEV-Share is a recent instantiation of this philosophy, where searchers can bid on order flow from users, wallets, and/or dApps. Ultimately, there are market dynamics that drive how much senders get rebated for the MEV they generate and how MEV surplus value is distributed between different market participants. But there is a philosophical question that asks what is the optimal split between MEV originator vs. searchers vs. other parties.

MEV-Aware Apps Will Reduce MEV TAM

However, this debate over fairness and value distribution is likely moot. As multiple parties fight to access the MEV surplus, we expect MEV’s TAM to decrease. From an application or dApp perspective, why should they leak value to searchers when they can keep the value for themselves or their users? These “MEV-Aware” apps will implement features that reduce the MEV they generate.

This is already happening. For example, MakerDAO and Euler both use auctions for liquidations as opposed to lenders Compound and Aave, which set liquidations at a fixed discount. In Maker’s and Euler’s case, because keepers compete on price to liquidate a loan, the liquidated user suffers a reduced loss. In other words, it recaptures value that they would have lost. For Aave and Compound, there is a fixed liquidation discount. This means that the liquidated user suffers a fixed loss, instead of a variable one that is likely less than the fixed amount. As apps compete for users and liquidity, we can expect dApps to implement features that reduce value leakage to encourage usage over competitors.

How will dApps think about allocating value? Instead of having a liquidation auction reduce the loss to LPs, the protocol can implement an auction fee that shifts some value back to token holders.

We expect applications to use a better combination of mechanism design (primarily auctions) and smarter parameter defaults to plug MEV leakage that their users experience. Some examples include UI warnings to prevent fat fingering, volatility, and pool-aware slippage limits for AMMs. The famous 2.08m USDC to 0.05 USDT swap can easily be prevented.

Looking back at our MEV taxonomy, we expect some categories to be easier to minimize than others. For example, front running and sandwiching will be minimized through more intelligent slippage settings. However, some forms of MEV might be inevitable-arbitrage between DEXs, for example, cannot be easily reduced without changes to the base protocol [2].

Who Decides the Future?

The MEV market landscape will continue to evolve going forward and impact various market participants. Many interesting questions remain: How will protocols balance the needs of different user groups and how will value flow between these groups? Will the market decide on what amount of MEV should be returned, or instead will there be intervention by protocol designers? Will users gravitate towards protocols that protect them more from MEV, or will users ultimately not care?

We expect application-specific MEV will approach zero in the medium term. Over the long run, inter-application MEV will slowly shift more value back to the originators of the order flow through protocol design. Ultimately, protocols and dApps who protect their users the most will win.

Many thanks to Sina, Hasu, Dev Ojha, Walter Smith, and Christine Kim for their conversations and feedback.

Endnotes:

[1] MEV TAM estimates from various data providers.

[1] Chorus One’s data annualized is roughly $921m a year (their data starts from August 2020 and ends at the Merge)
[2] Chorus One further separates the number into good and bad MEV, $713.95M good (arbitrage and liquidations) + $1206.11M bad (sandwiches)
[3] EigenPhi only has data for 2022 and onwards
[4] Flashbot’s does have sandwich data in Dune, unfortunately the data is not particularly clean. However, digging around has yielded numbers that are similar to Chorus One’s topline.

[2] Arbitrage between venues is difficult to minimize without changing the underlying L1/L2 protocol. Some designs include auctioning off access to the first transaction in a block, but that would require a change to the base layer. Though there may be some constructions where if a sufficient percentage of ETH validators restake then there can be an extra protocol auction.

[3] Dev from Osmosis notes how this can be mitigated by enshrining the oracles into the consensus for appchains (forcing ⅓ of the validator set to collude is difficult). Perhaps restaking can be used to mitigate this. Or auction for the right to “submit” the oracle update, and thereby the right to front run / back run it (h/t Sina)


Data

• https://dune.com/lsquared/mev-boost-detailed
• https://github.com/lsquaredleland/MEV-Distribution

Originally published at https://www.galaxy.com.

NFT rich and USDC poor? Fortunately for you, lending markets have popped up — you can deposit your NFT and borrow against it. Alternatively, if you want instant liquidity and no one has a buy offer, deposit the NFT into an NFT ETF and sell the ETF share.

NFTs or nonfungible tokens represent unique assets that are not interchangeable with their peers. Generally, NFTs are predominantly collectible eye candy such as Punks or BAYCs, but today include financial positions such as off-chain assets or Uni V3 LP positions. And now they’re slowly being integrated with onchain financial infrastructure — the DeFification of NFTs has begun.

NFT DeFi Taxonomy

DeFi primitives such as lending, trading, options, insurance, etc., are permissionless building blocks that enable anyone to earn yield and access financial tooling. These primitives are well established in the tokenized world but are nascent in the NFT metaverse. Building a taxonomy enables us to classify different types of protocols and understand which areas are being unexplored.

Taxonomy Highlights

Some quick learnings from the current NFT Defi landscape:

• NFT marketplaces, fractionalization and lending are deeply competitive markets.
• The majority of NFT trading is p2p rather than AMM-based.
• NFT native DeFi applies to both collectible NFTs and financial NFTs (ex: borrowing against Uni v3 LP positions and off-chain assets)
• Insurance for NFTs doesn’t exist, it’s also unclear what this would look like
• Analytics are surprisingly siloed, where tools will only look at NFTs on particular networks.

NFT Native DeFi

Tokens are convenient for protocol designers; they are fungible, each one interchangeable with another. If you deposit one ETH into a pool and withdraw it sometime later, you don’t need to get the same ETH back as all ETH are the same — thus, one ETH is always one ETH. This is not the case with NFTs where each one is unique; therefore, integrating NFTs into existing DeFi infrastructure involves tokenizing NFTs, making them fungible — for example, making all NFTs from a collection equivalent to each other. But then you lose the granularity and nuances of each NFT.

Take lending protocols, where you deposit an asset and borrow against it. Before NFT native lending protocols, if you wanted to borrow against their NFT, you would first tokenize it, most commonly through an ETF tool such as NFTx or NFT20. These protocols work by creating a pool of NFTs and issuing tokenized derivatives representing the underlying assets. Then once you have the ETF token, you can deposit it into a lending protocol that accepts.

However, the protocol values each NFT equally regardless of their actual value due to the ETF design. One NFT deposited into the pool creates one ETF token. And this value isn’t the average of the entire pool of NFTs. It is the value of the cheapest NFT — commonly known as the “floor price”. This means even if you have a more valuable NFT, the protocol is ignorant and returns you only 1 ETF token. Thus you can only borrow against the floor value rather than the actual value of your NFT. With NFT native DeFi, using protocols such as PawnFi — NFT holders can borrow against the fair market value of their assets which takes into account the unique attributes of their NFT.

Lending Protocols: Native vs Non Native NFT DeFi

Looking Forward

Now that DeFi is beginning to include NFTs, what kind of future could we imagine? Especially of the more exotic kind.

• Subprime NFT Crisis: NFT loans that have been packaged into CDOs[1] turn out to be much less valuable than expected, and given a massive correction in the NFT market, borrowers default as their loans are more valuable than their original NFTs.
• NFT ETF Arbitrage: As all NFTs within the NFT index cost the same amount to redeem, game randomness in the redeem() function to extract NFTs whose fair market value[2] would be higher than the floor price.
• Orphaned NFTs: Bridge rugs cause the NFT to be stuck on another chain away from home.
• NFT Bridging: Transfer NFTs to chains with privacy or unique applications such as more efficient auction methods.
• NFT Perpetual oracle manipulation: Perps require an oracle to determine the asset price on other exchanges to calculate the funding rate (as the price of the perp should be in line with the price of the actual asset).

NFT native DeFi is exciting. Due to the inherent nonfungibility of NFTs, how will protocols encourage liquidity, will AMMs even exist, or will everything be RFQ? Or will everyone be using some tokenized form of NFTs? What about the market size? Many collections of NFTs only have 10,000 NFTs — will this limit market participation, or will most users own synthetic representations of NFTs instead? Only the future can tell.

Footnotes:

[1] CDOs or Collateralized Debt Obligations take individual loans and bundle them together into a financial product that smooths out their repayments. (If one lender defaults, the impact is lower). Oftentimes CDOs will have different tranches with varying payout seniority.

[2] Clearly FMV is extremely vague for NFTs, but sometimes certain traits become more popular and fetch prices greater than the floor price.

Please contribute @ github.com/lsquaredleland/NFT-DEFI

Special thanks to Cindy Jiang, @0xSanthosh, my Galaxy Digital teammates and others for providing feedback.

Ever take the wrong bridge and ended up in the wrong place and had to backtrack to get to your final destination, but ran out of gas so you got stuck? As more protocols for blockchain interoperability reach mainnet, this will be a common problem if one isn’t careful. And the impact of crossing the wrong bridge can be much worse than a quick turnaround. One might have to wait days to return, assuming they have the proper fuel[0] :)

With the explosion of blockchains and interoperability projects (+40), routing between chains will become a common occurrence. Already 10s of billions are locked in bridges across the ecosystem. But not all interoperability solutions are the same. Each one has its own trade-offs, and each one will have to fight for market share.

Bridges != Swaps

Interoperability is a catch all for blockchains interacting with each other. But there are two categories for these protocols — bridges and swaps.

Archetypal bridge

User locks an asset on Chain A, then mints the same asset on Chain B. Some bridges are pairwise, they only connect two chains at a time. Others are more network-like, where users can transfer an asset from one chain to several potential chains — the benefit being if a user crosses the wrong bridge, they can bridge to the correct chain without having to backtrack as much. The final category is centralized bridges such as wBTC or USDC or Binance-pegged assets on BSC — this is where a centralized entity issues the asset on-chain.

Archetypical Swap

Trades asset A on Chain 1 for asset B on Chain 2. A swap does not transfer assets between blockchains[1]. For example, Thorchain doesn’t enable users to move BTC to ETH, rather it swaps BTC for ETH. The user ends up with ETH on the Ethereum chain, in exchange for BTC on Bitcoin. However, if the desired asset is already on the destination chain[2], users can swap USDC on Matic for USDC on ETH. Depending on the construction of the swap protocol, one’s counterparty might be an AMM or a market maker. Under certain conditions, the protocol might even pay a user to swap an asset to a new chain ;).

Path Dependence

Because each bridge has its own set of contracts, an asset is tied to the bridge that it comes across. USDC brought over by bridge X become xUSDC, and USDC brought over by bridge Y become yUSDC. xUSDC and yUSDC each have a separate ERC20 contract and therefore are not fungible or interchangeable with each other.[3]

This is horrible from a user and developer perspective. What happens if a user goes over the incorrect bridge and ends up with xUSDC when all applications use yUSDC? They’re forced to go back and use the correct bridge. Then on the application side, should developers integrate both or just one? If they integrate both, how should the assets be evaluated? Should they have the same parameters in an application, or should the risks and nuances of each bridge be taken into consideration?

If the market for a particular asset, say USDC, is big enough on a particular chain, then it’s possible that xUSDC and yUSDC can co-exist. Though in general, we suspect monopolization tendencies for bridges to dominate specific assets. This is the case with BTC on Ethereum, historically there were over a dozen competing standards, but today wBTC and HBTC represent 90% of the market share. We’d expect the original issuers of an asset to have a strong influence on which bridges they support.

Fight over Canonical Contracts

The canonical asset contract is the contract that captures developer and user mindshare, it’s the contract that everyone integrates. Users only want to have one version of an asset, not two or more versions of the same thing (no one wants to have to choose between xUSDC or yUSDC).

Bridges will compete with each other to own the canonical contract for particular tokens. For example, Matic’s Plasma bridge captures the $MATIC token market, whereas the PoS bridge is a catch-all for all other assets traveling between the Ethereum and Matic chains. In the future we expect newer bridges to try to capture specific assets from the generalized bridge. Already Aave has a bespoke bridge for transferring aTokens from ETH to Matic to handle unique accounting.

We expect these new bridges to compete on multiple fronts, such as being more secure or having a network-like construction. But the design space is expansive. Bridges could implement novel features such as flashminting, native cross-chain governance, user/developer-friendly features[4], cross-chain function calls[5], etc. That could attract more mindshare from the generic catch-all bridges. Alternatively, some applications may follow an Aave approach and build custom bridges to handle special cases (governance, mechanisms, etc) or to have more control over their assets. But then again, are dApps equipped to build robust bridges? Which is adjacent to their core business.

Economics of Interoperability

Every single interoperability solution has different costs for using them. Users have to pay a fee on the originating chain, but generally receive assets for free on the destination chain. For bridges the costs tend to be fixed, where the size of the transaction does not affect the cost to go across. This is not the case with swapping protocols, or at least the ones that use AMMs. As the depth of the liquidity pool will affect the price that a user gets to move across it. For large transfers it might make sense to take a slower but more cost effective route.

Predictions for Interoperability

1. Bridges fighting for market share — with dozens of bridging protocols coming online, there will be a tremendous fight for market share. Initially, bridges will start by connecting under-connected chains and targeting assets that have yet to be bridged. But that market is small and quickly closing; eventually, bridges will play a narrative game — trying to persuade the market that their solution is the “safest”. Or maybe they will start yield farming programs to attract liquidity :)
2. Speed doesn’t matter for small transactions on bridges because there are “fast bridges” or swaps — Bridges will not compete on speed with each other as there are swapping protocols with significantly lower security that enable users to traverse blockchains faster. A current incarnation is Hop protocol, where users trust an oracle to relay their transaction across a chain. And for small transactions, the risk is relatively low. For large transactions, users may desire to take a slower bridge that has lower fees and increased security. (And if there is insufficient liquidity in the “fast bridges”, users are forced to take slower bridges)
3. Large users, yield seekers and market makers will be the largest bridge consumers — each blockchain is its own siloed self-contained community. This is especially true when there are stronger native onramps to each chain. The average user does not need to use a bridge. Only yield seekers trying to find the latest farm far out on the risk curve or professionals trying to arbitrage assets and rates across chains.
4. Interoperability will break crypto’s dependency on atomicity — the magic of transactions on one chain is atomicity. This is why flash loans can exist only in a blockchain environment; if any aspect of the transaction fails, the entire transaction reverts. Look at DEX aggregators. Users either get all the assets they want, or the transaction fails; they don’t have to worry about only getting half. Atomicity does not exist for applications in real life. Smart order routers — the IRL version of DEX aggregators have to build logic to handle exchange connections dropping or transaction failures. Interoperability will force developers to have a different mindset when building cross-chain applications. Now partial failure cases have to be accounted for.
5. Interoperability aggregators — there are dozens of bridges and swapping solutions. Many teams will attempt to build an aggregator to unify them all. This is a nontrivial technical and UX problem for these teams; you no longer have atomicity :).
6. Fiat assets will remain centrally issued and only bridged onto new chains — fiat-backed assets such as USDC will be issued directly by CENTRE to other chains. This will also create problems[3]. For the newest chains that are still untested, bridges will bring over fiat-backed assets as issuers will wait for the chain to prove itself.
7. Bridges are useful if a user already has assets on the destination chain. What is the point of bringing over an asset if the user doesn’t already have the native fee token? Otherwise, the assets become stuck. Users have to acquire the native gas token either through a centralized exchange or a swap protocol. We expect interoperability to potentially abstract gas away or inform users to also swap / bridge over the native assets of the destination chain before bringing other assets over.
8. Some bridges will collaborate and share a canonical contract to make the UX for developers and users seamless, at the cost of increased risk (have to trust both bridges). Celo Optics is pioneering this. (h/t @pranaymohan)

Footnotes

[0] Generally users pay using the native token of the source chain to move assets to the destination chain. If they do not have the native token of the destination chain, they will be unable to pay to bridge back to the original source chain.

[1] Technically a bridge doesn’t transfer assets between blockchains either, the asset is locked on the origin chain for the duration of the cross chain activity — but this purely a technicality.

[2] Via an existing bridge.

[3] This dynamic of bridged assets having a different contract address from natively issued ones will cause large liquidity fragmentations. For example, USDC is natively issued on ETH and Solana. If there is a huge demand spike for USDC on Solana and CENTRE is slow to issue more, users who bridge USDC from ETH to Solana will learn that this bridged USDC is not interchangeable with USDC issued natively on Solana. Which is a horrible UX, the only way to fix this is if Centre acts as a centralized stableswap and lets users move USDC between chains quickly. (h/t Dev Ohja)

[4] Preventing users from sending tokens to the contract. Letting developers use batchCall to save gas, etc.

[5] In the future we expect cross chain function calls to become more important. One can imagine a cross chain ETF product that owns different assets on each chain, automated rebalancing can occur through cross chain contract calls.

Thanks to Dev Ojha, Jon Kol and Will Nuelle for feedback.

Legal disclaimer: Galaxy Digital Ventures may or may not be invested in some of the mentioned protocols above.

A Uniswap grants 💎🤝 Compound grants collab

In collaboration with Uniswap grants and Compound grants, we are excited to announce a joint competition — Suprememe. Memes are some of the most effective ways of conveying information and breaking down complex ideas into digestible pieces. Who will create the best meme (image, video, sound, etc) to demonstrate particular aspects of each protocol?

The 1st iteration of the competition will go on for 4 weeks. Each week will have a different theme.

Process (all days end ~Midnight EST)

1. On Monday the theme will be released
2. Submissions due Friday — Contestants can submit up to one meme per protocol. Details and submission form here
3. Community voting from Saturday to Tuesday
4. Meanwhile a new theme is released on Monday
5. Prior week’s winners are announced Wednesday.

Prizes

Final Thoughts

The goal is to have fun. This IS an experiment, each week we’ll refine the process. If you have any suggestions my twitter DMs are open (@lsquaredleland)(Thoughts on submitting memes as NFTs? — assuming there’s a non gas guzzling way).

To keep in the loop, follow @uniswapgrants and @compoundgrants on Twitter for subsequent details and links.

Liquidity mining (LM), incentivized pools, yield farming — all terms to describe a strategy where a user provides capital to a protocol in return for its native token. Although liquidity mining is common in crypto, it by no means originated there. Electronic markets since the late 1990s have offered rebates to liquidity providers. Looking into exchange rebate programs and their structure will create more effective liquidity mining programs in DeFi.

Initially intended to enable graceful decentralization to project users and enable fair launches, token distribution programs have evolved to focus on growth marketing, increasing AUM and users through subsidies. Most liquidity mining programs have been successful in terms of temporarily increasing AUM but tend to be expensive and the growth dissipates after the program concludes. Uniswap was able to attract billions in liquidity during their incentivized pools but proceeded to lose over a billion in TVL along with market share to other DEXs when their program ended[1]. Granted Uniswap has more liquidity now than it did before the start of liquidity mining, but at the cost of 20M UNI tokens or ~60m USD. Ultimately can Uniswap, other DEXs, and DeFi projects implement a liquidity mining program that will attract users and liquidity while being sustainable indefinitely?

The Maker-Taker Model

Like Uniswap, centralized exchanges of the late 1990s faced stiff competition from each other for market share. Initially, they charged both the makers and takers of liquidity. This means no matter if you put in a limit order which adds to the total liquidity or used a market order which took away the existing liquidity, the fee would be the same. In hopes of attracting more liquidity, an exchange, Island ECN[2], implemented a maker-taker fee model in 1997. Where the taker of liquidity pays a small fee, and the maker of liquidity gets a rebate or cash back in common parlance. To clarify, a maker of liquidity creates limit orders and is rebated when their order is executed. And generally, as rebates < fees, this model is sustainable[3].

Rebates drive liquidity

Holding all variables constant, when given a choice between exchanges with and without rebates, a market maker, broker, or trader intuitively would prefer to execute their limit order on maker-taker exchange. Why give up “free” money[4]? As a result, whenever an exchange implements maker-taker pricing, it increases liquidity, tightens spreads, resulting in more volume and revenue overall. But what is liquidity exactly? When exchanges incentivize limit orders, the total amount of stock available to be taken off the market increases drastically, meaning that prices are less likely to move the market whenever there are large trades — hence less slippage and better liquidity.

This model proved so attractive that Island’s market share grew from 3% to 13% of NASDAQ’s trades in two years. Since then, the majority of exchanges and alternative trading systems (ATS) in the US have implemented a maker-taker model[5]. Though the uptake among crypto exchanges is lower, mainly due to the market structure[6].

Rebate design

Each maker-taker exchange and ATS has a different rebate and fee schedule[7]. Although arcane to the outsider, they intended to incentivize particular types of trading behavior that the exchange believes will be helpful, similar to crypto economics. Variables will include:

• Particular securities
• Who is the market participant: trader, broker, designated market maker, SLP, retail, etc
• Percentage of total volume the market participant contributes
• Proprietary or not (meaning is the market participant trading their own capital or routing client orders?)
• Time of the order
• Percentage of quotes within certain percentage of NBBO (applicable to designated market makers and SLPs only)
• Price of the security
• Routing strategy

Skim the NYSE and Cboe EDGX’s fee schedules to appreciate the complexity. (Weird DEX fee pricing schemes seem so straightforward compared to this).

Applying Maker-Taker models to DEXs

Decentralized exchanges can fall under two broad categories — central limit order books (CLOBs) and automatic market makers (AMM). The former is structured similarly to most centralized exchanges where maker-takers models can be applied directly, whereas the latter requires some creativity.

Some CLOB DEXs are currently dipping their toes into maker-taker models. Loopring charges takers 0.2%, and makers receive a rebate of 0.016%, meaning for every 100 dollars, the taker pays 20 cents, and the maker gets 1.6 cents. This rebate to fee ratio of 8% is extremely low relative to CEXs in and outside of crypto. Qualified market makers generally expect to get 80 to 97% of the fee as a rebate. In contrast, 0x v3 has a variable taker fee based on the transaction gas cost, and the fee is rebated every ten days in a convoluted way back to the maker[8]. Both these exchanges should return more value to makers to incentivize more resting limit orders to reduce spreads to attract takers[9]. Because takers pay the makers, maker-taker models do not cost the exchange anything beyond lost revenue.

Unfortunately, rebates don’t map well to AMMs. AMMs are a type of DEX that uses a mathematical function instead of an order book to price its assets. The price is based on the ratio of two or more different assets deployed in a pool. There are two market participants — traders who only can make market orders and liquidity providers who deploy assets into the pool. In some sense, AMMs are the epitome of maker-taker models as LPs will receive rebates by default. Uniswap LP’s currently get 0.3% of all trades, which is significantly larger than what Loopring and 0x and centralized crypto exchanges offer. Regrettably, to reduce slippage for AMMs, there must be more assets pooled together which can be capital inefficient. If trading volumes are flat or do not grow sufficiently, the fees will be less per dollar of contributed capital. This makes new LPs wary of deploying capital into the pools as their yields will vary. Due to this dynamic, AMMs have to find ways to increase both pooled assets and volume at the same time.

AMMs should consider paying directly for order flow or volume, aka payment for order flow[10] (PFOF). Rebate DEX aggregators with the transaction fee to incentivize trades. For example, Uniswap could split the 30 bps fee to the pool’s LPs and the aggregator.

Future of rebates in crypto

Protocols need to think about the long term incentivization of their users. Indefinitely minting governance tokens can’t exist[11]. Rebate programs will become cross-subsidized, taking profits from particular actions to incentivize healthy behavior. The design space is vast, and there have been exciting designs. Thorchain has a slippage based fee that charges more to traders who create lots of slippage, resulting in more fees rebated to LPs.

Additional Notes

Caveats of rebate structures

Despite the liquidity benefits of rebates, there have been debates over second-order effects that were not initially a concern. The most consumer-facing one: given multiple venues to route a customer’s order, a broker could send the order to an exchange that offers the most generous rebate, which might not be the customer’s best execution price — a principal agent problem. Although this is explicitly banned by the SEC under NBBO as brokers have a fiduciary duty to get the best price for clients, determining the “best” price at a particular point in time is difficult. The SEC tried to indirectly reduce the rebate through a new ruling (Rule 610T in 2018), but exchanges rebelled, and the courts ruled the SEC lacked authority. (Side note an estimated 2.5 billion has been distributed through to rebates)

For now this is not a concern in decentralised markets as most trades are made directly with the exchange rather than using brokers, more commonly known as DEX aggregators, such as 1inch or Slingshot. Though in the future if DEXs start reducing fees or even giving rebates to aggregators, should their users expect the benefits to be passed on? Given the lack of any self regulating bodies, it seems unlikely.

Footnotes

[1] In itself, there is nothing wrong with LM programs that are costly and finite. They can be great ways to prime the pump — this piece is more about long term LM programs

[2] ECN or Electronic Communication Network is an Alternative Trading System (ATS), they fill a similar role to exchanges.

[3] Some exchanges offer rebates greater than the taker fee. This practice is sustainable as exchanges have multiple revenue streams such as selling data (which in practice can be equal to trading revenues)

[4] In practice, the traders are concerned about the “liquidity profile” of an exchange, e.g., quantity/quality of liquidity (fill ratios, adverse selection, the impact of HFT, etc). There’s no point in routing an order to an exchange with a high rebate if the probability of getting it filled is low. Conversely, for DEX this translates to the likelihood of failure, estimated slippage, front running, etc

[5] Some exchanges have maintained the flat fee model. Several have an inverted “taker-maker” model, where the taker gets rebated for liquidity, and the maker pays for adding liquidity.

[6] A guess is this is due to the market structure of crypto exchanges where the exchange itself owns the customer experience. In contrast, in traditional markets, a user will interface through a broker to multiple exchanges. Because switching costs are high, exchanges have more substantial pricing power. Routing orders tend to be difficult as exchanges also function as custodians; moving coins from exchange A to B takes time.

[7] RegNMS (17 CFR 242.610(c)(1)) limits “fees for access to quotations” or the cost to remove liquidity from an exchange at 0.3 cents per share; this has an indirect limit to set the max rebate to less than 0.3 cents per share. (But this is not always the case, and this only applies to RegNMS, options do not have access fee limits). The per-share pricing can be confusing initially as fees at crypto exchanges are represented as basis points rather than say per BTC.

[8] Have to include the ZRX token somehow :/

[9] But then again, if all CLOB DEXs have low rebates, market makers have no other choices. Some centralized exchanges probably would like to collude to reduce rebates so that they can capture a bigger spread on every trade.

[10] Payment for order flow is not a rebate from an exchange. It’s a rebate that market makers will give brokers the privilege to route their orders for them. (Though in turn, the market makers could get a rebate from an exchange, which is often the case)

[11] Maybe they can exist, similar to Ethereum and Monero’s tail emissions of infinite inflation

Special thanks to Yi Sun and Dmitriy Berenzon for their conversations and feedback.

You can follow me on Twitter here.

The general election in America is a pretty big deal. The president has a lot of powers and has a great effect on the global geopolitical landscape. With stakes this high, one would expect voter turnout to be higher than only 50 to 60 percent. If the turnout for the general election is already low, what about the turnout for midterm elections, state referendums, or municipal elections? Voter turnout drops even more. Imagine how low that number will go for corporate governance or those blockchain governance tokens you hold[0].

TLDR: people don’t really vote.

In the world of corporate governance, small shareholders don’t vote at all, while large institutional investors outsource their voting to professionals known as proxy advisors[1]. A similar phenomenon is occurring in dPoS blockchains, where token holders delegate to staking pools.

Governance Across Crypto Networks Are Inconsistent

The ethos of a decentralized network is the lack of central powers that have unilateral control. This generally manifests in a system where various stakeholders have some order of influence on the development and operation of a protocol. They can range from token holders to masternodes, core developers to ecosystem participants (miners, exchanges, etc) — in general, a diverse group. But depending on the protocol, only a subset of stakeholders may have tangible power. And to create a quantifiable Schelling point, some protocols only allow token holders governance rights.

Each protocol has a slightly different governance process, different norms and traditions that must be understood. And these processes are not static — the Ethereum EIP process has changed over the years. Even if we focus exclusively on token-based voting and ignore custody and key management, the voting process is inconsistent. For MKR holders, tokens must be locked up in the voting contract. In Decred, one must either create or buy tickets to cast. In PoS, protocol tokens have to be locked up for a certain number of blocks before votes can be accepted, along with an unbonding period before one can switch delegators. And what about those pesky precatory (nonbinding) resolutions and nonbinary votes?

Governance Impacts Are Difficult to Quantify

On the approachable end of governance, Dash has a treasury fund where masternodes vote on various proposals which are generally marketing related. The topics themselves are understandable to a nontechnical audience and a “bad” vote has a low impact on the protocol itself.

Conversely, there are technical governance proposals whose impacts are significantly harder to reason about — what should the updated Dai savings rate be in MakerDAO, 0 or 1 or 1.75 or 8 or anything in between? The cost of a bad outcome can destabilize and bring down an entire ecosystem. Higher interest rates are great for Dai holders, but at what price? What metrics should one optimize for, are there KPIs? What about considering users who don’t have governance rights?

Governance Has a Meta Game

Once one knows how to vote and what to vote for in particular, how should one deploy their political capital? If you only have a trivial percentage of votes, this does not matter. But if you are a large tokenholder with limited political capital one must be careful on how they play their hand.

Back to the Makerdao example. Should a MKR holder signal their intent by submitting a “polling vote”, which is nonbinding? If so, should it be done at the beginning of the polling period or at the end or should they only participate in the executive vote? For Cosmos / Tezos should one take a passive or active role in governance, should one only vote on proposals as they come or should they draft and code and submit their own proposals? Should one submit their proposal immediately or wait all the existing proposals have been wrapped up in hopes that the community will be more focused next governance epoch? But how strong will one’s political capital be after the current voting period? Or how much voting power will one’s supporters have as delegators may have reallocated their tokens? There’s a voting meta game that exists beyond the governance outcomes themselves and one must play their cards carefully in protocol governance realpolitik.

Proxy Advisors Job is to Focus on Governance

Most token holders are passive, they are simply holding the token for yield and staking to prevent loss from inflation. And if they’ve been constructing a portfolio of assets that maximizes their return for a given level of risk, presumably there is more than just one asset. Juggling various governance schedules and proposals for each protocol consumes a nontrivial amount of time. People are busy, even if portfolio management is their full-time job.

In the equities world, index funds and mutual funds both manage portfolios with thousands of equities, why would they care about the governance of a small cap stock that is only 0.06% of their portfolio even if they are a major shareholder? This market need has been filled by proxy advisor firms who are paid to spend their entire existence evaluating and voting on governance proposals on their clients’ behalf. All the client needs to do is set some voting preferences such as pro ESG and pro diverse boards then disappear.

Cryptonetworks need these actors to fill the governance gap. Granted yes one has to pay them, which is already the case in staking. So wouldn’t it be nice to tell a proxy advisor to focus on scalability for one protocol and block xyz collateral types for a stablecoin? Or even have them be proactive and draft proposals and implement code and an actuarial risk assessment too[2]? They can handle all the intricacies of blockchain governance, keep track of emergent politics and allegiances…

Token Holders are Delegating Power Now

Although it is uncommon to use independent[3] proxy advisors for dApps, delegating in dPoS and PoS system is the status quo[4]. In those protocols, the top stakers (by total stake) can actively participate in consensus and governance. In order to be a top staker, one must either be a large token holder or have other token holders delegate to them. If you are delegating their tokens to a staking pool, they are using a proxy advisor. Or if your tokens are in Coinbase these days or any exchange that stakes on your behalf.

These staking as a service providers are making governance decisions on your behalf. The question is do they have your best interest at heart? They don’t have a fiduciary duty to you, and you probably based on a mix of convenience and fees (particularly in protocols where delegators can’t get slashed). The next time you stake, try to understand what your staking provider’s stance on particular governance subjects are. There are staking providers who have specific agendas, such as promoting privacy tech. It would be unfortunate to indirectly support a proposal that you are against, especially if votes cannot be individually recast (in the case of Tezos). Or if your hashpower was supporting a fork you personally disliked (unless one is optimizing purely for profits then it might not matter à la Nicehash).

The Future is More Delegation

Proxy advisors traditional perform the process of voting on behalf of their clients, however in the cryptoverse keys cannot just be handed over as the advisor may run off with your funds. In order to safely delegate onchain, the voting mechanism must be independent of the spending mechanism[5]. dPoS and PoS protocols generally have these features built-in[6]. But for dApps, there has to be more infrastructure created, in the status quo large MKR holders don’t vote because have to move their tokens out of cold storage to the voting contract. Whether the solution is SGX, MPC or some smart contract, infrastructure has to be created to separate voting from spending[7]. With that welcome the future of more centralized and institutionalized governance.

Fun Thoughts

• Another way to think about proxy advisors is institutionalized liquid democracy (something DFINITY is working on)
• Yi Sun noted: Governance controls can be subdivided into two categories: controlling external assets (e.g. Ether locked in a smart contract) vs controlling only internal assets (e.g. Ethereum inflation rewards). This can lead to unexpected outcomes for the parent protocol. If the expectation that only n% of Ethers are in circulation because of staking and DeFi and all of a sudden circulation has increased dramatically — what happens?
• What happens to governance if your tokens are in a tokenset or a comparable contract.
• When will a protocol implement tenured voting? Though there are clever workaround here.
• Will exchanges allow their users to vote with their deposited tokens that are staked?
• If you’re lending out a token and there is a dividend, what happens? (the default is not what happens in the equities world)
• What kind of damage can a rogue proxy advisor cause? Along with the recourse mechanisms that protocols will build to counteract this threat (e.g. an exit game: MakerDAO emergency shutdown or REP universal fork)
• If one is delegating their governance tokens are work tokens and DAO tokens are up next?
• What would happen if there are multiple types tokens with varying voting powers? Like Google class B which has 10x the voting rights as Google class A. (There’s also a class C share that has no voting rights, oddly there is a sub 1% premium for class A over class B, implying shareholders don’t value governance). Or perhaps variable voting rights based on the size of the staking pool, forcing delegators to trade-governance rights for fee optimization (credits to Tarun).
• What if the largest staking providers collude to have a developer fund pay out to their own addresses as a dividend, or more politically tenable — to a burn address?
• Proxy advisors are getting new regulation in the corporate world

Footnotes

0. I should have clarified this is intended towards retail investors voting for both blockchains and corporate governance. Most corporate shareholders are dominated by institutional investors who do vote (albeit through proxy advisor firms) and voter turnout is greater than the US elections.

1. Proxy advisors submit proxy votes on behalf of their clients. The votes themselves are submitted by proxy as historically shareholders (even large ones) did not want to physically attend the annual general meeting. Some public companies don’t even have in person AGMs.
2. Tarun from Gauntlet noted how an actuarial risk assessment is desirable
3. Protocols / dApps have foundations who often make professional risk / governance suggestions to the community which are generally accepted by voters, however they are not an independent third party.
4. Yes before this there were mining pools but the connection between allocating hash power and a pool supporting a specific fork is not as strong as say token based voting.
5. On some levels this is at odds with “Dark DAOs”, by creating this separation it also makes it easier for vote buying to occur. It would be interesting to see protocols implementing systems to make delegation more difficult through “complete knowledge proofs” or other forms of coercion resistance. This is important as it proves a key holder has complete control over their key and that a briber does not have partial control over the key (e.g. the ability to sign votes but not transfer funds).
6. Sans bond pooling in Tezos where the delegator gives complete control of their tokens to the staker. Tezos also has conventional pooling.
7. Or more simply, dApps can have a special voting key that is derived from the private key.

Special thanks to Tarun Chitra, Matteo Leibowitz, Yi Sun, Dev Ojha, Yi Sun, and Jon Kol for helpful feedback, comments, and insights.

By Leland Lee and Haseeb Qureshi

After the DAO hack of 2016, the Ethereum community was faced with an existential quandary: should the community roll back the chain to revert the DAO hack, or let the hacker get away? Those who said yes forked away to what is now called Ethereum. But those who said no, who didn’t roll back, they are now known as Ethereum Classic. This is a classic example of blockchain statecraft: by creating a new fork, a minority coalition can effectively secede from the majority.

But Ethereum will never again have a meaningful minority fork, in large part because of DeFi’s inherent fragility.

A thought experiment

Imagine that ProgPoW, a controversial EIP, is merged into the codebase and will be deployed in an upcoming Ethereum upgrade. The EIP, which bricks the current generation of ASIC miners, is so polarizing that the community breaks out into infighting.

Soon they divide into distinct factions: anti-ProgPoW and pro-ProgPoW. Reddit and Twitter users change their online handles to signal their allegiances. A civil war is brewing, and everyone must take sides.

In the meantime, DeFi operators watch anxiously. Their hands are tied: they cannot pick sides too early. Why? Because for a DeFi operator, picking the correct fork is critical to their system surviving, and nobody wants to be blamed for instigating additional conflict.

Let’s say that USDC is the first to cross the Rubicon. CENTRE, the organization that issues USDC, announces that they are not supporting ProgPoW, and USDC will not be redeemable on the ProgPoW fork. Of course, this means that USDC will become completely worthless on the ProgPoW fork — after all, USDC is a system of record for dollar-backed IOUs. Only one system of record can correspond to the real liabilities of CENTRE, and so the USDC ledger is effectively meaningless on the other chain.

On seeing this, all DeFi operators are forced to now follow USDC’s lead. They cannot defy CENTRE. The reasons for this are subtle, and increasingly define Ethereum DeFi. Composability both rules and constrains everything.

As the second most used stablecoin in decentralized finance (or DeFi), USDC represents 99% of all fiat-backed stablecoins locked in DeFi applications.

All other fiat backed stablecoins have negligible usage in DeFi. But so what, you might say — this is a problem that the market can solve. Let other stablecoins like Tether and TUSD, which have billions in circulation, step up and take USDC’s place.

But what about the existing financial instruments that use USDC, directly and indirectly? DeFi could hypothetically survive without USDC, but given how deeply entangled it all is, it’s incredibly challenging to extricate it quickly and safely.

The pain of separation

Any DeFi app that does not follow USDC needs to have a coordinated extraction process: post fork, everything denominated in USDC will become worthless. Given the composability of DeFi, this removal has to be coordinated across the entire ecosystem. Just imagine what this would look like:

• Fixed term USDC loans or derivatives would have to be prematurely terminated (Dharma and Nuo Network).
• As people run for the exits and try to sell out of their USDC positions, arbitrageurs (who convert the USDC into USD) would not be able to divest fast enough, and USDC would plummet in price.
• Bank runs might occur on contracts like Compound where the majority of USDC is actively being lent out, preventing lenders from taking out their deposits. This would drive up the borrowing rates for USDC.
• Holders of USDC in passive positions would have to come online, which may be difficult for those using cold storage.
• Operators of DeFi abstraction layers like Outlet.finance or Astrowallet would have to integrate alternative stablecoins.

Facing such a bloody unwinding process, DeFi operators would have no choice but to side with CENTRE and throw all of their weight behind the USDC-blessed fork, regardless of where community opinion came down. Were they to defect, the damage would be more than just a technical hiccup: the real harm would come from disruption and lost of trust from their users. Financial systems and smart contracts are based on the assumption of predictability, and when that is violated, users are unlikely to return.

Were DeFi operators to not move in lockstep, the decentralized financial ecosystem would be thrown into pandemonium. This is a classic game theory situation: the incentives are overwhelmingly in favor of coordination, so all of DeFi is forced to move together.

So all of DeFi sides with USDC. But what about the people who commit to the opposite fork?

The valley of D-ETH

Imagine a small cohort goes through with the fork. Still optimistic, they brand their chain Decentralized ETH, or D-ETH. What will they find on the new chain waiting for them? As in all forks, the entire state of all smart contracts will be ported over — but without the operators to keep them running, what will happen?

Oracles stop posting data feeds. There are no more prices. Anything that used a price feed is now broken.

All centralized stablecoins are now worthless. Tether, USDC, TUSD, PAX, all gone. Most operators freeze the contracts, making the tokens now untransferable and unredeemable. For smaller stablecoins, no one even bothers.

Any borrowers who used USDC as collateral have walked away with free tokens. Of course, unless the borrowed tokens were Dai, they’re effectively worthless — there isn’t even a market for D-REP (the forked REP token) because Augur is no longer functioning. All long-dated Augur bets have become effectively debased. Not enough D-REP holders show up to report on outcomes. No UI even points to the D-ETH version, though there are complicated instructions someone posted in a Github issue somewhere. Eventually, the contract stops being poked entirely.

A few contracts still work, like 0x and Uniswap, since they don’t require any external actors. But liquidity is scant, as the prices of all the D-tokens have collapsed, and nothing is correctly priced anymore. The moment the fork goes live, smart arbitrageurs race to snipe 0x orders and Uniswap markets that are incorrectly priced post-fork.

And then of course, there’s the elephant in the room: Maker. It has too much D-ETH at stake in the minority fork to just ignore it. They could let the system ride out, but because the system is now backed with D-ETH instead of ETH, the system will be instantly undercollateralized post-fork. Almost every CDP must be liquidated, and the D-PETH must be auctioned off for D-Dai (which the system burns to deleverage itself). But there is little demand for the D-PETH that gets auctioned off, and most D-Dai holders are not paying attention to the minority fork, so the D-Dai supply is depressed. This leads to a massive undersupply of D-Dai and an oversupply of D-PETH being mass-sold into the market, causing a deleveraging spiral and huge price spike for D-Dai.

Seeing this writing on the wall, Maker governance decides to simply trigger global settlement on the minority fork. It’s not worth the headache. All D-Dai on this chain gets liquidated and eventually converted into D-ETH balances. The D-Dai holders who are paying attention claim their D-ETH balances. But when they turn around to sell their new D-ETH, all the selling causes a rush for the exits, crashing the price for all other D-ETH holders.

This causes anything dependent on D-Dai to instantly break. Uniswap D-Dai markets, Compound D-Dai markets, Augur v2, almost anything that uses D-Dai is now fundamentally broken. Even if they have fail safes in place for global settlement, most operators don’t have the infrastructure and deployment processes to manage their system on two chains, so many simply write it off.

All websites, interfaces, block explorers, and wallets ultimately point to the majority chain. Game operators like CryptoKitties lock their D-ETH contracts so as not to confuse their users. The minority chain is so barren as to be basically an empty blockchain.

If you imagine the movie version of this saga, the minority chain looks like an abandoned metropolis. Towering buildings sitting empty, alarms going off with nobody to respond, smoke billowing in the distance. There’s no one to even bother rebuilding for.

The minority community grumbles about conspiracies. But once D-ETH liquidity slows to a trickle, it becomes clear exchanges won’t list the debased D-ERC-20s. Economics can no longer tie the revolutionaries together. The early volunteer developers stop showing up, the community withers away, and the project is finally abandoned like all the other ETH forks that have been lost to history.

The value of ETH

What this little thought experiment tells us is: Ethereum is not what it used to be. In 2016, Ethereum was still a proof of concept, and ETC could plausibly claim to be a better vision of how the “world computer” should evolve. But today, it’s clear that ETH is valuable because of the systems that exist on top of it. Unlike Bitcoin, whose ledger is simple enough that forks are functionally airdrops, ETH’s ecosystem is incredibly complex. Because its applications are intertwined with unforkable components, the entire system is rendered unforkable. Any minority fork is doomed to obscurity.

DeFi is ultimately the kingmaker of any future governance crisis — users, miners, and developers certainly have a voice, but the chaos that would be unleashed by unraveling DeFi ties everyone else’s hands. With all of the new higher-level financial applications coming online in the next year, DeFi is liable to only become more fragile.

If there can never be another ETC-like fork, then it seems that “governance-by-fork” will become a thing of the past. Welcome to the post-forkable era.

Thanks to Dan Robinson and Tarun Chitra for their feedback and insight on this piece.

Ethereum is now unforkable, thanks to DeFi was originally published in Dragonfly Research on Medium, where people are continuing the conversation by highlighting and responding to this story.

How many steps does it take to claim that kitten? The official guide from the creators of CryptoKitties instructs users to first install Metamask before purchasing Ether, followed by many additional steps. This shows how terrible Blockchain UX is. Users are helpless without having the underlying protocol token. This locks out a huge portion of the population from adopting blockchain.

There’s a concept called “meta-transactions” or “fee delegation” that permits a third party to pay for a transaction fee on behalf of a user. Today we will survey the different techniques across Ethereum, Stellar and VeChain that enable these transactions and compare them with our evaluation framework.

Meta Transaction Use Cases

A common use case for meta transactions is for improving usability for first-time users, but they have more applications.

1. dApps want users to only use their native token (ex: for paying fees)
2. dApps want users to use their native token for governance, voting, etc, without users being tied to the underlying chain (which makes chain migration easier)
3. Streamlining accounting for users. Calculating capital gains for every single transaction across multiple accounts is painful for even the most intrepid accountant.
4. Streamlining key management. Have one master wallet that contains funds and child wallets for every single device
5. Encouraging particular behaviors. Ex: encouraging the users to add rather than remove liquidity on a DEX [Granted there are other ways of facilitating this that might make more sense such as exchange rebates]
6. Potential increases in privacy if accounts don’t need to be funded for transactions. It is not as obvious that user of dApp A is also a user of dApp B as they don’t usually need to send native tokens to each other.

Ethereum

Having one of the largest developer communities in the blockchain space, Ethereum has a diverse set of proposals that enable meta transactions. Note some of these are still proposals while others are being used in the wild and there is no consensus on what the best approach is as of now. (also DM me if you feel that the categorizations are off in any way)

Smart Contract Based Delegators

• Proxy Bouncers
• Gnosis Safe
• Status IdentityGasRelay

New Token Standards

• ERC-1776 Native Meta Transactions
• ERC-865 Pay transfers in tokens instead of gas, in one transaction
• ERC-1003 Token Standard (ERC20 Extension)
• ERC-1228 Delegated Execution

Wrapper Contracts

• ERC-20 Wrapper

Changes to EVM

• EIP1035 Transaction execution batching and delegation

Relayer Networks

• Uport TxRelay (requires compatible smart contracts)
• Aragon’s Pay Protocol
• EIP-1613 Gas Station Networks

Signature Standards

• ERC-1077 Executable Signed Messages refunded by the contract

Due to the plethora of proposals for Ethereum, we will not go into detail for every one, instead we will focus on Proxy Bouncers and EIP-1613.

Proxy Bouncers

A relayer can deploy a proxy contract and add additional addresses to its whitelist and enable them to transact through the contract. This allows any dApp user to interact with any smart contract that it chooses to, as the transactions are forwarded by the proxy contract. The limitation of this system is that the msg.sender is the proxy contract rather the account which might be an issue when interacting with particular types of smart contracts.

EIP-1613

Because meta transactions rely on a third party to relay transactions, early implementations had a single point of failure, the sole relayer. There have been attempts at creating decentralized relayer networks that are censorship resistant. However without a coordination layer the thundering herd problem might arise, resulting in all relayers trying to relay the same transaction with only one succeeding and the rest wasting gas.

EIP-1613 uses an anchor of trust called the RelayHub which acts as a registrar of relays (aka gas stations). The RelayHub mediates transactions between relays and dApp contracts. Relays are staked and they build reputation scores which will enable users to select relays with a decreased worry of being censored.

Stellar

Channels

Stellar channels were originally intended as a method to increase the transaction throughput of a single address. This is because Stellar transactions must be ordered and submitted in sequence and there is no guarantee of ordinality with the Horizon server (node software), potentially leading to bad sequence errors. Channels were a roundabout way to increase throughput by using different accounts to send transactions while maintaining the same “source” account for funding of these transactions.

Creatively, the concept of channels can be retooled for meta transactions.

1. Create Stellar account
2. Fund account with a minimum balance
3. Users create a transaction, specifying their sponsor as the `source` address (ie the payer)
4. Users transfer the unsigned transaction to their sponsor
5. Sponsors sign the transaction
6. Users sign the transaction and submit it (note users can sign the transaction before sending it to sponsors, however they will have to trust the sponsors to submit the transaction in a timely manner)

Note that the Stellar protocol mandates each account to have a minimum account balance of 0.5 XLM. Therefore channels may not be optimal for first-time users unless a third party is fronting the cost (perhaps the dApp the user is trying to interact with). However because the current cost is rather low, it might not be a huge issue (compared to say EOS account creation costs). But it is still a constraint that must be noted.

VeChain

Multi-Party Payment (MPP)

Protocols should elaborate in their documentation on the origin of their naming system, why is there so much diversity in naming, fee delegation or is it meta transactions again :p.

Anyhow, MPP is VeChain’s native form of fee delegation.

1. dApp creator deploys contract, they are the default master of the account.
2. A sponsor can sponsor the smart contract and pay for gas fees, if there is no sponsor then the contract pays for transaction fees (if toggled)
3. The master sets a credit plan for their smart contract. Credit is the max amount of VTHO (VeChain’s gas) per user and recoveryRate is the amount of VTHO that can be accumulated per block. This mechanism allows for automatic top off of users’ allowances for gas, and functions as a mechanism to reduce abuse.
4. The master adds or removes User(s) to use their smart contract
5. User sends signed transaction to the dApp
6. Check that User has sufficient credit (each user has their own credit balance)
7. Transaction is executed and the sponsor or master account’s gas balance is deducted

Unlike the other protocols that we have explored, MPP exists entirely on-chain, there is no off-chain co-signing process involved. Whether this is considered a desirable behaviour or not is up for debate.

(Fun side note: the VeChain foundation is currently sponsoring several dApps gas to encourage adoption and usage.)

Note: MPP applies to the entire contract. It is not possible to sponsor only particular function calls.

VIP191: Designated Gas Payer

To increase the flexibility of VeChain’s MPP protocol, a new standard has been approved and is awaiting implementation. VeChain Improvement Proposal 191 allows for any arbitrary “gas payer” to co-sign any transaction on behalf of the sender.

The signing flow follows:

Transaction Creation → Gas Payer Signing → User Signing → Submission.

Because the user is the one who submits the transaction to the Blockchain, he or she can control the submission timing.

VIP191 enables:

1. dApp creators and sponsors to pay fees only for particular actions rather than for all interactions with a particular smart contract. For example, in the case of a DEX that allows for fee-less limit orders and paid market orders. This encourages participants to add liquidity rather than take it away.
2. Sponsor interactions with other contracts that the dApp developer does not own. If one wants to use the VET+ contract (similar to WETH in Ethereum), the developer would not be able to sponsor the wrapping in MPP as the contract is owned by someone else.
3. Attaching additional operations by the payee/delegator. The payee can attach a clause saying he or she will accept payment in another token, the user can either sign and agree or toss the half signed transaction. This is useful for dApps who have their own internal token.

Desired Features / Comparison Matrix

Just because there are dozens of different ways to build meta transactions does not mean that they are all equal in feature set and capabilities. It is necessary to understand both the trade off space along with the associated use cases of each implementation.

• Self Sovereignty — Are users the custodian of their own keys? (This a is a must).
• Liveness — Do users require someone else beyond the the maintainers of the underlying blockchain to be online? (ie: relayer network or individual relayers)
• Multiple Delegators — Can there be multiple delegators / relayers.
• Integration — Can dApps implement this features without changes to their underlying smart contract code?
• Cost — How much is the cost of such transactions, how much more is it compared to a non delegated transaction
• Rate Limiting — Are there constraints on how many fees can be delegated per user?
• Versatility — Can this implementation work for many use cases or just one?
• Payee Flexibility — Can the payee be anyone, or is it just the creator of the contract, etc?
• Timing / Censorship — Does the user have control over the timing of the final transaction?
• In or Extra Protocol — Is this feature native to the blockchain?

What’s Next?

Ultimately meta transactions are an interesting strategy for improving the user experience when interacting with blockchains. But perhaps that is the wrong mindset to have, maybe blockchains should be difficult to transact with. Nonetheless this is the status quo, what trade offs should protocols make make when building meta transactions?

Further Readings and Research

Organizations Working on Meta Transactions

This list was compiled from looking around the internet, we have not verified that the actual development of these companies / projects.

• Ethereum: Argent, Universal Logins, Tenzorum, uport, MetaCartel, Portis
• VeChain: Totient Labs (CometVerse)

Note on Free Transactions

There are other protocols that claim to have “free” transactions, however, there is always a cost unless you are being subsidized by someone else. (And free transactions are slightly different from meta transactions in practice).

• IOTA has free transactions but users must mine two other transactions before they can send their own.
• EOS has free transactions but users have to create an account and stake EOS to use the protocol, but this process is fairly expensive.
• Nano has free transactions but users must perform computation when there is a p2p transaction.
• NEO has free transaction for NEO transfers only (up to 21 per block).

Up And Coming

Both ICON and Near Protocol are in the process of creating their own version of meta transactions for their respective protocols. Can’t wait to see what implementation they end up with and how they compare in trade offs.

Thanks to Kevin Britz (Totient Labs) and Illia Polosukhin (Near Protocol) for their insight on meta transactions across different implementations and protocols.

The State of Meta Transactions was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve seen both Ripple and TRON announce 100MM USD funds to invest into the blockchain gaming space. The interest and capital is here. How will the centralised incumbents respond? If both developers and players want to have a blockchain enabled world, they could go with a plethora of protocols that are being developed. But what if the incumbents decide to incorporate blockchain-like properties while maintaining their centrality. What does blockchain enable that the centralised incumbents cannot do within its technical and legal capacity? And can these incumbents get the same benefits without having to use blockchain? In this piece, I will compare properties of Steam’s centralised peer-to-peer game item marketplace with blockchain-based marketplaces for game assets such as RareBits and OpenSea, and discuss what centralised companies can do to become blockchain like without actually using blockchain.

Note: a lot of the discussion here will be explorative. just because a company can decentralise a particular component does not mean that it makes the most compelling business use case or the most financial sense.

Motivations

I’ve wondered how would centralised entities respond to perceived blockchain risk for their business. If decentralised infrastructure provides xyz properties, could the centralised incumbent respond with xyz’ properties, ie something similar? Do consumers want to have Snapchat or do they just want ephemeral video so Instagram stories is an alternative — not exactly the same thing but close enough. Is this something that centralised companies can also do in regards to blockchain?

Centralised Company

For the purpose of this article, I will focus on centralised cloud based companies that are closed sourced and profit-seeking. And more specifically, my analysis only applies to companies that:

• Don’t create software that anyone can deploy and run for free (ie they are not FOSS companies)
• Services require network connectivity (as in cloud based)
• Monetise through advertisements, selling subscriptions (SaaS), or fees

Valve created Steam which is a centralised cloud based marketplace for ingame items. One of the most popular game items or digital assets that are exchanged are skins for the game CSGO. Currently the Steam marketplace monetizes by taking a slice of every marketplace transaction which includes selling of new skins[1] and trading of skins between players. Steam has a monopoly on the marketplace, there are no other ways for players to trade skins without going through Steam.

A blockchain-enabled platform first requires the game items to live on a blockchain, think Ethereum’s Cryptokitties. The platforms built on top such as OpenSea or Rarebits provide both a UI and mechanisms for auctions and trading. Although these two marketplaces are hosted[2] it is possible to have self hosted marketplaces like OpenBazaar.

Blockchain Properties

Blockchain is a censorship-resistant, immutable and permissionless ledger. These three properties reflect the high level attributes of this system. They are the manifestations of a distributed consensus mechanism, applied cryptography and network incentives. These properties as we will see are not exclusive to blockchains.

Censorship resistant — It is expensive for entities to censor an individual on the network.

Immutable — State is append only. No previous state can be overwritten[3]

Permissionless — Anyone can run the network.

• This means the code is open sourced
• And that anyone can fork the network

Micro Properties

• Verifiable execution / State transition rules — There are cryptographically enforced rules on how a blockchain can change from state A to state B
• Incentives to maintain the network — There are incentives for those who run the network on their computers
• Fault tolerant — The system is difficult to take down
• Data sovereignty — Users have control of their own data

Can Centralised Entities Have These Properties?

What Can Centralised Companies Do

Here we delve into potential steps that centralised companies can take to have more blockchain properties.

Censorship Resistant / Anonymity

It is possible to architect systems that have varying levels of privacy from pseudo anonymity to zero knowledge proofs. An exchange implement a zero knowledge system where items may exchange hands and to outside observers they have no idea what trade hands and for how much. Even though trades can be anonymous, a game will still be able to identify what items a user has as those assets must be rendered for the player (though there probably is a clever scheme where this is not the case). Note anonymity is a touchy subject if there is money flowing around in a system.

Immutable

Blockchains are immutable, meaning that once state has been committed to the blockchain, it can no longer be mutated. Companies can hash a snapshot of their data every night with the hash of the previous night and publish the output in a public place such as OpenTimestamps or a newspaper. Then create tools for any user to verify the integrity of the data.

Bellcore Labs hashed their researchers’ work and posted the hash in the NYT everyday back in 1992. Steam could create a data structure for all their customers and their item balances and publish the hash in a blockchain and / or a multitude of public sources.

Verifiable Data

Why trust a platform that a process is truly random or that only one hundred of these special items exist when it can be done with cryptography. Gone will be the days of uncertainty.

Verifiable Execution / Smart Contracts

Although traditional business logic does not adhere to the cryptographic guarantees of smart contracts in the blockchain sense. Is it possible to implement the equivalent for a centralised company. Similar to verifiable data, systems can be built to verify that state transitions have occured and that the output is deterministic and correct. A user can verify that a trade has finalised and within his account there is a new item. And if companies want to get fancy they can use tools such as Ricardian Contracts, which unifies traditional legal contracts to cryptographic contracts.

Incentives to Run the Network / Community Governance

Blockchains allow network maintainers (miners) and token holders to make governance decisions about the future of the protocol. Some protocols let these stakeholders change parameters such as the inflation rate or accepting new protocol updates. Centralised companies have governance in the form of shareholders. They are not necessarily end users and may have competing interests. To avoid this, a platform could try a co-operative model where all players are also owners.

Fault Tolerance

Although 51% attacks on blockchains do occur, for the most secure chains these attacks are extremely expensive and seldom in practice. Even if an attack takes place, as long as a user does not transact during that time period they do not have to worry about a transaction being replayed. Centralised systems can be engineered in ways to be extremely fault tolerant, making it extremely difficult to take them down by either hacking or normal server failure.

Data Sovereignty

Any data a user commits to a blockchain, she can extract. Even on privacy blockchains, as long as the he keeps his view keys, historical transactions can be privately viewed. Centralised companies can do the same, building tools to allow users to extract their own data. Although this is not done normally out of charity, regulations such as GDPR article 20: Right to Data Portability forces companies to allow users export their data.

What Can Centralised Companies Not Do?

Technology can greatly push what companies can do to mimic blockchain properties. However this can only take us so far when it comes to legal arbitrage and fork-ability. Technology might be able to de risk some legal concerns, but it is yet to see if it can diffuse all legal concerns.

Legal Arbitrage

Although companies can perform varying forms of legal arbitrage by setting up subsidiaries and incorporating in various jurisdictions, there are legal limits in what a company can partake in. For example there is no such thing as a legal murder market. Even if the company ran privacy preserving infrastructure and had no clue what was running inside of their servers (perhaps using trusted execution environments), a cease and desist would stop their operation. Because there is a single target to go after, centralised companies have extreme difficulty in evading authorities. At best companies can claim plausible deniability on the use of their technology. But blockchains don’t have to. It is difficult to go after the developers if they don’t run the network. Steam had to clamp down on their API since they discovered third party platforms facilitating underage gambling. Whereas decentralised marketplaces have no ability to censor their users who may be anonymous.

Permissionless Running

Nearly all cloud companies have centralised infrastructure running on premise or in the cloud. Try to name a centralised company that lets users run core infrastructure. Yes apps will often run AI models locally, but that is not core infrastructure. These companies must own their infrastructure in order to keep control of all the data that flows to them. Most marketplaces have a review system, these reviews are curated for the buyer. The precise ordering is not merely sorted by time but instead by quality, relevance and deletion of fraudulent reviews. This requires more than just the reviews for product A, but rather A through Z, detecting patterns across all products. Perhaps innovations in federated machine learning will change this in the future, but until then it will not be possible. This is a problem that plagues peer-to-peer marketplaces. For example OpenBazaar does not have the best curation layer in terms of search and reviewers with personalisation nonexistent. How would they effectively defend against “review bombing” which happens to centralised platforms like Steam? The short answer is that there is no quick solution.

Fork-ability

Because centralised companies cannot let outsiders run core infrastructure, these companies cannot be forked. No one overnight can decide that they dislike Valve’s Terms of Service and migrate not only their history but everyone else's history to a forked version of the platform. Even if the code of the marketplace was open sourced, the data will still be missing which arguably is the most valuable component. In contrast, in a decentralised marketplace anyone can fork the entire network whenever they want to.

Though realistically this may be an advantage to centralised companies, because they are unfork-able there are no distributions to the user experience and political conflicts between different factions.

Perpetual Interoperability (via APIs)

What excited me about decentralised protocols is their permissionless nature, anyone can built on top of the network and no be censored down the line. The greatest fear of building on top of another platform is the cutoff of API access. Horror stories are abound, Zynga bootstrapped off Facebook’s user base, when their exclusive relationship ended, Zynga fell face first. Twitter has done the same with 3rd party apps, cutting off event streaming. LinkedIn too. Why should developers trust that the platform that they build on is benevolent, why should they trust that the platform will not arbitrarily change their APIs or even worse cut off access? Maybe legal contracts could be a stop gap measure, but drive to hoard data is too strong, the more data a company acquires, the better the algorithms, the more sticky the recommendations, why share?

Incentives

Although there are many things a centralised company could do to have more blockchain properties, what are the incentives for them? If you take a company like Valve, what is the forcing factor to be more open (besides regulatory intervention)?

• Providing provable scarcity increases the trust in the platform
• By letting other developers build on top of their infrastructure it increases their distribution effectively for free.
• Having the perception that their platform is more open which increases trust
• Having blockchain properties with a strong brand is good marketing

Advantages to Centralisation

Perhaps centralised incumbents adopting blockchain properties will put them ahead of their blockchain only competitors. Unlike blockchain only companies, these platforms will have a better user experience in terms of personalisation and content curation. Instead of having to see all the items that are available to buy or trade, the platform understands who the player is and what they want to see. Rather than a the uncurated firehose of data that blockchain based marketplaces provide.

Advantages to Centralisation

I suspect that the future will be a happy medium between decentralized protocols and centralised interfaces. Even though Steam has a 100% monopoly of the skin market, what if all the digital assets were issued on an open protocol and rules around transfership and fees were encoded in the asset? Steam as the original asset issuer could program a slice of every single transaction, increasing their revenues. They could operate a centralised user centric data curation layer that provided an improved UX over other platforms and charge for it. And there would be other marketplaces. Cryptokitties has their own auction interface, but kitten owners can trade through protocols like 0x or DApps like OpenSea and Rarebits. Not only increasing consumer choice but increasing distribution.

Centralised Incumbents vs Blockchain Upstarts

• Valve vs Forte
• Ticketmaster vs Tari
• Amazon vs OpenBazaar (distributed tech not blockchain persay)
• Twitter vs Mastodon (distributed tech not blockchain persay)

Only time will tell if developers want to built on top of blockchain protocols or use centralised companies that have blockchain like properties. But the fact that centralised companies can get very close to blockchains should be worrying for their blockchain competitors. I expect that we will end up seeing a future where both worlds end up merging together, with decentralised protocol and centralised entities operating on top of them, who are perhaps even the previous incumbents.

Footnotes

[1] Selling digital skins have zero COGS, effectively zero distribution costs and effectively zero transaction fees. Though a concern is inflating the system and suppressing the price on the open market.

[2] A hosted service in this context means that a user can access the network by simply trying a URL. This contrasts greatly with self hosted services where the user must download software that interacts with the network, requires users to be online, etc.

[3] Blockchains in practice are not as immutable as they say they are. There are attacks that can cause a reorganisation of the chain, however they tend to be very expensive to conduct in Proof of Work systems.

Can Centralised Businesses Implement Blockchain Properties? was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

To help censorship resistant, immutable, and permissionless blockchains gain wide spread market adoption, a lot of changes have to be made. Every individual layer of the ecosystem needs to become more usable from the base protocol to the end-user interface. These layers must leverage the unique properties of blockchain for meaningful adoption to occur. Because what’s the point of using a censorship resistant blockchain if the interface is censoring?

Today is the first piece in a series of posts detailing blockchain usability for the different blockchain layers (that we have made up completely, mildly modelled after the OSI model). Here we will focus on the base protocol, working our way up in subsequent posts.

Blockchain Layers of Abstraction

The internet follows the OSI model:

a conceptual model that characterizes and standardizes the communication functions of a telecommunication or computing system without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard protocols. The model partitions a communication system into abstraction layers….A layer serves the layer above it and is served by the layer below it.

The layers exist as an isolation mechanism, one working on the top-most layer should have no concern for what goes on below it, and vice versa; this is complete abstraction. This is a foundational modern developmental practice. In the past the developer of a robotic arm would have to know how each hardware device communicated with the other. But now there are common APIs, so developers do not need to worry about the register format, I2C addresses, etc, allowing for code reuse, quicker development, etc. Albeit at the cost of lower performance, but the develop speed outweighs this by magnitudes. And the same applies to Blockchains.

Careful design decisions at the lower layers of the stack can greatly impact the usability of upper level layers. Without a secure foundation anything on top is shaky at the best. Users can’t trust a protocol if the cryptography is broken :).

Taxonomies can be built in many ways, these layers reflect the current mental model for UX, please reach out for suggestions. For some inspiration: Multicoin’s Web3 Stack, a Vitalik post from back in the day, Web3 Foundation, Evan Schwartz’s 5 Layed Interledger Architecture, Blockchain Application Stack and 7 layers of financial cryptography.

Usability in What Context

Before we can even determine what makes a blockchain usable, we need to understand the objective of the protocol. If a protocol is intended to be used only for tracking and managing assets for the overnight market for banks then the protocol can be permissioned or federated. Whereas if the protocol is intended for permissionless infrastructure for non fungible assets the requirements for usability is much different (BFT consensus, etc)

People often say how transaction low finality time, high transaction throughput and low transaction costs are essential for any blockchain, but in reality they are independent of usability depending on what the protocol’s goals are. The same goes for consensus rules, a blockchain does not need to be byzantine fault tolerant if the network is permissioned or federated. With this in mind, we’ve been careful to only discuss common usability attributes that can transcend these different design goals.

Started From the Bottom

Starting from the bottom, we can ensure that layers built on top have the ability to inherit the usability features that have been natively integrated into the base protocol. What is built here affects both the developers and end users on top.

What are the steps a protocol designer should take to have the most positive downstream effects on everyone else? And we will admit, these reflect our opinions, and there are arguments for and against each particular feature.

Features the Protocol Should Include

Features

• SPV Proofs / Light Clients: It is unlikely for all users of a protocol to interface with the blockchain using a full node, it is more common to use a hosted node service. They work well but represent a single point of failure, censorship and lack of privacy. Using SPV proofs or light clients, a user can validate and send transactions on his or her own without having to trust others. And if these light clients take very little resources, this gives more sovereignty to the user. Coda Protocol is the leader in this space.
• Account Based Modeling: Although there are many benefits to a UTXO model, account based modeling is more user friendly as there is only one canonical account which makes key management more straightforward. Users do not need to worry about optimal UTXO selection which has concerns of privacy, fees, dust, etc. Even better if one can register multiple key pairs to the account so if they lose one set, there are others available. Near protocol is currently working on this.
• Fork Friendliness: Some protocols believe that there should be no forks and have mechanisms built in to make it difficult to fork. People will always find a way to fork a protocol, therefore protocol designers should be cognizant of malicious actors / contentious hard forks and build in tools to both signal forks and prevent transaction replays.
• Hierarchical Deterministic Wallets: Also known as HD wallets, these allow one seed or mnemonic phrase to generate an infinite amount of public private keys. Therefore instead of a user having to store all their private keys, all they need to store is the seed.
• Consensus: The Fischer Lynch Paterson impossibility result (FLP) states that a deterministic asynchronous consensus system can have at most two of the following three properties: safety (results are valid and identical at all nodes), liveness (nodes that don’t fail always produce a result), and fault tolerance (the system can survive the failure of nodes at any point). No consensus mechanism can have all features, any distributed consensus system on the Internet must sacrifice one of these features. Therefore when choosing a consensus mechanism for a protocol, designers must determine what they value and how it affects user experience. Some inspiration from Stellar on their design decisions.
• Dust Handling: There exist coins that can no longer be used by the owner as the transaction fees are greater than the value of the UTXO. From a user standpoint this is not ideal because they have been deprived of their funds, if there was a clever way to not be in this situation it would be much appreciated.

Features For Network Maintainers

• Full Node Incentives: There should be a reason for users to run full nodes, whether they have to because the network is a permissioned or because there is a crypto economic incentive to do so. Without full nodes a network has lower security and less support. Incentives should cover the most important features of a protocol, in Bitcoin’s Nakamoto consensus only the miner who mines the block on the longest chain gets rewarded. But there is no incentive to propagate blocks, which has unfortunately leads to selfish mining. Perhaps an incentive to encourage relaying of blocks will fix this, but this represents the tip of the iceberg for incentives.
• Implementation Details: There are many ways to implement a specification for a protocol, developers must be careful to check for corner cases to prevent unintended attacks and unknown inflation.

In Protocol vs Extra Protocol Features

These are some features that also should be integrated into a blockchain protocol to increase its usability. However they can be implemented on several levels, should these be native to the protocol and potentially be part of consensus rules or should they exist on a smart contract layer or even off chain? Some protocols have taken a stance on this, but we will spare you from this debate and instead discuss why these particular features are empowering no matter what part of the stack they live in.

• Fee Delegation / meta transactions: For the end user, do they even need to know they are using a blockchain? Unless transactions fees are delegated to a third party, users forever will know that they are using a blockchain and have to acquire coins, which adds a layer of friction. Ethereum is working on smart contract based fee delegation (which has 2–3x gas costs compared to normal transactions and dApps specifically have to support it), whereas other protocols (Stellar and VeChain) have it natively. Nonetheless now users can use assets on top of a protocol without even knowing what’s powering it.
• Human readable addresses: Remember that time you typed an “O” instead of a “0” and burned a bunch of money? EOS has this natively (note it is mandatory and costs tokens to register, which detracts from usability), Ethereum uses ENS which is a smart contract. Now this won’t happen anymore. But we do understand that malicious people take advantage of renaming, look at Twitter last year with many scam accounts masquerading as Vitalik Buterin asking for ether.
• Native Multi-signature: It is paramount for a protocol to have one, either native or a smart contract. They can be implemented in scripts (BTC P2SH) or cryptographic threshold signatures. Try to can’t find a reason why a protocol should not have one.
• Gas Markets / Block Space Future: Transaction fees are a first price auction, which both in theory and practice tends to lead to imperfect pricing and games between participants. Several different models has been proposed to alleviate this, such as changing the auction type or introducing gas markets or futures for block space. And should these changes be part of the protocol or exist on the contract layer?
• Native Exchange: When features are implemented natively to the core protocol and consensus, they generally are more performant as the code is written as part of the client, rather than using a higher level smart contract language. Stellar has a native distributed exchange which make sense due to the asset nature of the protocol, but note this feature should not be implemented for non asset based protocols.

Complexity Shifting

There are some features that protocols inherently need, such as multi-signature (in my opinion, feel free to disagree). However which layer it lives in: base layer or smart contract layer or layer 2, along with the particular implementation greatly changes the user experience and shifts the complexity to different layers and parties. Is there a desire to make the base protocol extremely light weight? Or should it integrate everything? Can we assume that users are okay with an interactive protocol or should we assume that behaviour is undesirable? Is this a feature or a must have? These are some of the basic questions any protocol designer has to ask themselves, they must be cognizant that complexity will always exist. And who should be the ones who interface with the complexity, who should have the responsibility?

Balance between core developers and community

For legal de-risking, protocols cannot own the entire ecosystem. If the company developing the protocol runs nearly all nodes, develops all the ancillary components, etc it is hard to not say that the protocol is centralized. And that the company could be held liable for legal action.

Therefore it is essential for there to be outside development, but how to balance their contributions against the vision of the project? It is necessary for a project to have a concrete narrative to ensure that all developments by the community have a guiding light to follow. Then what about the security or trust, is it easier to trust a wallet by the company or by outsiders, what if one is open sourced and other not? These are not easy lines to walk.

Going Forward

Be cognizant of what the design goals of the protocol are when deciding on which usability features to implement per layer.

Special thanks to Kevin Britz (Totient Capital), Martina Long (Primitive Ventures), Dan Elitzer (IDEO CoLab) for their review and / or conversations.

Blockchain Usability Checklist was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.