Discover more from Bankless Publishing
The MEV Edition (part II) | DeFi Download
MEV after the Merge; Relay Ecosystem Analysis: Players and Economics; In-Protocol PBS and Inclusion Lists
Dear Bankless Nation 🏴,
We hope you’re doing well in these tough times. Centralized exchanges are security holes, and the last few days have highlighted that in a way web3 has not seen since Mt. Gox.
Still, there are also centralizing forces in DeFi that impact our us in unseen ways. In this edition of the DeFi Download, we dig into the current MEV landscape and breakdown how MEV-Boost works. Next, we dig into MEV relay ecosystem, relays’ economic viability, and tell you who is winning MEV.
After that, d0wnlore walks us through another security incident and the dangers of contaminating your production environment with test variables, but not before we give you the latest updates on the DeFi ecosystem’s project releases and hot Twitter takes.
If you want to focus on the technology and avoid the dangers of centralized finance, you won’t want to miss this edition of the DeFi Download!
The MEV Edition (Part II)
Author: Rook Team
The Dark Forest of MEV is a dangerous but lucrative space for some of the smartest minds in web3.
It has also remained, until recently, entirely unknown or incomprehensible to anyone not actively playing the MEV game. A niche within a niche industry.
But with Ethereum undergoing a foundational evolution from Proof-of-Work (PoW) to Proof-of-Stake (PoS), MEV has become more than just a buzzword; it is tied to the future health and success of the network.
Make no mistake, MEV still exists on Ethereum and, as the dust begins to settle post-Merge, the new landscape is starting to become more clear.
New challenges, new opportunities, and an existential threat to the future of Ethereum that continues to go relatively overlooked.
The Private Orderflow Problem
With Ethereum’s switch to Proof-of-Stake, a new player has emerged: the block builder.
Block builders scan through available orderflow, such as the public mempool, for transactions which they then sequence together to assemble the most profitable block, which is then proposed to validators.
Block building as a concept was explicitly put forth to preserve the decentralization of the network via proposer/builder separation (PBS).
By separating the block builder from the validator, it limits the possibility of centralization, but it doesn’t remove it entirely.
Block builders incentivize validators to settle their blocks with a percentage of the MEV they capture and that’s where the private orderflow problem rears its ugly head.
Imagine a single block builder has exclusive access to a protocol’s entire orderflow.
Instead of only using transactions from the public mempool, they can combine them with these private transactions to compile blocks that extract more MEV than other builders.
This gives them an anti-competitive edge and creates a centralizing flywheel; the more they win, the more they can win. This single block builder extracts more profits than anyone else, uses that profit to pay more to get validated, and soon enough they’ve centralized the network.
Another block builder may have a better algorithm, but they’re not getting the opportunity to settle the transaction. This lack of competition also inevitably forces other block builders out of business increasing a single builder’s dominance as well.
You might recall a similar flywheel discussed in the Flashboys paper about PoW Ethereum. It seems that PBS and PoS, while a step in the right direction, are not a cure-all.
Protocols and dApps with large volumes of transactions are now incentivized to monetize their users’ orderflow, but how can this be aligned in a way that protects the future of Ethereum?
One solution for democratizing MEV between block builders is an orderflow auction for each transaction.
Block builders and searchers — users who run complex algorithms to find opportunities to extract profits on-chain — can scan through private orderflow and create an auction on an individual transaction.
Once an auction is completed and a winner has been determined, the winning bidder has exclusive rights to settle the transaction within a specified number of blocks. If the transaction does not end up being validated, it could either be sent back for another auction or forwarded to the public mempool for general settlement.
The exciting part about these auctions are that each transaction settled through an auction now has a transparent, attributable value. And since the user is the one who is creating the value from these transactions, shouldn’t they be the ones to capture it?
The Future of MEV
It’s no longer all about danger and defense in the Dark Forest.
MEV protection is increasingly becoming the norm and, while users should still tread carefully, the real question is: how can they thrive?
A positive and sustainable redistribution of MEV to those who generate this value. That’s the future we want.
Author: Austin Foss
Within the last few months, the implementation of block proposer/builder separation (PBS) has been brought into the spotlight. This feature has long been in the works, evolving since 2018, but has largely been overshadowed by protocol upgrades like the proof of stake (PoS) merge, sharding, or even more exotic, danksharding.
Following the US sanctions of the Tornado Cash contracts in August, chatter about what could be done to alleviate pressure from this and possible nation state attacks against Ethereum became a hot topic. About one month later, Ethereum's merge and transition to PoS altered the MEV landscape significantly by making solo block proposers possible again without having to join a larger mining pool.
Since the merge two months ago, PBS has become one of the most discussed features of the Ethereum Protocol.
PBS Generally Speaking
By no means is PBS exclusive to Ethereum or PoS. Both PoS validators and PoW miners act by default as both the proposer and builder, but there is nothing in either pre- or post-merge Ethereum enforcing this. Pre-merge Ethereum had a partial implementation of this for miners developed by the Flashbots team called MEV-Geth, and post merge they released MEV-Boost for validators.
Why would a consensus layer entity—validator or miner—outsource their building responsibilities to a separate entity in the first place? By doing so, they give up their ability to have full control over the MEV in a block.
Part of the reason stems from user security.
In the last issue of the DeFi Download we looked at an instance where a user was targeted by an MEV bot that took advantage of a low-liquidity trading-pair, leaving the victim with only $500 of their original $1.85 million. If that user had submitted their transaction privately to a builder, similar bots wouldn't have the same opportunity because searcher's are disincentivized to act maliciously if they want users to drive more order flow towards themselves.
This accumulation of private order flow gives block builders an advantage in creating the most profitable blocks and increasing the likelihood of their blocks being included by the proposers. Thus rewarding the proposer for outsourcing their block building responsibilities—and MEV capabilities—for greater revenue.
In both cases, PoW or PoS, this introduces varied points of centralization and trust.
Under PoW the miners receive bundles of visible transactions from searchers in a secondary marketplace, restricted to trusted parties. This is because the builders that submit their partial blocks to proposers need to trust that their own transactions wouldn't be MEV'd or otherwise attacked, further centralizing the already competitive mining space around the trusted miners.
Post-merge Ethereum brought back the viability of solo proposers, since PoS lacks the barriers to entry present in PoW, because any validator not known to the builders could now be the next proposer to submit a block for inclusion.
To get around this, a commit-reveal mechanism has been implemented where a proposer must first commit to proposing the contents of a hidden block before the builder reveals the body of transactions for inclusion in the chain.
While this does address the aforementioned centralization of proposers by adapting to the new PoS consensus, PBS introduces another problem: how does the validator know it's committing to a valid block? This architecture reverses the direction of trust from the builders trusting the proposers they submit transaction bundles to validators trusting who they accept bids from.
In the last issue of the DeFi download we touched on the 'MEV supply chain', introducing the concepts 'searchers', 'builders', and relayers. Together, along with the public mempool and users who submit the transactions, they make up the 'builder market' we have today.
Validators use Flashbots' MEV-Boost to implement the builder-api and allow validators to receive bids from builders to have their blocks included. Then validators select the most profitable blocks—the ones with the highest bids—for inclusion.
Sitting between the builders and proposers acting as the trusted party, validating blocks bidding for inclusion, are the relays.
The MEV Relay Ecosystem
Author: Jake and Stake
The impact of MEV relays on the Ethereum ecosystem has been dramatic. If you’re not using MEV-Boost, you’re leaving money on the table, making MEV relays the de facto gate-keepers of Ethereum transactions. While the negative effects OFAC compliant relays are largely overblown…
…Relays have progressively centralized block production, increased block inclusion time, and threatened credible neutrality. All this without having a clear business model.
In the current MEV environment, blocks are generated, propagated throughout the network, and verified of its correctness before settling. With the increased profits from MEV, validators increasingly outsource the process of block generation to block builders and receive those blocks via MEV relays.
MEV relays are not part of the Ethereum protocol, but if you want to earn more income you’ll want to use MEV relays to extract it. The process begins when users and searchers send transactions to block builders. The block builders bundle these transactions to create the most valuable block they can and then send them to the relay.
Then the proposing validator requests “blinded blocks” from multiple MEV relays and selects the block with the highest bid. These “blinded blocks'' are block headers without transaction data.
The validator signs the blinded block, requests the corresponding transactions from the MEV relayer, and broadcasts the block to the network. These validator requests to 3rd party MEV relays have increased the number of network calls by 40%.
The Flashbots team worked very closely with the Ethereum foundation as its founders were researchers who saw the threat that MEV posed to blockchains. Since then, they’ve developed MEV-Geth and MEV-Boost to prevent the centralization of MEV searchers and validators.
Flashbots has relayed the largest percent of MEV-Boost blocks. ~80% at time of writing.
But since Tornado Cash addresses were sanctioned by the US Treasury department, Flashbots has taken a stance of OFAC compliance. Transactions that are sent to or from addresses sanctioned by OFAC will not be forwarded to validators (block proposers) by the Flashbots relay. Despite this, Flashbots still relays the large majority of blocks.
A month before the Merge, just before announcing OFAC compliance, Flashbots open sourced their relayer to increase competition in the relayer market. Flashbots also runs their own block builders to generate income.
BloXroute has been known to provide traders with information services. Traders that receive information quickly have an edge in capturing the next opportunity. Imagine a block contains information that will change the price of an asset. If the trader sees this information, they can quickly calculate how this information will change the spread between two liquidity pools.
BloXroute’s MEV relay is a response to changes in the Ethereum ecosystem, because validators are opting to use MEV-Boost. In order to better service searchers, bloXroute has created this relay to better service MEV searchers and traders.
BloXroute runs several relays, each with a different heuristic for transaction inclusion.
BloXroute Max Profit: Propagates all transactions/bundles
BloXroute Ethical: Propagates transactions/bundles excluding frontrunning transactions.
BloXroute Regulated: Propagates transactions/bundles excluding transactions to or from addresses sanctioned by OFAC.
BloXroute offers public relays located in London, Virginia, Beijing, Hangzhou, and Singapore, but MEV searchers can submit their transaction bundles to private relays if the public relay is too slow.
At the time of writing, block builders must be approved by bloXroute before they can submit blocks to the relay, so searchers have to buy bloXroute’s products (Enterprise-Elite or Professional) in order to submit bundles to bloXroute.
BloXroute provides data propagation services for Ethereum and Solana. Their BDN (Blockchain Distribution Network) disseminates updated information (transactions and blocks) from blockchains faster than the default P2P network.
Eden used to be ArcherDAO, which was a transaction ordering protocol that guaranteed transaction inclusion while protecting users from MEV attacks like front-running and sandwich attacks.
Eden is a permissioned system for block builders. They are accepting applications for block builders, but they also run their own. They capitalize on orderflow sent to their builder via their private RPC.
Anyone (but namely Searchers) can submit their bundles (set of transactions) directly to block builders via the Eden RPC. Calls include direct payments to block builders which are settled if their transaction is successful. If their transaction is not completed, their payment is not successful. This saves searchers from spending funds on gas if their transaction fails to be included.
Eden has their own token which was designed for PoW Ethereum. They’ve since pivoted to the relay services mentioned above, but they plan to add utility to the EDEN token after other technical milestones have been reached.
Blocknative provides one MEV relay, Dreamboat, that validators can connect to. This relay is open sourced and publicly available. Blocknative has APIs that allow developers and data analysts to identify proposer payloads, blocks received, and validator registration. Notably, Dreamboat is not a Flashbots Relay fork.
At the time of writing, Blocknative has a closed block builder ecosystem with the only builder being its own proprietary one, but they plan to support more builders in the future. Blocknative’s relay only supports OFAC compliant blocks.
Manifold has a focus on trade execution quality and end user settlement. They support blocks that are not OFAC compliant.
The Economics of MEV Relays
Relays can be seen as a platform serving a three-sided marketplace.
MEV searchers create bundles that they send to relays, and searchers simply want their transactions to be included as quickly as possible. Inclusion is most important to them.
These transactions are sent to block builders that gather these transactions and create profitable blocks. These entities want to create the most profitable blocks with the most profitable bundles, so variety of bundles to choose from is most important to them. Note that builder diversity is steadily increasing:
Finally, builders submit these blocks to block proposers (validators) who query different relays for the most profitable blocks. These entities are looking for maximum profit.
Relays have powerful network effects. Flashbots already submits 80% of all blocks using MEV-Boost, of which 88% of network participants use. It should be noted that Flashbots is also one of the few—if not only—permissionless relays.
If searchers want their transactions included, they’ll probably submit their bundles to the Flashbots relay. This leads to a greater variety of transactions, affording block builders the opportunity to assemble increasingly profitable blocks.
The more builders there are submitting blocks to a relayer, the more attractive that relayer is to block proposers. Further increasing the likelihood that the validator will choose the Flashbots relay.
Note: The median block reward is lower than the average. This suggests that some block rewards are outliers with much greater value than the rest. This implies that utilizing an MEV sharing mechanism will likely yield better returns than not.
Given these new numbers:
90% of blocks use MEV-Boost
80% of MEV-Boost blocks come from the Flashbots relay
the OFAC inclusion time looks a bit more grim compared to 1 month ago. The probabilities of a non-OFAC compliant transaction being included by the nth block are the following:
The result is that a sanctioned transaction will probably take 2 min to be included. While this may be acceptable to some, it’s still not ideal. These wait times are largely a result of Flashbots owning increasing market share and being OFAC complaint.
In order to do better than this, we have to increase relay diversity and make them permissionless—let anyone build blocks for them. We need more OFAC non-compliant relays in order to stave off censorship and promote credible neutrality.
Unfortunately, running relays by themselves is not profitable. Today, most (if not all) relays have zero fees for their services, and large majority of MEV profits go to validators—the real winners of MEV. But some MEV goes to searchers and builders, which is why relays also run a block builder in conjunction to earn income. Ones that don’t operate their relay infrastructure as a public good.
But Flashbots isn’t only winning relays. On top of 72% of blocks coming from the Flashbots relay, Flashbots’ builders continue to dominate the builder ecosystem as well.
I suspect the permissioned relays don’t want to open themselves up to Flashbots builders, who have already spent a lot of time refining their technique. If they open themselves up, Flashbots can swoop in and eat their lunch.
The incentive model is not great for relays and, subsequently, independent block builders. Relays run on private servers and are not profitable. They make money by relaying the blocks they create, so relaying a block they don’t create will hurt their bottom line. While we can pray that these relays act fairly, the fact of the matter is that we can’t know their behavior with certainty, reducing the trustlessness of the greater Ethereum ecosystem as a result.
Still, in-protocol PBS will eventually displace the need for private MEV relays. Relay runners are spending this time to optimize and improve their block building abilities for that inevitable future. If all goes according to the Ethereum roadmap, we’ll abandon relays altogether, so they won’t need to be profitable. Put plainly, maybe making relays profitable is like stitching repairs on a band-aid.
Author: Austin Foss
A possible path forward to further reduce or eliminate points of centralization is to integrate PBS directly within the protocol, eliminating the need for trusted relays. It integrates, or 'enshrines', two guarantees within Ethereum's protocol:
The chosen builder is guaranteed that the proposer has committed to the builder’s block; else the builder's MEV rewards can be exploited.
The proposer is guaranteed that the builder’s block is valid and will be revealed by the builder; else the validator can be slashed.
In-protocol PBS designs have gone through several iterations and continue to be discussed. At a presentation he gave in May of this year, Vitalik showed a diagram of how such an integration would look.
By no means is this a definitive specification for in-protocol PBS, this design being called “two-slot PBS”. In a report published by Delphi Digital the steps to produce a block using this method follow this path:
Builders commit to block headers along with their bids
Beacon block proposer chooses the winning header and bid. Proposer is paid the winning bid unconditionally, even if the builder fails to produce the body
Committee of attestors confirms the winning header
Builder reveals the winning body
Separate committees of attesters elect the winning body (or vote that it was absent if the winning builder withholds it)
MEV research is still ongoing and there is a chance PBS might not ever be integrated within the Ethereum protocol. Vitalik has however included PBS in his latest roadmap targeted for implementation in 'The Scourge'.
Under MEV-Boost’s current design, builders bid to have a whole block to be proposed by a validator, but this doesn't have to be the case. One reason we wouldn't want 100% of the block to be constructed by the builder is possible censorship. Under a partial block building PBS model, proposers can require some transactions to be included by the builder as a “prefix” or “suffix” to the rest of the transaction set.
PBS can get even more nuanced because of slot auctions. Slot auctions are a theoretical way for builders to bid on the right to a slot on the beacon chain behind the next slot in line, which is currently the only slot of relevance to the current design. Up until now we've discussed how builders must bid for block space. This opens up a separate set of possibilities, problems, and incentives.
Having a commit-reveal scheme protects the block builder from censorship—or other attacks—by the proposer, but what happens if the block proposer tries to censor or block transactions for any given reason? Formerly known as "Censorship Resistance (cr) Lists", inclusion lists give proposers a way to combat censorship from the builders by requiring the next block to contain a set of predefined transactions.
This poses a couple of problems:
Inclusion lists limit the freedom of a block builder to include or exclude any transaction they wish, harming their MEV potential profitability.
Inclusion lists allow validators to dictate the contents of a block, defeating the original purpose of PBS.
A possible way to compromise on those problems while still adding to Ethereum’s credible neutrality was proposed by a researcher at the Ethereum Foundation, Francesco, describing how this could be done using Inclusion Lists.
By instead of forcing a set of transactions to be included, validators preserve the proposer-builder separation by simply requiring a full block while strengthening the protocol's censorship resistance. If the builders continually fill their blocks to capacity, in an attempt to censor a transaction from the inclusion list, costs begin to rise exponentially because of EIP-1559’s effect on the base fee and gas market.
What is Ethereum's Concern?
With all of the above under consideration, and the evident complexity of implementing full in-protocol PBS, it should be asked: is making PBS as decentralized and trustless as possible even Ethereum's responsibility?
If the protocol, as it stands, gives consensus layer participants (validators) the option to outsource their block building responsibilities with the trade off of greater profits but more risk, is it not their choice to make and risk to take? If users want to avoid the public mempool by using private order flow channels in exchange for a less trustless process, is it the protocol's responsibility to manage that risk?
In a blog on PBS published by Barnabé Monnot, another researcher at the Ethereum Foundation for the Robust Incentives Group, framed this question as "Where do Ethereum's concerns stop?"
At the client level? Provide more ways for out-of-protocol markets to organise? E.g., proposer specifies inclusion list, block prefix... to mev-boost.
At the market structure? E.g., making sure [the] proposer is paid when things go south? PEPC is a proposal in that direction
At the allocation mechanism?
As long as it is more profitable for validators to outsource their block building responsibilities they will do so, but this may (or will) create "a new instance of the principal-agent problem". A type of problem where the incentives between an employer (the proposer) and the employee (the builder) are misaligned.
If this is truly an inevitability, perhaps it is right for Ethereum to enshrine fairness within the protocol; even if designing this system is not a simple solution.
🎧 Listen Evaluating the PBS Experiment: Early insights from MEV-Boost and the Builder Market | Jolene Dunne
Project Releases 🎉
Hand-picked project updates to understand the current state of the DeFi ecosystem
Sound.xyz launches Sound Market
Secondary Market for Music NFTs
No listing fees
Aggregates listings across OpenSea, LooksRare, and X2Y2
Multichain block explorer
Track bridge transfers across multiple chains
Google launches Blockchain Node Engine
Google-managed service for Ethereum node operators
Google will offer an RPC service to allow users to submit transactions, deploy smart contracts, or otherwise read/write blockchain data.
Allow easier node deployment, security improvements, and automated liveness features like monitoring and restarts.
Chirping Birds 🐤
🔥 and 🧊 tweets from across the DeFi ecosystem
Security Scares: The pGALA Whitehat Draining Operation
No, it’s not quite another bridge hack. Here we will summarize the pGALA incident, an ongoing affair that began with a compromised token contract, leading to a whitehat heist of the token’s main liquidity pool with unexpected results.
The catalyst was when pNetwork, a cross-chain asset protocol, noticed that the owner address of their pGALA proxy smart contract had changed. pGALA is a BEP20 version of the GalaGames’ GALA token. In fact, the smart contract ownership had changed hands over two months before the incident. This meant that the new, unauthorized owner could take further action with the contract, such as issuing an unlimited amount of pGALA tokens.
So how did this happen? pNetwork says it was a “misconfiguration at time of contract creation” in their post-mortem. SlowMist had discovered that the private key of the smart contract’s original owner account was exposed in a test file on GitHub. This “misconfiguration at time of contract creation” statement could have meant that the smart contract was incorrectly initialized with a test account—and its exposed private key—as the owner.
Note that the GALA token on Ethereum mainnet (which was used as collateral in pNetwork's bridge) and the bridge itself were safe, as emphasized by both pNetwork and GalaGames.
As the smart contract no longer belonged to pNetwork, it was now a time-bomb that necessitated an incident response. After contacting GalaGames—it should be noted that pGALA is a bridged token that was not created with GalaGames' involvement, according to their statement—a series of actions was proposed to eventually make pGALA token holders whole again with a fixed smart contract.
This revolved around four actions:
Pause swaps on pNetwork’s cross-chain bridge
Prevent exchanges from processing withdrawals and deposits of pGALA
Perform a whitehat drain of the main pGALA/BNB liquidity pool on PancakeSwap
Warn the public not to interact with the pool until a fixed version of pGALA was created
If done successfully, this would mitigate the real danger of the attacker should they choose to exploit the contract soon and receive GALA or other valuable tokens in exchange for their new, uncollateralized pGALA. The subsequent recovery plan includes returning the BNB drained from the pool to liquidity providers and making pGALA token holders whole with a fixed smart contract.
The (Whitehat) Heist
While GalaGames attempts to contact various exchanges that are trading GALA in an attempt to block any token transfers of pGALA through exchanges, pNetwork plans to execute the whitehat drain once they’ve heard back that all exchanges are halting withdrawals and deposits. If the exchanges did not follow through it could introduce unwanted arbitrage opportunities and an inflated supply of pGALA.
Unfortunately, not all exchanges had cooperated, which created an arbitrage opportunity between the dropping pGALA price and the price of GALA on exchanges, an opportunity that many users and bots took advantage of. This forced pNetwork to drain even more liquidity out of the growing pool. Despite a polite request on Twitter for users to stop swapping using the pool, this likely fell on deaf ears.
The whitehat draining eventually stopped due to not being as effective as planned. What had begun with a pool of about $400,000 in BNB swelled to over $4,000,000 by the time the operation stopped.
The Unexpected Results
Most exchanges that had been contacted by GalaGames to halt actions on GALA had followed suit. But pNetwork specifically mentioned Huobi for delaying in turning off withdrawals and deposits, which likely did not help with the growing liquidity on PancakeSwap.
A few days after the initial incident, Huobi accused pNetwork of performing a rugpull rather than acting in good faith. The main argument is that the operation did not need to move as fast as it did since the malicious owner of the contract had not taken action in over 2 months, making the operation seem suspect.
pNetwork condemned the accusation, citing that Huobi failed to follow-up on their request to halt deposits and withdrawals early enough. It could be argued that had Huobi acted sooner there would have been less liquidity drained out of the PancakeSwap pool. If the original $400,000 in BNB was drained, rather than the $4,000,000 it grew to, it would have looked more favorably as an incident response in good faith rather than a rug pull.
Developers should know that an incident like this could have been prevented had a clear separation of test and production credentials, and the proper handling of them, been established before contract deployment.
Author: Lucas Campbell
🛠 BANK Utility (BanklessDAO token)
With over 5,000 holders, BANK is one of the most widely held social tokens in crypto. So it bears asking, where are the best places to put our BANK to use? The five protocols below will allow you to deposit BANK in a liquidity pool and earn rewards. To get going, just click on the name, connect to the app, filter by BANK, and start earning passive income.
Balancer has two 80/20 liquidity pools, meaning that you are required to deposit 80% BANK and 20% ETH in the pool. There is one pool on Ethereum and another on Polygon. Once you’ve provided liquidity, you’ll receive LP tokens. Keep an eye out for opportunities to stake these LP tokens. There is nearly 500,000 USD in the two Balancer liquidity pools.
SushiSwap has a 50/50 BANK/ETH pool. As with Balancer, you will receive LP tokens, and while you can’t stake them on SushiSwap’s Onsen Farm yet, you may be able to in the future. Liquidity providers earn a .25% fee on all trades proportional to their pool share. The SushiSwap pool has a little over 100,000 USD in liquidity.
⏛ Rari Fuse Pool- Deprecated Soon
This will be deprecated soon. The Rari Fuse Pool allows you to borrow against your BANK or earn huge APY by providing assets like DAI to the pool. At present, all borrowing is paused for this pool. There is over 450,000 USD deposited in the Pool
The Uniswap V3 liquidity pool is 50/50 BANK/ETH, and provides a price oracle for the Rari Fuse Pool. By depositing in the Uniswap pool, you can earn fees and help enable borrowing on Rari. This pool currently has over 500,000 USD in liquidity.
You can also provide liquidity to the Arrakis Uniswap V3 pool. The ratio is about 2/1 BANK/ETH. This pool is new, and only has a bit more than $6,000 in liquidity. In the future, you may be able to stake your BANK/ETH LP tokens within the protocol to earn additional rewards.
Get Plugged In
Get a job in crypto! Do you like solving hard problems, care about building more efficient markets for everybody, and want to work at the frontier of decentralized finance? Rook is looking for full time contributors, with salaries ranging from $169,000-$722,000. There are positions ranging from engineering, recruiting, product marketing, copywriting, and design. Sound interesting? Sign up for our referral program and go full-time DAO.
DeFi Research Lead (Fully remote)
DeFi Bot Wrangler (Fully remote)
Blockchain Economist (Fully remote)
Head of Research (Fully remote)