Over 200 subscribers
Collect this post as an NFT.
This edition of the newsletter dives into a relatively new topic called preconfirmations, exploring what they are and their market potential. We'll also share some interesting articles, portfolio updates and market highlights.
Special thanks to YY, Melvin, Adna, Nikos, Keith and Ash for their help.
Please do enjoy reading,
Ash
a) Journey towards sustainable yield farming
• Many protocols use centralized elements for sustainable revenue generation and liquidity acquisition, such as the RWA model and basis trading model.
• Considering that the RWA model and basis trading model are still in their early stages of introduction, their influence in the DeFi ecosystem is expected to grow further in the future.
DeSpread Research · Meet our people's insight, our capabilities, our research, and the ever-changing face of our firm.
b) Keeping up with the GenZs
• Behaviour shifts matter because they collide with technology shifts to form the largest startup opportunities.
• Major sectors affected by changing generational behaviours include era of self-expression, social, finance (investing), health and sustainability.
The Defining Characteristics of the New Generation
c) Distributed validator technology (DVT)
• DVT aims to reduce entry barriers for solo staking and improve the current validator setup.
• This is key for Ethereum’s evolution towards decentralization, security, and accessibility in validator operations.
In this article, we'll dive into the proposals for improving Ethereum's PoS, as outlined in Vitalik's roadmap.
d) EVIntent - Darkmatter in MEV
• Bots can not just only target transactions – but predict them and exploit users' trades (current MEV protection solutions only hide your signed transaction from the bots – but, not your intent to trade).
• No fix yet for now, users can only make themselves a smaller target with random actions and smaller trades, hoping that the risk outweighs the payoff and a bot won’t target them.
MEV bots predict your trade
e) Pointenomics 101: Mastering the new language of crypto incentives
• With each new point program, projects push the incentive design space a little further, uncovering new reward mechanics and behaviors to incentivize.
• The key to success will lie in balancing transparency with flexibility, and in aligning point programs closely with overall project goals and user needs.
Many thanks to Haseeb & Tom from Dragonfly, Jai from Royco, DQ from Definitive, Peter from Nascent, Hemanth/Jeff from Goldsky, Derek from Variant, Chudnov from 3Jane, BlockEnthusiast, Kirk of Credit Guild, Steven Becker from UDHC, and others for their generous comments, and discussions that contributed to this post.
f) People not decks
• Pitch decks are about signal. There are multiple ways founders can build that signal which includes telling a compelling story and reshuffling the pitch deck when needed.
• In an attention-deficit world, grabbing attention is half the job. How one chooses to go about doing it is up to the founder.
Set that pitch on fire. 🔥
a) Gasp
• Gasp is a L2 on Ethereum that provides a trustless (Eigenlayer security), gas-free transactions, MEV-protected, lightning-fast and cross-rollup (cross-chain liquidity pools and vaults) protocol.
• On Gasp, users and AMM users are part of a single, combined product instead of one product deployed atop another product, each with its own business model. In this way, Gasp can offer gas-free transactions to its users.
With Gasp, a cross-rollup protocol designed for exchanging cryptocurrencies between blockchains (including L2s), we are launching a cross-chain communication platform that can scale with large amounts of capital and high-speed trading for enterprise and individual retail users alike. This blog post is a deep dive into Gasp's gas-free, secure,
b) 0xPass
• 0xPass's passport protocol's distributed + MPC mainnet is now live
• It offers programmability (customize auth logic), seedless (no recovery/device shares), fast (~1s avg performance) and distributed + secure (non-custodial and secured by enclaves + MPC).
Customizable authentication and recovery policies
Programmable transactions
Introduction
Preconfirmations often go overlooked in daily life. For instance, fulfillers of online orders such as Amazon have to perform sophisticated inventory checks in order to provide a 'preconfirmation' for an item’s date of delivery.
In the context of blockchain transactions, preconfirmations are essentially early indications that a transaction will be included in a block, providing users with faster feedback on their transactions. This is crucial for improving user experience by quantifying and reducing the execution risk.
This can be seem more evidently in the relationship between layer2s (L2s) and layer 1s (L1s). L2s can achieve enhanced scalability and maintain high security by utilizing the Ethereum base layer's inherent features of decentralization, censorship resistance, and data availability. Designed to be the primary user-facing layer, L2s nonetheless depend on the L1 for transaction latency and block confirmation times. This dependence introduces a bottleneck that impacts both transaction efficiency and the overall UX.
Deeper dive
Preconfirmations represent the routine aspect of our interactions with L2 transactions before they settle on the L1. Whenever a user interacts with the L2 between its last state root posting to the L1 and the next one, they receive soft confirmations of transaction execution from the L2. The certainty of inclusion and settlement of the transaction on the L1 is provided by collateral, which, in this context, is the reputation of the L2 sequencer - a centralized entity managed and controlled by the L2 itself.
Preconfirmations serve as early promises that a transaction will be included in a block, offering users faster feedback on their transaction status, backed by staked collateral. This process is vital for enhancing user experience by quantifying and mitigating execution risk.
The exact mechanisms used to fulfil this promise can be designed through 2 paradigms
• Protocol based
• Out of protocol solutions (3rd party entities)
(a) Protocol-based
Justin Drake first introduced protocol-based preconfirmations to deliver a competitive user experience with sub-millisecond latencies. These preconfirmations create an in-protocol standard for immediate inclusion guarantees in the next block. As preconfirmers, L1 proposers generate "signed promises" and earn tips from users by economically guaranteeing block inclusion through additional slashing conditions. This process, known as based sequencing, enables based Rollups. Consequently, the protocol can offer users preconfirmations on transaction execution.
To enable such innovation, we need to assume that
• A proposer is willing to opt into additional slashing conditions, via a third party protocol such as restaking, to achieve slashing (“staked preconfirmation”).
• The Proposer has the ability to force the inclusion of preconfirmed transactions or blobs into blocks via inclusion list (more on that in the following section).
L2s implementing this approach, known as "Based Rollups," inherit decentralisation and liveness from L1 while utilising straightforward sequencing by the L1 proposer. By opting in, preconfirmers (proposers) agree to join an external protocol where they can be penalised if they fail to fulfil their preconfirmation commitments. Each rollup can customise its preconfirmation sequence and slashing criteria to meet its unique needs.
Through this process, the MEV extracted flows back into the L1, which boosts the economic value and stability of the L1’s economic model. Although L2s may sacrifice some MEV revenue (as they would with a decentralized/shared sequencing model), they can continue to generate fee-based income through mechanisms like EIP-1559, ensuring long-term viability.
(b) Out of protocol solutions from 3rd party entities
• BFT & HotShot by Espresso: leverage the internal mechanics of the BFT consensus protocol to provide unique preconfirmation guarantees. Espresso's decentralized sequencer leverages HotShot's low-latency consensus to offer preconfirmations, enabling users to trust that a rollup has executed their transaction even before a proof is generated. By involving Ethereum validators through EigenLayer restaking, the Espresso network ensures secure transaction execution and minimizes trust assumptions on their own validator set.
• Bolt by Chainbound: an out-of-protocol sidecar for proposers, designed to enable Ethereum block proposers to credibly commit to their block contents. By introducing innovations like preconfirmations and inclusion lists, Bolt enhances user experience and censorship resistance, ultimately increasing block-space value and yields for stakers. Bolt also uses restaking for economic assurance and seamlessly integrates with the current block production pipeline. Bolt's uniqueness lies in several key principles. It is trustless, meaning no new trusted entities are introduced and commitments are backed by economic assurances rather than intermediaries. As a proposer-centric system, Bolt ensures credibility by holding proposers fully accountable for their commitments, with penalties for breaches to maintain integrity. It is also permissionless, allowing any proposer to opt into the protocol and any user to request commitments without a central authority. Furthermore, Bolt is designed to be compatible with the existing PBS pipeline and eventually ePBS, requiring only an additional sidecar from the proposer's perspective.
• MEV-commit by Primev: a P2P network that serves as a transparent and permissionless coordination layer for all MEV intermediaries and operators in the transaction supply chain. This network includes fulfillers like builders, rollups, relays, and sequencers, who provide sets of commitments. By gathering real-time commitments from a credible threshold of fulfillers, Mev-commit offers reliable guarantees without needing special delivery actors. The system also incorporates mechanisms to reward or penalize providers based on their performance. Bidders and end-users can specify their transaction execution preferences and receive commitments from execution providers, such as block builders and validators.
Execution tickets
At current state, PoS validators hold a perpetual “ticket”, which means they are randomly selected as proposers for each slot based on the staked ETH amount.
Under the new Execution ticket system, validators will no longer automatically have block proposal rights. Instead, they will need to acquire an execution ticket from the protocol through a lottery system. This change eliminates the "free ticket" advantage and is expected to significantly alter the way validators and builders interact. Execution tickets create a marketplace where proposers participate in a lottery to purchase a ticket for a given slot. Each block will have one winning ticket holder who gains the right to propose the block for that slot. Additionally, a secondary marketplace allows ticket holders to list and sell their tickets to other proposers.
Inclusion lists
Since the Merge, validators have largely outsourced block production to builders, giving them control over transactions and forcing proposers to choose between accepting this or missing out on MEV. Inclusion Lists aim to restore some decision-making power to proposers while balancing incentives and data availability concerns. While PBS enables competitive block creation through mev-boost, it also gives builders sole discretion over transaction inclusion. By allowing proposers to enforce the inclusion of transactions in the next block, Inclusion Lists ensure that important transactions are not omitted. This mechanism helps maintain proposer involvement in block production while preserving the competitive environment fostered by PBS.
Conclusion
In summary, preconfirmations are essential for improving user experience, expanding blockspace monetisation and redistributing control over transaction execution. Additionally, they enhance censorship resistance, uphold credible neutrality, and work to dismantle builder monopolies and vertical integrations within the entire transaction supply chain.
However, there are trade-offs to be considered in the implementation details. In-protocol approaches risk overloading the L1 and require extensive testing in external environments before full integration, which can impose design constraints.
Consequently, out-of-protocol designs from third parties offer faster innovation and production-ready solutions. Yet, these solutions may introduce new challenges, such as reduced credible neutrality, complex hardware requirements for low latency consensus (potential centralisation risk) and liveness guarantees from external third party protocols. Balancing these aspects is crucial for advancing the infrastructure while preserving its security and decentralisation.
46
- Vertical frameworks enable deep specialization in niche domains - Specialized agent swarms optimize tasks like DeFi and robotics - Focused verticals build strong, defensible ecosystems with real value https://paragraph.xyz/@signumcapital/signum-newsletter-36