Author: 0XNATALIE, Source: Author's blog
"On block-space distribution mechanisms" co-authored by Ethereum researcher Mike and a16z researchers Pranav Garimidi and Tim Roughgarden systematically explores how the block space allocation mechanism affects MEV. First, the necessity of introducing an in-protocol mechanism to handle block space allocation is explained. Then, the existing allocation schemes are evaluated and compared through the framework of "Who, What, When, Where, How" (W^4H), and further in-depth analysis is made on how the execution ticket model can strike a balance between improving MEV perception and allocation fairness. The following is the translation of the article.
TL;DR: Block space, that is, the capacity contained in transactions, is the main resource derived from blockchains. As the crypto ecosystem expands and specializes, the value generated by the efficient use of block space (MEV) plays an important role in the economics of permissionless consensus mechanisms. The research community has written a lot of articles to explore how protocols should deal with MEV (see Related Work). The discussion over the past few years resembles the storyline of the blind men and the elephant, with many different viewpoints, solutions, and theories proposed, but each angle seems fragmented and difficult to compare. The first half of this article aims to present a macro picture of the "MEV elephant" by distilling a series of core issues and exploring how existing proposals address these issues. The second half focuses on the allocation mechanism enabled by the execution ticket, demonstrating an important new insight - there is a trade-off between the quality of the in-protocol MEV oracle and the fairness of the mechanism.
Article Organization: Section 1 explains why an in-protocol mechanism is needed to handle block space allocation as part of the Proof-of-Stake "endgame". Section 2 lists five dimensions that can be used to measure the block space allocation mechanism, using a familiar set of questions: who, what, when, where, how (abbreviated as the W^4H problem). Section 3 explores how block builders are selected, focusing on the execution ticket model. Section 4 opens the discussion by summarizing and raising follow-up open questions.
Notes: This is a long article with some technical elements. We encourage readers to focus on the sections of the article that interest them most. Sections 1, 2, and 4 provide a broad view of existing proposals and our proposed analysis. Section 3 (~44% of the article, but 100% of the math) provides a detailed analysis of the allocation mechanism enabled by the execution ticket design. This section can be read in sequence, as a standalone, or skipped entirely - it's up to you!
Before diving into this complex topic, let's briefly explain the need for a block space allocation mechanism. In Proof-of-Stake, validators are tasked with generating and voting on blocks. The picture below is from Barnabé’s article More pictures about proposers and builders, which describes these as proposing and attesting rights.
The block space allocation mechanism is the process by which the protocol determines the owner of the "proposal" or "block construction" rights. Proof-of-Stake protocols typically use one of the following rules:
Blockspace (Proposal) Rights – A validator is randomly selected as a leader and allowed to create the next block.
Voting (Witness) Rights – All validators vote on the block they believe to be the canonical head within a certain time window.
Validators are rewarded for performing these tasks. We categorize rewards based on where they come from, either as consensus layer (protocol issuance, e.g., newly minted ETH) or execution layer (transaction fees and MEV):
Consensus layer
a. Attestation rewards – (see attestation deltas).
b. Block Reward – (see get_proposer_reward).
Execution Layer
a. Transaction Fees – (see gas tracker).
b. MEV (Transaction Ordering) – (see mevboost.pics).
Rewards 1a, 1b, and 2a are well known and “within the protocol’s view”. MEV rewards are more challenging because fully capturing the value realized through transaction ordering is difficult. Unlike other rewards, the amount of MEV in a block is effectively unknowable (as a permissionless and anonymous system, it is impossible to track the controller of each account and any off-chain activity that may be profitable in conjunction with it). MEV can also change wildly over time (e.g., due to price fluctuations), resulting in greater variance in execution layer rewards than consensus layer rewards. Additionally, the Ethereum protocol has no insight into the MEV generated and extracted by its transactions at implementation time. To increase the protocol's visibility into MEV, many mechanisms attempt to estimate the MEV in a given block, which we call MEV oracles. Block space allocation mechanisms are often capable of producing such oracles, making the protocol "MEV-aware."
This raises the question, why should protocols care about MEV-awareness? One answer is that MEV-awareness may increase the protocol's ability to maintain reward parity when validators have different levels of sophistication. For example, if the protocol is able to accurately burn all MEV, then validators' incentives will be completely within the protocol's view (as in 1a, 1b, and 2a above). Alternatively, a mechanism that shares all MEV among validators regardless of validator complexity (e.g., mev-smoothing) would seem to promote a larger, more diverse, and decentralized validator set while maintaining MEV rewards as an additional staking incentive. Without MEV awareness, validators that are best able to extract or smooth MEV (e.g., due to relationships with block builders, proprietary algorithms/software, access to exclusive order flow, and economies of scale) could receive disproportionately high rewards and exert significant centralization pressure on the protocol.
The Ethereum protocol design strives to maintain a decentralized validator set at all costs. It should go without saying, but for completeness: The protocol's credibly neutral, censorship-resistant, and permissionless nature directly depends on a decentralized validator set.
In Ethereum today, mev-boost accounts for about 90% of blocks. With mev-boost, proposers (randomly chosen validator leaders) sell their block construction rights to the highest bidder through an auction. The diagram below shows this flow (we excluded relays because they are effectively extensions of the builder).
Proposers are incentivized to outsource their block construction because builders (agents that specialize in ordering transactions to extract MEV) pay them more than they could earn by building blocks themselves. Coming back to our goal of keeping validator rewards equal in the presence of MEV, we see that mev-boost allows all validators to enter the builder market, effectively keeping MEV rewards close to parity between independent stakers and professional staking service providers — great! But… Of course, there are some issues with mev-boost that still bother some members of the Ethereum community. In short, here are some of the negative side effects of taking the mev-boost drug: Relays – These trusted third parties broker block sales between proposers and builders. The heavy reliance on relays increases the overall fragility of the protocol, as demonstrated by duplication, incidents, involvements, relays. Additionally, since relays have no inherent revenue stream, more (and closed-source) methods of capturing profits are being implemented (e.g., timing games as a service and bid adjustments).
Extra-protocol software is fragile – In addition to relays, participating in the mev-boost market requires validators to run additional software. The standard suite for standalone staking now involves running four binaries: (i) a consensus beacon node, (ii) a consensus validator client, (iii) an execution client, and (iv) mev-boost. Not only does this add significant overhead for independent stakers, relying on this software also provides another potential point of failure during a hard fork. See the Shapella incident and the Dencun upgrade for examples of the complications caused by more extra-protocol software.
Builder Centralization and Censorship – While this was probably inevitable, the mass adoption of mev-boost has accelerated the centralization of builders. Three builders account for approximately 95% of mev-boost blocks (85% of all Ethereum blocks). mev-boost implements an open outcry, first-price, winner-takes-all auction, leading to high levels of builder centralization and strategic bidding. inclusion lists or other censorship resistance tools have not yet been implemented, and builders have a large influence on the inclusion and exclusion of transactions - (see censorship.pics).
Timing Games – While timing games are considered a fundamental problem in Proof-of-Stake protocols, mev-boost pushes staking service providers to compete on thin margins. Furthermore, relayers (which conduct mev-boost auctions on behalf of proposers) act as complex middlemen that facilitate timing games. Thus, we see marketing that encourages higher yields by staking with a specific provider.
After the necessary “setting the stage”, let’s take a closer look at the nature of the block space allocation mechanism.
Consider the game of acquiring blockspace; MEV incentivizes agents to participate, while a combination of in-protocol and out-of-protocol software defines the rules. What elements should be considered when designing this game? To answer this question, we use the familiar rhetorical pattern of “who, what, when, where, how” (hopefully Section 1 answered the “why” enough), which we call the W^4H question.
Who controls the outcome of the game?
What is the commodity that players fight over?
When does the game take place?
Where here do the MEV oracles come from?
How are block builders selected?
These questions may seem overly simplistic, but when considered individually, each can be seen as an axis to measure the space of mechanism designs. To demonstrate this, we highlight some different varieties of block space allocation mechanisms that have been explored in the past. While they may seem unrelated, their relationship becomes clear by understanding how they answer the W^4H question.
< bb25d978-9246-4898-999b-182d5d5de458_328x500.jpeg","srcnowatermark":null,"fullscreen":null,"imagesize":null,"height":500,"width":328,"resizewidth":null,"bytes":null,"alt":"upload_23e73e8aae1d7223973af83053d41ebc","title":null,"type":null,"href":null,"belowthefold":true,"topimage":false,"internalredirect":null}"="" class="sizing-normal" alt="upload_23e73e8aae1d7223973af83053d41ebc" title="upload_23e73e8aae1d7223973af83053d41ebc" srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbb25d978-9246-4898-999b-182d5d5de458_328x500.jpeg 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbb25d978-9246-4898-999b-182d5d5de458_328x500.jpeg 848w, We present an outline of a number of different proposed mechanisms. Note that this is only a subset of the rather large literature around these designs — (see infinite buffet). For each of the following, we only summarize the key ideas (see Related Work for details).
Execution Tickets
Key Idea: Block construction and proposal rights are sold directly through "tickets" issued by the protocol. Ticket holders are randomly sampled as block builders, with advance notice. Ticket holders are entitled to produce blocks during an allotted time period.
Block Auction PBS (Proposer-Builder Separation)
Key idea: The protocol grants block production rights through a random leader election process. Selected validators can sell their blocks directly to the builder market or build them locally. Builders must commit to specific blocks in an auction. mev-boost is an out-of-protocol instantiation of block auction PBS; ePBS is the in-protocol equivalent, as originally proposed.
MEV Burning / MEV Smoothing
Key idea: A committee is responsible for setting a floor on the bid chosen by the proposer in the auction. By requiring the proposer to choose a "large enough" bid, a MEV oracle is created. MEV is either smoothed among committee members or burned (smoothed to all ETH holders).
Slot Auction PBS
Key idea: Similar to block auction PBS, but instead of selling slots to builders, the market does not require them to commit to specific blocks - sometimes called block space futures. By not requiring builders to commit to specific blocks, future slots can be auctioned in advance, rather than waiting for the slot itself.
Partial Block Auctions
Key idea: Allows for more flexible units of block space to be sold. Instead of selling entire blocks or slots, allow proposers to sell a portion of their block, e.g. the top of the block (most valuable to arbitrageurs), while keeping the rest of the block for construction. Runs in other Proof-of-Stake networks, such as Jito's block engine and Skip's MEV lane.
APS Burning is Execution Auction
Key idea: New proposal from Barnabé forces proposers to auction block construction and proposal rights in advance. Slots are sold in advance (fixed time), without committing to a specific block; committees (like MEV burning/smoothing) ensure that bids are large enough.
By comparing these proposals’ answers to the W^4H problem, we can see that they are different pieces of the same design space.
For each W^4H problem, we describe the different trade-offs in the above proposals. For the sake of brevity, we will not analyze each problem against each proposal, but instead focus on highlighting the key differences brought by each problem line.
Who controls the outcome of the game?
In the execution ticket mechanism, the protocol determines the winner of the game by randomly selecting the ticket holder.
In the block auction PBS, the proposer (the leader selected by the protocol) unilaterally selects the winner of the game.
In the MEV burning mechanism, the proposer still chooses the winner, but the winning bid is constrained by the committee, reducing the proposer's autonomy.
What is being competed for?
In block auction PBS, entire blocks are sold, but bids must commit to block contents.
In slot auction PBS, entire blocks are sold, but no commitment to specific block contents is required.
In partial block PBS, a portion of a block is sold.
When does the game take place?
In block auction PBS, auctions take place during slots.
In slot auction PBS, auctions can take place many slots (e.g., 32) in advance, since there are no commitments to block contents.
In an execution ticket mechanism, tickets are assigned to slots with a fixed lead time.
Where does the MEV oracle come from?
In the MEV burn/smoothing mechanism, the committee enforces that the selected bid is large enough, and this bid is the oracle.
In the execution ticket mechanism, the total cost of the ticket serves as the oracle.
How are block builders selected?
In the block auction PBS, any outsourced block production is a winner-takes-all allocation, and the highest bidder gets the right to build the block.
In the execution ticket mechanism, many different allocation mechanisms can be implemented. For example, in the original proposal, tickets were chosen randomly and the mechanism was “proportional to the number of tickets”; in this case, the highest bidder (the one holding the most tickets) simply had the highest probability of being selected, but was not guaranteed to get the right to build a block.
If the above seems cryptic, don’t worry. The following sections will dive deeper into these different allocation mechanisms.
Before moving on, let’s recap our original motivations:
The block space allocation mechanism is designed to keep validator rewards homogeneous in the presence of MEV.
This is a great foundation, but if that’s our only goal, why not just continue with mev-boost? Keep in mind that mev-boost has some negative side effects that we may need to design our final protocol to be resistant to. We highlight four other potential design goals for blockspace allocation mechanisms:
Encourage broader competition among builders.
Allow trusted interactions between validators and builders.
Incorporate MEV awareness into base-layer protocols.
Remove MEV from validator rewards entirely.
Note that while (1, 2, 3) are relatively uncontroversial, (4) is more controversial (and requires (3) as a prerequisite). Protocols may want to ensure that consensus layer rewards (the part controlled by the protocol) more accurately reflect the incentives of the entire system by eliminating MEV rewards. This also gets into the question of staking macroeconomics and protocol issuance—a more political discussion. On the other hand, MEV rewards are a byproduct of network usage; MEV can be viewed as a value capture mechanism for the native token. We do not attempt to resolve these issues here, but rather explore how different answers affect mechanism design.
What can we do at the protocol design level to meet these expectations? As mentioned above, there are many trade-offs to consider, but in the following section we will explore "How are block builders selected?" to improve on some of these aspects.
Editor's Note: As mentioned before, this section is longer and more technical than the others - if you have limited time (or interest), feel free to skip to Section 4.
Section Objectives: Show the quantitative trade-offs between MEV oracle quality and mechanism fairness between the two most familiar methods of allocating block proposal rights (which we call "Proportional-all-pay" and "Winner-take-all").
We intend to achieve this goal through the following subsections:
Before diving into the possible allocation mechanisms implemented by execution tickets, we must first establish the model. Consider a protocol where the rules for selling execution tickets are as follows:
The price is fixed at 1 WEI, and
An unlimited amount of tickets can be bought and sold.
Note: This version of execution tickets effectively creates two separate staking mechanisms - one for attestation, and one for proposals. Small changes in design, such as not allowing tickets to be resold to the protocol, could have huge impacts on market operation, but this is not the focus of this article. We are narrowly exploring the problem of block space allocation in the presence of a pre-existing set of ticket holders.
It is worth noting that from the perspective of the protocol, block producers and attesters are separate individuals - individuals must choose which part of the protocol to participate in, by deciding whether to stake or buy tickets. The secondary note market could develop into a venue where structuring rights are sold in a timely manner in the auction market (much as mev-boost does today).
Alternatively, builders may choose to interact with the protocol directly and purchase execution tickets, but their capital may be better suited as active liquidity, capturing arbitrage between trading venues. Therefore, they may prefer to purchase block space at auction on the secondary market.
Why are we limited to this mechanism of publishing prices with an infinite supply? Two reasons:
It’s not clear that a complex market can be implemented at the consensus layer. Client optimizations make it possible for any validator with consumer-grade hardware to participate in the network. This requirement may be incompatible with fast auctions, bonding curves, or other possible ticket sale mechanisms. Questions about the number of tickets sold, the MEV included in the on-chain ticket sale (meta-MEV?!), and the timing (and timing games) of ticket sales seem closer to the concerns of the execution layer than to what Ethereum consensus can reasonably implement while keeping hardware requirements limited.
“It is conceivable that the inclusion of ET market-related transactions could trigger MEV, regardless of whether these transactions are included in the beacon block or the execution payload.” - Barnabé said in More pictures about proposers and builders.
Even if (a big assumption) the protocol is able to implement a more rigorous market for ticket sales, the design space for that mechanism is enormous. Many potential pricing mechanisms have been discussed, e.g., bonding curves, 1559-style dynamic pricing, auctions, etc.; making general statements about these is beyond the scope of this article.
Therefore, we focus on the "unlimited, 1 WEI fixed price" version of exercise tickets, where the protocol internalizes the least complexity. With this framework, we can ask a question that may be burning you, "Given a set of exercise ticket holders, how do you choose the winner?"... Sounds simple, right? It turns out that there is a lot to say about even such a seemingly simple question; let's explore a few different options.
x:b→[0,1]n ∑ixi(b)=1 p:b→Rn≥0
Consider a repeated game of obtaining MEV rewards by purchasing execution tickets:
Each cycle, each player submits a bid, indicating the number of tickets they purchased. The bids are represented by the vector b , where bi is the bid of the i-th player.
Each player has a valuation for winning the right to produce a block. The valuations are represented by the vector v, where vi is the valuation of the i-th player.
Each time step, an allocation mechanism determines the allocation of each player based on the bid vector. Assuming bidders are risk-neutral, we can equivalently say that each of them is assigned a "portion of the block", which can also be interpreted as "the probability of winning a certain block". In a game with n players, denote by x:b →[0,1]^n the mapping that implements the allocation mechanism, where xi(b) is the allocation to the ith player, subject to the constraint that ∑ixi(b)=1 (i.e. the mechanism fully allocates).
Each player's payment is collected at each round. Denote by p:b →Rn≥0 the payment rule determined from the set of bids, where pi(b) is the payment to the ith player.
Each player's game utility function is defined as Ui(b)= vi xi(b) - pi(b), i.e., a player's utility is equal to the value of the block they won times the portion they won minus the amount they paid
Consider two (completely different) possible mechanisms.
Proportional Full Payment (a slight modification of the original execution ticket proposal)
During each round, all players submit bids. The bids are represented by the vector b.
The probability of a bid winning the game is the bid value divided by the sum of all bid values
b) = bi.
Winner Takes All (Current PBS Implementation)
During each round, all players submit bids. Use the vector b to represent the bids.
The highest bidder wins the game, so x_i(b) = 1 if max(b) = bi and xi(b) = 0 (e.g., in case of a tie, preference is given to the player with the lower bid).
Only the winning player pays his bid, so pi(b) = bi if max(b) = bi and pi(b) = 0 (same treatment for ties).
To demonstrate the different outcomes of the two mechanisms, consider a game with two players, where Player 1 has valuation v1 = 4 and Player 2 has valuation v2 = 2 (we consider a perfect information setting where individual valuations are common sense).
Proportional Full Payment Result:
Equilibrium bids: b1 = 8/9, b2 = 4/9
Equilibrium splits: x1 = 2/3, x2 = 1/3
Equilibrium payments: p1 = 8/9, p2 = 4/9
This feels intuitively correct; when v1 = 2·v2 (Player 1 values the block twice as much as Player 2), Player 1 bids, receives, and pays twice as much as Player 2.
Winner-take-all outcome:
Equilibrium bid: b1 = 2+ϵ, b2 = 2
Equilibrium allocation: x1 = 1, x2 = 0
Equilibrium payoff: p1 = 2+ϵ, p2 = 0
This is quite different. Player 1's bid just exceeds Player 2's value (we'll use ϵ to represent a small amount), and receives the full allocation. Player 2 gets nothing and pays nothing.
Now consider the “revenue” (or sum of bids) collected by the mechanism in each case:
Proportional all-in revenue: b1 + b2 = 4/3
Winner-take-all revenue: b1 = 2+ϵ
Winner-take-all revenue is higher, equating to a more accurate MEV oracle (and thus more MEV burned or smoothed by the protocol) than Proportional all-in. Intuitively, by allocating block production rights to lower-value players (as Proportional all-in does), we give up revenue that we would have received if the entire right had been allocated to the highest-value player. For a more complete treatment, see Appendix 1.
Another factor to consider is the “fairness” or “distribution” of the allocation mechanism. For example, suppose we agree on the following metric: √x1⋅x2 (we use the geometric mean because it is maximal when x1 = x2 if the sum of x1 + x2 is fixed, and is zero if either x1 or x2 is zero). Now, let’s look at the fairness results for the two candidate mechanisms:
Proportional Full Payout Fairness: √1/3⋅2/3≈0.471
Winner Takes All Fairness: √1⋅0=0
Here, the “performance” of the two mechanisms is flipped — winner-takes-all is not as fair as proportional full payout, because “Player 2” does not receive any allocation. This demonstrates the quantitative tradeoff between the quality of the MEV oracle and the fairness of the mechanism when allocating block proposal rights.
This small example reveals a key conclusion: there is a fundamental tradeoff between the quality and fairness of the MEV oracle. The Proportional Full Payment mechanism (aka the original Execution Ticket proposal) is fairer because both players have some probability of winning the game, which encourages each player (especially high-value players) to adjust their bids accordingly, which reduces the mechanism's revenue and the accuracy of the MEV oracle. The First Price mechanism induces higher bids because bidders only pay if they win the entire block production right, which increases revenue, but this winner-take-all dynamic makes the distribution unfair.
Open Question: Is the Proportional Full Payment mechanism the "best" Sybil-resistant mechanism? In the permissionless setting, we only consider Sybil-resistant mechanisms, i.e., players do not benefit by splitting their bids into multiple identities. We believe that the Proportional Full Payment mechanism is in the ideal range of Sybil-resistant mechanisms, performing well in terms of both revenue/MEV oracle accuracy and fairness. We leave it as an interesting open question to determine the degree of "optimality" of the Proportional Full Payment mechanism (e.g., we fail to find another Sybil-resistant mechanism that outperforms it in both revenue and fairness).
(Notes #1 and #2 related to the specific calculations can be found in the original text)
Let us summarize what we have learned. Section 3 demonstrated the fundamental trade-off between MEV oracle accuracy and fairness in the context of the execution ticket mechanism. A protocol may be willing to pay for more allocation and entropy (in the form of reduced revenue) to improve and maintain the protocol's credible neutrality. Moreover, using the model to derive equilibrium bids helps us understand how agents might react when faced with various allocation and payment rules.
Further questions (returning to our three W^4 questions):
What are the players competing for? Can we extend the model dimensionality to allow different players to place different values on different parts of the block (e.g., arbitrageurs may place particular value on the top of the block, but place no value on the rest)?
When is the game played? How does the accuracy of MEV oracles change if the game is played far in advance rather than during the slot (e.g., pricing future expected MEV vs. currently achievable MEV)?
How are block builders selected? Is there a Sybil-resistant mechanism that outperforms pro rata full payouts in terms of both revenue and fairness? Can we more formally characterize the fundamental tradeoff between revenue and fairness? Given the Sybil-resistant constraint, what alternative allocation and payout rules should be explored (e.g., the Tulloch tournament, where the allocation rule is determined by a parameter α>1, as i=bi^α/∑jbj^α), and can we identify the optimal choice?
Returning to the broader perspective, other versions of the W^4H problem may require different models to reason about.
Who controls the outcome of the game? What kind of collusive behavior might emerge in a committee-enforced version of the mechanism? If instant block auctions continue to take place outside the protocol, should we explicitly characterize a secondary market?
When do games take place? How critical is network latency when considering early vs. same-slot sales of block space? Is it worth modeling a partially synchronous environment? If multi-slot MEV is feasible, how does the valuation of block builders change?
Where do MEV oracles come from? If from a committee, do committee members have incentives to behave dishonestly? Do these incentives depend on whether MEV captured by the protocol is burned or smoothed?
As always, there are many open questions, but we hope that (a) the W^4H problem helps expand our understanding of block space allocation mechanisms, and (b) a deeper exploration of allocation mechanisms helps us understand the potential design space for execution tickets.
Ilya Sutskever, co-founder of OpenAI, left amidst disagreements over AI safety priorities, leading to the founding of Safe Superintelligence Inc. (SSI) in June 2024, focusing on developing safe superintelligence with a streamlined approach and a select team.
Anais
AlexPixelverse's PixelTap game integrates a tap-to-earn model on Telegram, recently adding TON blockchain support for in-game transactions and $PIXFI token interactions, aiming to enhance player engagement and value creation within its cyberpunk universe. With rapid user growth, community events like Pixelfest, and substantial backing from investors, Pixelverse is positioned to expand as a prominent player in blockchain-based gaming and entertainment.
WeatherlyEthena made history with its USDe surpassing $3B just four months after launch. Its Sats campaign will continue until 2 September or until USDe supply reaches $5B. However, the ENA token has declined over 50% in the past month. Will Ethena's USDe follow the path of other high-profile stablecoin collapses?
CatherineQED Protocol, backed by $9 million in funding, enhances Bitcoin with scalable smart contracts using zero-knowledge proofs, aiming for faster transactions and broad Web3 application support. Led by Carter Feldman, QED aims to revolutionize Bitcoin's capabilities, potentially making it a cornerstone of the next-gen internet.
WeatherlySoccer legend Lionel Messi is allegedly promoting Solana-based WaterCoin (WATER). However, as meme coin mania grows, celebrities endorsing these assets on Solana might be violating securities laws, attracting SEC scrutiny.
KikyoThe race for a Solana ETF heats up with BlackRock reportedly considering joining VanEck and 21Shares in filing, signaling increased institutional interest. The SEC's decision, influenced by the upcoming U.S. election, could determine the ETF's fate by mid-March 2025.
AnaisNeon is a fully compatible EVM enabling developers to use Ethereum tools on Solana's high-speed, cost-efficient blockchain. The introduction of RollApps has seemingly boosted the value of the Neon token.
CatherineYuliverse is a pioneering gaming metaverse on Binance Smart Chain, blending social interaction with play-to-earn mechanics through $ART tokens, set for a major listing. Its innovative features, like the Moon Ring, aim to enhance player engagement and wellness.
WeatherlySolana-based Water Coin surged nearly 40% after Ronaldinho promoted it on Instagram, following Lionel Messi’s earlier endorsement. Industry critics warn a potential pump-and-dump may be on the horizon.
Kikyo
< 755eb34c-0f91-416c-adf5-28ef74f84b52_718x1420.png","srcnowatermark":null,"fullscreen":null,"imagesize":null,"height":1420,"width":718,"resizewidth":262,"bytes":65796,"alt":null,"title":null,"type":"image="" png","href":null,"belowthefold":true,"topimage":false,"internalredirect":null}"="" class="sizing-normal" alt="" srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F755eb34c-0f91-416c-adf5-28ef74f84b52_718x1420.png 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F755eb34c-0f91-416c-adf5-28ef74f84b52_718x1420.png 848w, https://substackcdn.com/image/fetch/w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F755eb34c-0f91-416c-adf5-28ef74f84b52_718x1420.png 1272w, https://img.jinse.cn/7241166_watermarknone.png 1456w" sizes="100vw" loading="lazy">
< alt="upload_cdbf47258422c2a96ea2903ce113a113" class="sizing-normal" alt="upload_cdbf47258422c2a96ea2903ce113a113" title="upload_cdbf47258422c2a96ea2903ce113a113" srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7f1ca08a-f1eb-4b96-acdf-a17adac0e5c6_552x367.jpeg 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7f1ca08a-f1eb-4b96-acdf-a17adac0e5c6_552x367.jpeg 848w, https://substackcdn.com/image/fetch/w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7f1ca08a-f1eb-4b96-acdf-a17adac0e5c6_552x367.jpeg 1272w, https://img.jinse.cn/7241167_watermarknone.png 1456w" sizes="100vw" loading="lazy">
< alt="upload_a24cdf5b513fb4e410700573687adcd6" class="sizing-normal" alt="upload_a24cdf5b513fb4e410700573687adcd6" title="upload_a24cdf5b513fb4e410700573687adcd6" srcset="https://substackcdn.com/image/fetch/w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd75e1ffe-34d7-4b6b-ae12-693de5049784_690x493.jpeg 424w, https://substackcdn.com/image/fetch/w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd75e1ffe-34d7-4b6b-ae12-693de5049784_690x493.jpeg 848w, https://substackcdn.com/image/fetch/w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd75e1ffe-34d7-4b6b-ae12-693de5049784_690x493.jpeg 1272w, https://img.jinse.cn/7241171_watermarknone.png 1456w" sizes="100vw" loading="lazy">