Decentralization is one of the most important goals and principals at Base, as we strongly believe that this is what a global, free, onchain economy requires. We took the initial step towards this goal with:

• Fault Proofs: In October 2024, a decentralized proof system was set up allowing anyone to move funds between Ethereum and Base without relying on trusted authorities. Any user can permissionlessly make a claim as to the state of Base and any user can challenge a claim.

• Security Council: In April 2025, a decentralized committee reflecting Base’s values was set up to approve Base upgrades.

With the above, we achieved Stage 1 decentralization, the first milestone in Vitalik Buterin’s decentralization framework.

We have now set our sights on the next and final decentralization milestone: Stage 2. A technical requirement of stage 2 decentralization is the ability to detect and handle bugs onchain. Our new multiproof system consisting of TEE and ZK provers not only accomplishes this, but also:

• Improves user experience and liquidity efficiency by enabling faster withdrawals.

• Improves security as less financial resources are now required to defend against attacks.

As the main component for our journey towards Stage 2, this new system expresses Base’s commitment to decentralization as well as our security-first and user-first mindset. Below, we explore the specifics of various proof systems to better understand the technological landscape that informed our multiproof solution.

Proof Systems

Optimistic Proof Systems

Along with several other L2s, we started our path towards decentralization with an optimistic proof system. In this design, participants make a proposal as to what the state of Base is and this claim is optimistically accepted as the truth. If it is an invalid proposal, someone must actively challenge it, in which a dispute protocol would take place to determine who is correct.

While this system was an excellent initial step towards moving trust from central authorities to code, it faced certain limitations:

• Heavily Involved Process: The dispute protocol is an interactive process where it may take dozens of transactions for a dispute to resolve. Due to this and the possibility of delay attacks, enough time had to be given to allow honest defenders to respond.

• Onchain Complexity: The dispute protocol for resolving challenges is very complex. In the case of our previous fault dispute system, it needed a smart contract that mimics how a virtual machine would operate. This was a very difficult problem to solve and became hard to maintain.

Bond Requirements: To deter incorrect actions, participants needed to put up bonds, where one would lose their bond if found to be dishonest. The previous fault dispute system required hundreds of ETH in bonds if fully played out, straining the resources of honest defenders in the worst case.

Validity Proof Systems

Validity systems are where proving the state of a chain is required, as opposed to an optimistic system where verification generally never occurs and is only needed if there is disagreement among participants. In particular, every block in a proposal is proved to be correct.

These systems solve some of the issues optimistic systems face, such as:

• Non-Interactive Process: Proofs are generated offchain and verified onchain in a single transaction, no longer needing to provide time for participants to perform several steps. As a result, the complexity of these systems is mainly placed in offchain components.

• No Bonds: Assuming that the proof system works properly, there are no possible dishonest actions to take, meaning bonds are not needed.

There are two main validity systems at the moment: Zero-knowledge (ZK) and trusted execution environments (TEE).

ZK Proof Systems

These are decentralized systems that prove the state of a chain through advanced mathematics and cryptography. There are also hybrid models that combine an optimistic and ZK approach, but time for challenges and bonds is still required, albeit with much lower bond requirements than the full optimistic setup. Examples of these are Op-Succinct and Kailua.

However, the main drawbacks preventing full adoption are:

• Complexity: The offchain components rely on advanced mathematics and cryptography, which are difficult to soundly implement. Detailed specifications, proper theory-to-implementation practices, and formal methods are artifacts that give us confidence in a ZK prover.

• Cost: The resources needed to prove Base blocks in real-time are high, especially as we look to scale the chain further. Fortunately, there have been many advances in this field bringing costs to a likely manageable level in the future.

TEE Proof Systems

TEE proofs provide assurance for integrity from a hardware point-of-view. These proofs ensure that the state of Base was derived correctly and not tampered with. They are also efficient to produce and cheap to verify. 

The main downside is that this is a centralized option. Trusting a TEE requires trusting an authority, such as AWS or Intel. TEEs can be further divided into physical TEEs and cloud-based ones, each with their own downsides:

• There are known attacks against TEEs if one has physical access, such as side-channel attacks

• Cloud-based TEEs include another layer of trust: the cloud provider

Our Solution: Multiproofs with TEE and ZK

The solution we landed on is a combination of TEE and ZK provers, a system inspired by Vitalik’s L2 finalization roadmap. At a high-level, the proof system:

• Requires either a TEE or ZK proof to finalize a proposal

• Allows fast finalization (at most 1 day) if both TEE and ZK proofs are present

• Allows a ZK proof to overrule a TEE proof

• Raises a soundness alert when contradictory proofs exist

We immediately obtain the following:

• Better liquidity efficiency due to fast finality when both TEE and ZK proofs are present

• Decentralization as proposing remains permissionless with ZK proofs and permissionless components override permissioned ones

• Technical requirements for Stage 2 since we can now detect proof system bugs onchain

We view ZK proving as the ideal setup for the future. However, before we can get there, we need to build our confidence and knowledge of this technology in order for us to fully rely on it later. That is why as an intermediary step, we view TEE proofs as the main way to progress the proof system while maintaining safeguards as we gain confidence in ZK technology.

Security

As the proof system is what secures Base, it was the main focal point in the design process. By shifting from an optimistic system to a validity one (a proof is required for every proposal), we raise the assurance that each claim is correct.

The main worry now is if there is a vulnerability in a prover and an incorrect proof can be produced. We address this with the following added functionalities:

• Soundness Alerts: If contradictory proofs exist, such as two ZK proofs for the same block number with different claims, then the proof system automatically disables the associated prover.

• Intermediary Roots: While proving a proposal requires proving every block the proposal covers, showing a contradiction only requires showing disagreement with one block. This is where intermediary roots come in, which are subclaims every couple of blocks in a proposal. Showing a contradiction with a subclaim is enough to contradict the entire claim, raising a soundness alert. As a result, defenders do not have to disprove an entire proposal, but only a small portion, reducing the requirements on defender resources.

Our choice of SP1 as the current ZK prover reflects this, as it is one of the most performant and secure prover on the market right now, backed by several audits and formal verification.

Future Roadmap

The new proof system was designed with a particular end state in mind: full ZK proving. This will allow us to have near instantaneous withdrawals, a feature we believe will be great for users.

To get there, we will be exploring ways to:

• Improve ZK Security and Efficiency: We are looking at changes we can make to the chain to make real-time proving a reality and we are always evaluating various ZKVMs to see how this technology is improving.

• Decreasing Finality Times: As confidence and efficiency in ZK improves, we will be looking to decrease the time it takes a proposal to finalize, ideally to just a couple of minutes.

This next chapter in our journey towards full decentralization on Base is defined by the launch of the multiproof system, an architecture that secures our network while laying the groundwork for improved  user experience and liquidity efficiency via decreased withdrawal times. By leveraging the complementary strengths of TEE and ZK proofs, we have not only met the technical requirements for Stage 2 decentralization but have also established a robust framework for future innovation. As we continue to evaluate ZK technology and work towards decreasing finality times, we are dedicated to realizing our ultimate goal: a credibly neutral, secure, and performant L2 that is ready to scale the onchain economy to a billion users.

In our previous post, we shared why Base is consolidating onto a streamlined Base stack to ship faster and simplify the protocol. Base Azul is the first network upgrade built on top of this new foundation. Base Azul is now live on testnet and is scheduled for Base Mainnet on May 13.

The Azul upgrade follows months of work for improved stability and consolidating our stack. And it's already paying off. Over the past two months, we've:

• Increased Builder Reliability: Reduced the number of empty blocks by ~99% — from ~200/day to ~2/day

• Increased Chain Throughput: Sustained multiple 5,000 TPS bursts

• Shipped Faster: Cut client releases fortnightly, added new features, and improved validator performance

Security is our top priority for Base. Every onchain component and proof system in Azul has gone through both internal and external audits. And to get as many eyes on the code as possible before activation, we're running an Immunefi audit competition from April 21 to May 4, with a $250,000 maximum reward pool for any critical vulnerabilities reported.

What’s in Azul?

Azul delivers impact in three key areas:

1. Increases security and decentralization: Multiproof-driven Stage 2 decentralization

2. Accelerates the path to 1 gigagas/s: Performance-focused client stack consolidation

3. Improves developer experience: Ethereum Osaka spec alignment

Increased security and decentralization

With Azul, we're activating multiproofs on Base - a major step in our path toward Stage 2 decentralization. Multiproofs combine TEE and ZK provers into a single system: either proof type can finalize a proposal on its own, but when both agree, withdrawals finalize in as little as one day.

This unlocks faster withdrawals and better capital efficiency for users, while satisfying a core technical requirement of Stage 2: the ability to detect and handle proof system bugs onchain. Posting ZK proofs is permissionless and will override the permissioned TEE proofs if there is a contradiction. The design is inspired by Vitalik's L2 finalization roadmap and gives us security-in-depth. An attacker would need to compromise multiple independent systems for fast withdrawals, not just one.

Multiproofs are an intermediary step towards our desired end state of full ZK proving with near-instant withdrawals. Getting there means onboarding additional ZKVMs, investing in real-time proving performance, and progressively shortening finality times as our confidence in the technology grows.

Over the next few weeks, we’ll be sharing a blog post that provides more details. For now you can learn more in our specification.

Accelerated the path to 1 gigagas/s

Azul consolidates Base onto a single, performance-focused client stack:

• base-reth-node becomes our sole execution client. Reth has consistently been one of the highest-performing clients on Ethereum, and is providing the headroom to scale Base.

• base-consensus is our new consensus client, based on Kona. It already delivers significantly faster historical sync, and we'll keep optimizing it on the path to 1 gigagas/s.

Azul drops support for all consensus and execution clients except for base-reth-node and base-consensus. You can get the latest client releases from base/base.

We plan to further simplify the node software by combining these into a single binary base in the upcoming months.

Improve developer experience

Azul aligns Base with Ethereum by adopting the latest execution-layer specs (Osaka). The main changes are:

How Azul impacts you

Users

Users won’t have to take any action for this upgrade. Base just gets faster, safer, and cheaper for you to use. Withdrawals from Base to Ethereum will get faster as the multiproof system matures.

Node operators

You'll need to migrate to the new Base clients before the network upgrade activates. For the consensus client, you’ll need to run  base-consensus and base-reth-node for the execution client. Step-by-step instructions are in the node operator upgrade guide.

If you serve historical proof RPCs (e.g. eth_getProof, debug_executionWitness and debug_executePayload) you’ll need to enable our historical proofs extension to serve these performantly. More information can be found here. 

Developers

Most apps require no changes. If you use MODEXP heavily, send very large transactions, or consume the Flashblocks websocket directly, review the spec changes linked above before activation.

Auditors

For white hats and security researchers, we’re running an audit competition on the testnet code with Immuefi with a reward pool. More information can be found here. 

What's next

Azul is the first of many Base upgrades. In the spirit of building in public, we are sharing our current working plan for the next several months of network upgrades. We will continue to iterate based on community feedback and the evolution of Base.

We expect the next two upgrades to include: 

•  End of June: Performance-focused. Enshrined token standard, Flashblock Access Lists, Glamsterdam EIPs, single client binary and reduced withdrawal times.

• End of August: UX-focused. Ship native account abstraction.

In mid-May we're also launching Base Vibenet, a public devnet for developers to experiment with our upcoming features and give us early feedback. Vibenet isn't tied to a hardfork, it's our permanent space to try things ahead of mainnet.

Azul is the first network upgrade on a stack we control end-to-end, and the start of a steady cadence of independent upgrades on the path to a global, free, onchain economy that serves the next billion users.

If there's something we can do better, we want to hear it. Reach us on X, Discord, or GitHub.

The Evolution of the Stack

The mission Base launched with is the same mission we have today: make it the best place to build and onboard the next billion people into the onchain economy. We knew that this required creating a secure, low-cost, developer-friendly home for anyone, anywhere, to build on top of. To get there quickly, Base launched as an OP Stack chain. Over time, we grew to incorporate a diverse range of software in collaboration with various partners, including Optimism, Flashbots, and Paradigm. These collaborations enabled features like Flashblocks, but also introduced a complex web of external dependencies.

Today, we’re introducing our new unified stack for running Base - where all dependencies and future innovations are now consolidated into a single place. Base was built on the shoulders of giants - we could not have gotten so far so quickly without the world-class technology underpinning the OP Stack and are grateful for the collaboration over the last 3 years.

Why are we doing this?

We have three objectives:

• Faster Shipping Cadence: Consolidating the stack means we can move faster. We're targeting six smaller, tightly scoped hard forks per year, doubling the current schedule (vs three per year currently). We’ll ship upgrades frequently rather than batching risk into infrequent large ones.

• Reducing Cognitive Overhead: The protocol spec and codebase should be understandable by a single developer. By focusing on just what Base needs, we’ll radically simplify the stack. 

• Collaborative success with Ethereum: Base wins when Ethereum wins. We will accelerate to deploy high-impact changes, such as BAL, ahead of the L1 to provide data that informs the Ethereum roadmap.

A Unified Stack

Today, the code operating various components of Base, such as the sequencer, is owned by multiple teams and spread across multiple repositories, which adds coordination and maintenance overhead. Our unified solution, base/base, built on open-sourced components such as Reth, allows us to dramatically simplify the number of components, by optimizing them directly for our use case.

Consolidating into base/base changes how Base packages and releases software for the network. We will ship one official distribution for each upgrade: a single Base binary for operating nodes on the network.

This unification does not mean Base will be built in isolation. The protocol remains public and specified in the open, and alternative implementations are welcome and encouraged. Any team can build, run, and maintain an independent client that follows the published specs and remains compatible across hard forks.

Accelerating Upgrades

Evolving the stack means updating Base’s software and upgrade process. Over the coming months, Base is moving away from the OP Stack, however, we’ll continue to work with Optimism as a client of OP Enterprise: Mission-Critical Support. Once the transition is complete, upgrades and release information will be published through ⁠base/base. 

Maintaining High Decentralization Guarantees

It was important that in this evolution, we didn’t make any tradeoffs in security or technical decentralization. We are committed to maintaining, and exceeding, the highest standards for rollup safety.

• Stage 1 Status: Base remains a Stage 1 Decentralized Rollup.

• The Base Security Council:  In lieu of Optimism, we are adding an additional independent signer to the Base Security Council.

• Accelerated Security Roadmap: This also allows us to move faster on our decentralization milestones, including faster withdrawals via a more robust multi-proof system, Base-specific governance, and enhanced neutrality standards that protect economic autonomy across the entire stack.

Building in Public

We believe the technology behind Base should be a public good.

• Open Source Forever: Base specifications and code will always be public, open for contribution, and available for others to fork.

• Client Diversity: We actively encourage the community to build alternative clients and implementations for Base to further harden the network.

• Ecosystem Tooling: We will continue to contribute to essential tooling like Foundry and Wagmi, ensuring a great developer experience for building on Base.

Our goal is to assemble the best libraries from across the ecosystem and continually adopt better options as they emerge. We’re open to new partners and libraries that improve performance, security, or decentralization, and we’ll work in public and contribute upstream so the broader ecosystem benefits.

How does this impact you?

Our goal is to ensure the transition to our consolidated stack is as seamless as possible for the builders, node operators, and users in the Base ecosystem. While the underlying technology is evolving, the experience of using Base will remain consistent. Here is what you can expect:

• Today: No immediate action is required. Base will continue operating as it does today, and we will remain compatible with the OP Stack specification (including continued support for existing RPCs). We’ll continue to upstream bug fixes and coordinate security disclosures to help keep the broader Superchain ecosystem safe.

• Next Few Months: If you run a Base node, you will need to migrate to our Base client to remain compatible with future hard forks. All RPCs, including those in the optimism namespace, will continue to be fully supported to prevent breaking existing integrations.

• Longer Term: As Base matures, the network will become significantly more decentralized and scalable, enabling higher throughput and lower costs. To maintain stability, breaking changes that require node operators and clients to upgrade will be rare, occurring only during scheduled hard forks and communicated well in advance to the community.

Roadmap Preview

In the spirit of building in public, we are sharing our current working plan for the next several months of hard forks. We will continue to iterate based on community feedback and the evolution of Base.

The Road Ahead: Scaling for a Global Economy

Base is moving from a patchwork of dependencies to a single unified stack in base/base. This means node operators will need to migrate to the Base client and releases will run on a faster, more frequent schedule.

We continue to be committed to building in the open: Base’s codebase and protocol remain open-sourced and influenced by Ethereum’s roadmap. Base will continue to raise its decentralization and security bar while we ship updates more predictably and efficiently.

Join Us

Building the next frontier of the internet is a collective effort. If you are passionate about scaling, securing, or decentralizing the future of Base, we want to hear from you. View our open roles and apply here.

The Attribution Gap

While anyone can link a transaction to a specific protocol, determining which app facilitated the transaction is difficult.

Protocols are onchain smart contracts users interact with directly. For example: decentralized exchanges like Aerodrome or lending protocols like Morpho.

Apps are offchain entities that drive transactions for any use case. For example: web and mobile interfaces, trading bots, and backend automations.

Protocols are straightforward to track because all interaction data exists publicly onchain. Apps however have no native link to the transactions they facilitate.

This gap has real consequences. Without attribution data, chains can't measure which apps bring value to the ecosystem. Allocation of attention, distribution, and capital investments becomes manual guesswork rather than data-driven decision making. Builder Codes and ERC-8021 close this attribution gap and enable builders to compete for resources in a way that’s more open and transparent.

Industry Inspiration

Others have independently recognized and addressed this problem in their ecosystems, but not in a way reusable by everyone.

Hyperliquid pioneered the term "Builder Codes" by allowing apps to annotate transactions to receive a portion of generated swap fees, creating measurable incentive alignment and rewarding the apps that drive real volume.

Polymarket followed with a similar implementation where apps can annotate transactions through their order book API to qualify for rewards.

Both solutions work well within their ecosystems, however they are isolated to specific use cases (Hyperliquid for perpetuals, Polymarket for prediction markets). To make transaction attribution work across Ethereum, we needed a general-purpose standard that any protocol can adopt.

ERC-8021: Transaction Attribution for Ethereum

We wrote ERC-8021 to enable attributing any transaction on Ethereum today. To do this, we had to work under a couple constraints:

1. It needs to work with Ethereum’s existing transaction format. This enables shipping quickly for both nodes and apps by staying interoperable with existing code and tools.

2. It needs to work regardless of what transactions are trying to do. This enables us to serve all protocols with no integration effort and build developer network effects.

Data Suffixes

To meet these constraints, we leverage an underutilized EVM property: smart contracts ignore extra data appended beyond expected function arguments. If you call a smart contract function with any additional data after function arguments, by default they are safely discarded without errors or reverts. Because this “data suffix” passes through without impacting execution, we can attribute safely and for any transaction type.

Here's what this looks like in practice:

A smart contract only reads up through abi-encoded data (0xabcd...1234) to execute the interaction. The attribution data suffix (0xaaaaaaaaaaaa) passes through without affecting execution, but remains available in transaction data for analytics.

This pattern isn't new. Many teams already use it in production at scale including Aerodrome, Morpho and the Base App.

What's been missing is standardization. Each team implements their own format, making it difficult to parse attribution across different apps. ERC-8021 solves this by defining one canonical data suffix. The standard supports both regular transactions and ERC-4337 user operations, ensuring compatibility with all wallet types.

Standardizing the Data Suffix Schema

ERC-8021 builds up its schema by solving three core problems: interoperability, extensibility, and identity. Let's derive the format from first principles.

Problem 1: Interoperability

Existing attribution methods struggled with interoperable detection. While a specific app can append a custom data suffix they know to look for, how does a separate party discern if transaction data ends with attribution or not? Without a standard marker, every parser needs custom logic for every attribution format.

ERC-8021 solves this with a constant marker at the end of every data suffix: 0x80218021802180218021802180218021 (16 bytes of "8021" repeated). This enables parsers to reliably detect attribution is present by checking if the last 16 bytes match the standard marker. The probability of accidental collision with this specific 16-byte sequence is negligibly low (1 in 2^128), making it a reliable detection mechanism.

ercMarker = 0x80218021802180218021802180218021
attributionData = 0xaaaaaaaaaaaa
dataSuffix = attributionData + ercMarker
           = 0xaaaaaaaaaaaa80218021802180218021802180218021

Problem 2: Extensibility

Attribution needs will evolve. Today's format might not serve tomorrow's use cases for new attribution types, more efficient encoding, additional metadata fields, and more. We needed a versioning mechanism to iterate without breaking existing implementations.

ERC-8021 adds a one byte schemaId immediately before the ercMarker to identify how to parse additional preceding schemaData. This single byte provides 256 possible schema versions, each defining how to parse the actual attribution data.

ercMarker = 0x80218021802180218021802180218021
schemaId = 0x00
schemaData = 0xaaaaaaaaaaaa
dataSuffix = schemaData + schemaId + ercMarker
           = 0xaaaaaaaaaaaa0080218021802180218021802180218021

The suffix is designed to be parsed backwards from the end of calldata:

1. Extract last 16 bytes → verify ercMarker matches standard

2. Extract previous byte → switch on schemaId to determine parsing rules

3. Parse remaining bytes according to schema specification

Problem 3: Identity

For attribution to be useful, it needed to help identify who gets credit for a transaction. Existing candidates to identify this were Ethereum addresses, app names, and website domains, but each of them compromises on an important property. The ideal identifier is small and can link to additional information as needed.

ERC-8021 chooses "codes" as string-based identifiers (e.g. "abc123"). Codes are familiar to developers, mapping to concepts like referral codes in traditional apps, and are human-readable for debugging. 

ERC-8021 also defines a Code Registry smart contract where codes can be registered and their additional related information read from, generally splitting into either onchain or offchain metadata.

Onchain metadata enables protocol rewards. Protocols can query where rewards credited to a code should be sent to. For example, a DEX could reward the frontends generating the most trades.

Offchain metadata enables app discovery. By associating codes with app names and domains, we create a transparent view of the ecosystem. Public dashboards can surface top apps by transaction volume, turning onchain usage data into a distribution channel for users to find new apps.

Anyone can deploy their own Code Registry so long as it adheres to the standardized interface. Different ecosystems can run their own registries with custom rules while still enabling others to parse attribution and query related information.

interface ICodeRegistry {
    /// @notice Returns the address where protocols should send rewards
    /// @dev This enables anyone to distribute rewards to an app that drove volume
        function payoutAddress(string memory code) external view returns (address);

    /// @notice Returns a URI to fetch offchain metadata (app name, website, logo)
    /// @dev This enables building discovery interfaces and leaderboards
    function codeURI(string memory code) external view returns (string memory);

    /// @notice Checks if a code follows format rules (character set, length constraints)
    /// @dev Parsers use this to filter malformed data
    function isValidCode(string memory code) external view returns (bool);

    /// @notice Verifies a code has been registered
    function isRegistered(string memory code) external view returns (bool);
}

End-to-End Flow

Let's walk through how ERC-8021 works in practice, from registration through transaction submission and parsing.

Step 1: Register a Code

An app registers a code (e.g., "baseapp") with a unique Code Registry. The registry stores onchain metadata and a pointer to offchain metadata for the code.

Step 2: Encode the Data Suffix

When preparing a transaction, the first app injects their code into an ERC-8021 data suffix (real example below):

ercMarker = 0x80218021802180218021802180218021
schemaId = 0x00
codesLength = 7
codes = ["baseapp"]
schemaData = codes.join(",") + codesLength
           = 0x6261736561707007
dataSuffix = schemaData + schemaId + ercMarker
           = 0x62617365617070070080218021802180218021802180218021

Step 3: Append Data Suffix to Transaction Data

The app then appends this data suffix to the transaction data:

transaction.data = abiEncodedData + dataSuffix
                 = 0xabcd...1234 + 0x62617365617070070080218021802180218021802180218021
                 = 0xabcd...123462617365617070070080218021802180218021802180218021

Step 4: Submit Transaction as Normally

After the transaction is prepared, it can be signed and submitted by the app directly or through prompting the user to do so with their wallet.

Step 5: Parse and Attribute

After the transaction is confirmed onchain, analytics tools parse its data for attribution:

1. Check last 16 bytes for ercMarker → confirms ERC-8021 format

2. Read schemaId byte → determines parsing rules

3. (Given schema 0 in this example) Extract codes length and codes array → "baseapp"

4. Query registry for payout address and metadata matching ”baseapp” code

The result: universal, interoperable transaction attribution across Ethereum. Learn more by reading the official specification.

Base Builder Codes

Base aims for every transaction to be attributed with ERC-8021 to inform how we prioritize our attention, distribution, investment capital, and rewards for the teams that grow Base's global economy. 

To make this happen, we’re launching Base Builder Codes: the first ERC-8021 Code Registry. Apps that opt-in and append Base Builder Codes to their transactions can make it on our public leaderboard. Anyone can claim a Base Builder Code through base.dev for free today.

Several key partners in the Base ecosystem have already agreed to implement ERC-8021 builder codes on Base to help close the attribution gap: Aerodrome, Avantis, Bitget, Clanker, Definitive, Flaunch, Hydrex, Jumper, Kyber, Limitless, Maestro, Mamo, Moonwell, o1, PancakeSwap, Privy, Rips, Sigma, Slab, Sport.Fun, Swissborg, Treble, Turnkey, Virtuals, and more.

For additional details on our smart contract implementation, read more at github.com/base/builder-codes.

Integrating Base Builder Codes

Integrating Base Builder Codes impacts how you prepare transactions and potentially how you submit them, depending on the wallet stack your app uses. 

There are typically three wallet types that apps can submit transactions from:

1. Universal wallets: Third party experiences brought by users (e.g. Base App, MetaMask)

2. Embedded wallets: Provisioned by apps for each user (e.g. Privy, CDP Embedded Wallet)

3. Server wallets: Managed by apps server-side independently (e.g. Turnkey, CDP Server Wallet)

If you're a wallet provider: You need to expose a way for apps to customize transaction data. For universal wallets, this likely means implementing ERC-5792's wallet_sendCalls with the dataSuffix capability. For embedded and server wallets, this likely means ensuring apps have a means to append manually to transactions via your APIs and SDKs. ERC-4337 accounts may require additional work to support data suffix appending for user operations. Read more here.

If you're an app: The integration path depends on your wallet model. Apps with direct control over signing (embedded or server wallets) can manually append data suffixes. Apps using universal wallets rely on the dataSuffix capability in wallet_sendCalls. Read more here.

Frontend Integration with Universal Wallets

These apps enable users to bring their own wallet to authenticate and use onchain funds. Users connect via web popups, browser extensions, mobile wallets, and more.

Apps submit transactions with Universal Wallets through standardized wallet APIs. Wallets can customize how they render these requests to users, facilitate signing, and transaction submission. We recommend using the wallet_sendCalls method with a dataSuffix capability:

// Sample ERC-8021 attribution  for "baseapp" from earlier
const response = await provider.request({
  method: 'wallet_sendCalls',
  params: [{
    calls: [{
      to: protocolAddress,
      data: encodedCalldata,
      value: '0x0'
    }],
    capabilities: {
      dataSuffix: {
        value: '0x62617365617070070080218021802180218021802180218021'
        optional: true
      }
    }
  }]
});

We also recommend using the Wagmi library for convenience where you can specify a default dataSuffix to auto-apply to your transaction requests.

Frontend Integration with Embedded Wallets

These apps enable users to receive and use wallets in an invisible manner while preserving degrees of non-custodial ownership. Users login with traditional offchain methods (e.g. phone number, email) and typically treat their account as bounded to the app.

Apps submit transactions with Embedded Wallets through their provider’s SDKs and/or APIs. Since the app has control over transaction signing, you can manually append data suffixes to transaction data and directly sign. Most embedded wallet SDKs now support dataSuffix parameters directly in their interfaces.

For example, you can reference these guides from Coinbase and Privy.

Backend Integration with Server Wallets

These apps transact directly from their own servers, often with keys managed by third party providers.

Apps submit transactions with Server Wallets through their provider’s SDKs and/or APIs. This works nearly identically to embedded wallets: append your ERC-8021 formatted suffix to transaction data before signing and sending.

Start Attributing Today

The foundation for a globally attributable and rewarded onchain economy is here. ERC-8021 and Base Builder Codes are the missing layer to identify the apps that generate real value.

Close the attribution gap for your app, plug into the Base flywheel, and show off your contributions to the onchain economy.

Claim your Base Builder Code and start attributing today at base.dev. We look forward to seeing what you build!

More resources:

• ERC-8021 Standard: eip.tools/eip/8021

• Base Builder Codes: github.com/base/builder-codes

• Integration Guide: docs.base.org/base-chain/quickstart/builder-codes

Rewards are one of the most powerful growth tools in crypto — and the easiest to exploit.

Across the ecosystem, teams run into the same issues:

• Bots and multi-wallet users frequently drain reward pools

• Gated access leaks almost instantly

The problem isn’t incentives themselves. It’s identity.

Wallets don’t prove uniqueness.

Anyone can create unlimited wallets and interact repeatedly. Without stronger identity signals, it’s nearly impossible to reward real users, prevent abuse, or build meaningful reputation.

Introducing Base Verify

Base Verify is anti-Sybil verification infrastructure built into the Base App and now available to the broader ecosystem.

It allows users to prove ownership of real accounts — such as X, Instagram, TikTok, or Coinbase — without revealing credentials or personal data to applications.

Instead of tying access and rewards to wallets alone, Base Verify anchors them to real-world identity signals and returns a deterministic verification token:

1. The User proves they own a real account. They log in to a social platform—X, Instagram, TikTok, or Coinbase—through a familiar "Sign in with..." flow, the same kind used by countless apps.

2. Base Verify creates a unique identifier. This identifier is tied to the user's social account, not their wallet. Critically, the same social account always produces the same identifier.

3. Your app stores that identifier. The next time anyone tries to claim—even from a different wallet—you check if you've seen their identifier before.

This creates a simple and powerful guarantee:

One real account equals one claim — regardless of how many wallets a user controls.

It also unlocks something wallets can’t: the ability to recognize high-value users even when their on-chain activity is minimal. A brand-new wallet might still belong to a Coinbase One subscriber, an X Blue user, or a creator with a large audience. Beyond proving uniqueness, Base Verify can also check whether users meet specific requirements—like having 10,000 followers, holding a Coinbase One subscription, or being a verified creator. Users prove they qualify without revealing the underlying data.

Built for Base Mini Apps

Base Verify already powers identity, reputation, and feed quality inside the Base App. We built it to operate at platform scale first, then opened it to all builders.

For the ecosystem, this means you get access to the same infrastructure we rely on. And because verifications are shared across the Base App, users only need to verify once. That single verification then works across every app that uses Base Verify.

Users verify once, and that verification can unlock value across multiple Mini Apps inside the Base App.

Base Verify is already live and operating at scale:

• 200,000+ verifications completed and growing

It’s already used in production by Base Mini Apps today. Early partners include:

• Cody Uses Base Verify to prevent reward farming and enforce one claim per real account.

• Scratch Distributes tokens to high-value users instead of anonymous wallets.
  

• Bracket Gates $BRACKY airdrops to Coinbase One members, powering sports betting incentives inside a Mini App.

What Base Mini Apps Can Build With Base Verify

Rewards that can't be farmed: Ensure incentives go to real people, not wallet farms.

Tiered access using social proof: Unlock Mini App features based on signals like follower count or verification status.

Subscriber-only benefits: Offer perks to Coinbase One members without building subscription infrastructure.

Creator programs: Identify real creators using engagement thresholds instead of empty accounts.

Start Building with Base Verify

Base Verify is available today for builders. Please fill out this form to request access to Base Verify. Check out the documentation here. 

If you’re building incentives, rewards, gated access, or reputation systems inside Mini Apps, we’d love to collaborate.

If your token launched on Solana, BSC, or another chain and you want it to be tradable on consumer interfaces that aggregate onchain liquidity across EVM networks, the process is straightforward: establish a verified token on your destination network, bridge supply using reputable infrastructure, seed liquidity, and publish safe, official links. This explainer focuses on Solana and BSC, with guidance that applies to other chains as well. It’s educational and venue‑neutral, and does not imply any centralized listing outcomes, endorsement of any asset, or use by any particular person or jurisdiction.

Before you move: make the token launch‑ready

Confirm audits and explorer verifications, set up multi‑sig and timelocks for admin functions, and prepare a concise public page with official contract addresses and links. Share enough detail to keep users safe, but avoid pre‑announcing exact deposit times or granular pool parameters that bots can exploit. Announce from official accounts, use signed messages, and maintain a single “official links” hub to reduce phishing risk.

Solana to Base: using the Base–Solana Bridge

Solana projects can bridge to Base via the official Base–Solana Bridge, now live on mainnet and secured by Chainlink CCIP alongside Coinbase subject to applicable terms and operational assumptions. Use verified domains, start with small test transfers, and confirm transactions on explorers before publishing instructions. Share the destination token address and a short verification guide so users can independently confirm they’re interacting with the correct asset. The bridge is open‑source and available for builders to integrate, with documentation to support SOL and SPL assets in Base apps.

BSC to Base: secure routes and configuration

For BSC, several established bridges support movement into Base, including Wormhole, LayerZero (OFT for unified supply or Stargate for liquidity bridging), and options like Axelar or deBridge. Begin with small transfers, configure rate limits and endpoint monitoring, and publish destination addresses and explorer links so wallets and aggregators recognize your asset.

Make the token tradable: seed liquidity across platforms

Once your token exists on the destination network, create pools on one or more venues so aggregators can route trades. On Base, popular choices include Aerodrome and launch tooling like Flaunch; cross‑chain options include Uniswap, Sushi, and Maverick. Pick a common pair (e.g. token/ETH or token/USDC), set a fee tier that compensates LPs for early volatility, and consider layered ranges if you use concentrated liquidity. To reduce sniping, share pool details only after onchain confirmations rather than pre‑publishing exact timestamps or ranges.

Broaden access beyond one network

Many teams improve accessibility by maintaining liquidity across multiple platforms and, where appropriate, mirrored pools on other chains. If you use project‑owned liquidity, disclose it and size it prudently so it doesn’t dominate active liquidity or distort price discovery.

Operational safety you should bake in

Use multi‑sig for admin changes, timelocks for sensitive operations, and segregated operational wallets. Monitor bridge events and pool health (TVL, fees, LP concentration, slippage). Coordinate with indexers and analytics sites to display verified logos and addresses, and keep your official links page current to reduce spoofing.

Closing

A multichain approach to onchain liquidity is repeatable when you combine reputable bridging, verified contracts, and measured liquidity seeding. Publish enough detail to keep users safe, avoid granular pre‑announcements that enable bots, and consider multi‑platform liquidity to broaden access. This explainer covers mechanics—not outcomes.

Disclaimers

• Use of bridges, pools and onchain applications may be restricted or prohibited in certain jurisdictions or for certain persons (including under sanctions or AML regimes). You are responsible for compliance with applicable laws, including sanctions, AML and consumer protections laws.

• Nothing herein constitutes facilitation, brokerage, solicitation, distribution or intermediation of any token, protocol or transaction and does not create any agency, partnership or advisory relationship.

• Educational, venue‑neutral content. This does not advise on token sales, fundraising, pricing, investor targeting, regulatory classification, or legal risks. It is not legal, tax, or investment advice; consult your own counsel.

• Availability via onchain interfaces is independent of centralized listing decisions. No guarantees, signals, or implied likelihood of listing. Choices of bridge, venue, or chain do not affect listing outcomes.

• References to bridges and tooling (including the Base–Solana Bridge, Chainlink CCIP, Wormhole, LayerZero, Axelar, deBridge, Aerodrome, Flaunch, Sushi, Maverick, Uniswap) are examples; availability and security characteristics may vary. Always verify official documentation, endpoints, and contracts before use.

A year ago, we made a bold decision: evolve Coinbase Wallet into the Base App, an onchain everything app that brings social, trading, payments, app discovery, and earning into one place. Our goal was to build a consumer-grade experience that rivals the best social apps, while gracefully handling onchain challenges like transaction confirmations and real-time blockchain data syncing. But we also knew it was critical to balance security and quality with speed and scale. To do this, we carefully considered how to handle loading states.

We started with loading skeletons (or shimmer UIs). They serve a single purpose: to keep users engaged while data is being fetched. Instead of staring at a blank screen or a spinning loader, users see a visual placeholder that mimics the final layout of the content.

But loading skeletons are ultimately an elegant band-aid, and we set out to do better. They help mask slow APIs or heavy computations by giving users something to look at while they wait. While they improve the overall user experience, they don't address the root cause of slow performance.

As the content is being fetched, the skeleton itself must be rendered first, followed by the actual content once it’s loaded. This double render cycle can affect performance, particularly on less powerful devices. The result? An additional delay that might ironically make the app feel slower, especially in low network conditions or on resource-constrained devices.

One could also argue the repeated, jumpy flash of gray shimmers isn’t as elegant as we thought. See our current Profile loading timeline:

This pattern addresses a backend bottleneck : Loading data from multiple sources, all at once can be slow. It introduces a waterfall of layout loading state while various parts of the screen are being fetched.

However, this came at the tradeoff of making the user's experience substantially worse.

We wanted to do better. So we built a behavioral prefetching system in the new Base App to anticipate user behavior and deliver content instantly.

Solution: Behavioral, data-driven prefetching

We have data on the navigation habits between different links and screens. E.g: Users on the Feed are more inclined to navigate to a Cast than a Profile.

We also know when links are in the viewport. We can use this to design a simple prefetching algorithm:

score = conversionRate * visibility * manual priority

And start prefetching screens data accordingly:

A simple idea in principle, with many caveats.

Overfetching

There can be hundreds of links on any given screen — so how can we reduce scope and only prefetch visible items? Unfortunately react-native doesn’t have yet an Intersection Observer API so we came up with a few alternatives below. 

Note: These snippets are meant to be educational / inspirational, copy-pasting as-is won’t work.

Measure & onLayout

With react’s New architecture, we can leverage the useLayoutEffect & measure method

function PrefetchOnVisible({ children, prefetchQuery }) {
  const ref = useRef<View>(null);
  const prefetchManager = PrefetchManager.getInstance();

  // Synchronous, first-frame measure
  useLayoutEffect(() => {
    ref.current.measure((_x, _y, _width, _height, _pageX, pageY) => {

      // Within Viewport?
      const isComponentVisible = pageY <= viewPortHeight && pageY + 100 >= 0;
      if (!isComponentVisible) return;

      prefetchManager.process(prefetchQuery);
    });
  }, [prefetchQuery]);

  return <View ref={ref}>{children}</View>;
}

For legacy Architecture, we can fallback to onLayout callback:

function PrefetchOnVisible({ children, prefetchQuery }) {
  const ref = useRef<View>(null);
  const prefetchManager = PrefetchManager.getInstance();

  // Asynchronous, next frame measure
  const onLayout = useCallback(() => {
    ref.current.measure((_x, _y, _width, _height, _pageX, pageY) => {

      // Within Viewport?
      const isComponentVisible = pageY <= viewPortHeight && pageY + 100 >= 0;
      if (!isComponentVisible) return;

      prefetchManager.process(prefetchQuery);
    });
  }, [prefetchQuery]);

  return (
    <View ref={ref} onLayout={onLayout}>
      {children}
    </View>
  );
}

Then wrap our links accordingly:

function ProfileLink({ children, profileId }) {
  const navigateToProfile = useCallback(() => {
    navigate('Profile', { profileId });
  }, [profileId]);

  const profileQuery = useProfileScreenContentQuery(profileId);

  return (
    <PrefetchOnVisible prefetchQuery={profileQuery}>
      <Pressable onPress={navigateToProfile}>
        {children}
      </Pressable>
    </PrefetchOnVisible>
  );

If ProfileLink is within the viewport when the screen renders, ProfileQuery will be fetched & cached. Navigation to the profile will become instant.

However, this only works for static, non-scrollable screens: useLayoutEffect and useLayout only fire when the layout changes.

Virtualized list: renderItem & onViewableItemsChanged

Most if not all virtualized lists (FlatList, FlashList & LegendList) have two methods we’re interested in:

• renderItem

• onViewableItemsChanged

We can wrap these methods to keep track of when an item is visible on the screen:

Let’s start by wrapping renderItem function with a provider to share the item’s index:

function usWrappedRenderItem({ renderItem, listId }) {
  
  // Wrap list items with a provider surfacing the index of the item
  return useCallback((args) => (
    <ListItemVisibilityProvider listItemVisibilityIndex={args.index} listId={listId}>
      {renderItem(args)}
    </ListItemVisibilityProvider>
  ), [renderItem]);
}

All children within this function can now access their index within the list & the listId:

const { index, listId } = useListItemVisibility()

Next let’s wrap the onViewableItemsChanged callback:

 function useVisibilityTracker({ onViewableItemsChanged, listId }) {

  // 1. Keep track of mounted list
  useEffect(
    function trackListVisibility() {
      visibilityTracker.registerList(listId);

      return visibilityTracker.removeList(listId);
    },
    [listId],
  );

  // 2 Update visible items when array of visible items changes
  const updateVisibleItems = useCallback((visibleIndexes: Set<number>) => {
    visibilityTracker.setVisibleItems(listId, visibleIndexes);
  }, [listId]);

  // 3. Debounce to avoid rapid-fire updates while scrolling
  const debouncedUpdateVisibleItems = useDebouncedCallback(updateVisibleItems, 150);

  // 4. Return the wrapped onViewableItemsChanged callback
  return useCallback((event: { viewableItems: ViewToken[]; changed: ViewToken[] }) => {

    // Call the original callback first
    onViewableItemsChanged?.(event);

    // Get visible indexes
    const { viewableItems } = event;
    const visibleIndexes = new Set(
      viewableItems.filter(({ isViewable }) => !!isViewable).map(({ index }) => index),
    );

    debouncedUpdateVisibleItems(visibleIndexes);
  }, [debouncedUpdateVisibleItems, onViewableItemsChanged]);
}

And finally, use this in our lists:

const wrappedRenderItem = useWrappedRenderItem({
    renderItem,
    listId: 'MyList',
});

 const wrappedOnViewableItemsChanged = useVisibilityTracker({
    onViewableItemsChanged
    listId: 'MyList',
});

return (
  <FlashList 
    renderItem={wrappedRenderItem}
    onViewableItemsChanged={wrappedOnViewableItemsChanged}
    ...

With this,  we effectively gave our list items full visibility context, so we can use this to prefetch our data like so:

function PrefetchListItemOnVisible({
  children,
  prefetchQuery,
}) {
  const visibilityTracker = ListVisibilityTracker.getInstance();
  
  // from wrappedRenderItem
  const { index, listId } = useListItemVisibility();

  // Subscribe on mount
  useEffect(() => {
    visibilityTracker.subscribe('listId', (visibleIndexes) => {

      // Item index is not in the viewport, return
      if(!visibleIndexes.has(index)) return;

      // Item is in the viewport, prefetch !
      prefetchManager.process(prefetchQuery);
    });

    return () => visibilityTracker.unsubscribe();
  }, []);

  return children;
}; 

The hard part is done, and what’s next is we have  scroll-aware viewport context and can prefetch data accordingly.

Backend strain:

Even when fetching only visible data, this can still mean hundreds of requests per user, multiplied across hundreds of thousands of users.

It’s queue time 

An on-device queue gives us flexibility and safety, we can add delay, max concurrent requests & even a set maximum request per minutes:

We also can set these queue options based on device class: A last-gen iPhone Pro can prefetch hundreds of queries in seconds, but a low-end Android phone will start struggling almost immediately.

Killswitches

Even the most moderate queue settings and conservative visibility tracking can’t avoid overfetching entirely: We added fine-grained killswitches by defining “Triggers,” e.g. Link to a screen & “Target” e.g. The screen.

If our profile backend sees an abnormal strain from prefetching, we can disable specific prefetching flow like “search results → profile”, or disable profile prefetching entirely.

Now that frontend won’t overfetch, and we have multiple mitigations in place for our backend. Time for the elephant in the room: DevX

🐘 DevX

We have 20+ classes, components, context, helpers, hooks. How can we make the process of implementing prefetching easy?

Solution: a single API for prefetching target & triggers:

function createPrefetchableComponent( { query, prefetchTarget, options }, Component) {

  // Wraps "target" component
  const PrefetchableComponent = memo(function PrefetchableComponent({ variables }) {

    // Fetching & refresh methods
    const queryRef = useLazyLoadQuery(query, variables, options);
    const { refresh, isRefreshing } = useRefreshQuery(query, variables);

    const props = { queryRef, refresh, isRefreshing, variables };

    return <Component {...props} />
  });

  // Attach the Trigger component with the query & prefetchTarget
  PrefetchableComponent.TriggerComponent = memo(function TriggerComponent({ children }) {
    return <PrefetchObserver prefetchQuery={query} >{children}</PrefetchObserver>;
  });


  return PrefetchableComponent;
}

Note: This is a heavily simplified snippet, in practice it’s a typescript fiesta.

Then use this to wrap our prefetchable components:

const PrefetchableProfile = createPrefetchableComponent({ 
  query: profileQuery,
  prefetchTarget: 'profile'
}, function Profile({data, refresh}) {
   
   // ...

})

And finally around our triggers:

 function ProfileLink({ children, profileId }) {
  const navigateToProfile = useCallback(() => {
    navigate('Profile', { profileId });
  }, [profileId]);

  return (
    <PrefetchableProfile.TriggerComponent variables={{profileId}}>
      <Pressable onPress={navigateToProfile}>
        {children}
      </Pressable>
    </PrefetchableProfile.TriggerComponent>
  );

Add a couple AI rules and context on top, and implementing prefetching becomes one-shotable.

Results

Smooth UX

Previously, navigating between tabs led to a shimmer fest:

With prefetching enabled, navigation & rendering is instant:

We added debugging tools to let us “see” the prefetching in action

Performance

We measure our app’s performance via a unified scoring system introduced at Coinbase:

• NTBT: Navigation Total Blocking Time

• ART: Above the fold Rendering Time

• TRT: Total Rendering Time

Together, these metrics capture how quickly users can interact, see initial content, and view the fully loaded screen.

See performance comparison results on High End devices:

NTBT: -80-100%

The data is available in cache, no suspense is triggered and navigation is instant

| Screen        | Before | After | Diff (%) |
|---------------|--------|-------|----------|
| Search        | 44     | 0     | -100%    |
| Transact      | 183    | 25    | -86.3%   |
| Notifications | 48     | 0     | -100%    |
| Wallet        | 126    | 38    | -69.8%   |
| Profile       | 229    | 0     | -100%    |

TRT & ART: -70-80%

We skip the loading steps entirely, the screen renders near-instantly in its final state.

| Screen        | Before | After | Diff (%) |
|---------------|--------|-------|----------|
| Search        | 283    | 33    | -88.3%   |
| Transact      | 765    | 141   | -81.6%   |
| Notifications | 447    | 127   | -71.6%   |
| Wallet        | 849    | 128   | -84.9%   |
| Profile       | 511    | 94    | -81.6%   |

We saw similar results on low end devices

NTBT: -60%

The data is available in cache, but de-serialization is still expensive on low end devices.

TRT & ART: -40%

Rendering is faster but still expensive on low end devices.

Try it out today

Download the Base app and experience instant, seamless navigation for yourself—no shimmers, no waiting, just the onchain everything app the way it's meant to feel.

Appendix: Rendering, Tech Stack & RN New Architecture

Curiously, a few screens remained stubbornly slow even with prefetching enabled. What's going on?

All our investigations pointed to the same conclusion: Our stack was aging.

Running React Native 0.77.3 in legacy mode meant missing out on bug fixes & new features.

The New Architecture, its flashy new Fabric UI rendering engine and bridgeless native call should also streamline rendering.

But more importantly, it blocked us from upgrading third‑party libraries like FlashList V2, Reanimated V4, and many others that have already moved to the New Architecture.

In theory, it’s just a matter of switching a flag somewhere in the app config:

-newArchEnabled=true
+newArchEnabled=false

Sounds easy enough right?

Subscribe to the Base Engineering Blog & stay tuned for more on the New Architecture.

We recently launched a bridge between Base and Solana, enabling token transfers and arbitrary message passing between the chains. This post details the architecture, the engineering constraints that influenced our design choices, and our roadmap for future improvements and decentralization.

Why Build a Bridge?

To build a global economy, we need to make it dead simple for people to move assets at the speed of the internet and tap into liquidity across every chain. While the Ethereum ecosystem is already a highly interconnected web of L2s, a canonical connection to chains outside this ecosystem has been missing.

Our first step is unlocking access to Solana, a network with over $8B TVL and $5B in daily trading volume. There are existing bridging options between Base <> Solana operated by unaffiliated third parties, so why invest in building a bridge?

We believe there is value in solving this problem at the protocol level in Base. Existing third party protocols compete for blockspace in the public mempool, subjecting them to variable costs and latency constraints. Adding native interop within Base allows us to:

• Introduce canonical Solana asset representation within Base, and canonical Base asset representation on Solana.

• Lower costs, as the native bridge does not need to charge a protocol fee outside of covering existing gas costs.

• Index finalized Solana state in real time for lower latency.

• Own the security properties affecting cross-chain assets.

Bridge Design

We designed the bridge as a low-level primitive, taking inspiration from the native bridge between Base and Ethereum. It is asymmetric by necessity, leveraging the unique strengths and working around the constraints of both chains. Supported actions include token transfers, arbitrary function calls, and combinations of the two.

System Properties

Token Bridging

Before bridging a source chain asset, a corresponding token wrapper must be created on the destination chain. These wrappers are tokens owned by the bridge, granting the bridge the exclusive permission to mint and burn them as assets move across the network.

This mechanism creates a ‘lock and mint’ concept. First, source chain assets are locked in a bridge-owned vault; the bridge then mints an equivalent amount of wrapped tokens on the destination chain for the user. Then to bridge back, the destination chain wrapped tokens are burned, which triggers the unlocking of the original assets from the source vault.

Latency

End-to-end latency is strictly bound by source chain finality and oracle verification overhead.

• Solana → Base: Latency is dictated by Solana's finalized commitment level. Messages are not processed until a supermajority of the validator set (66%+) confirms the slot, ensuring reorg protection (approx. 15 seconds).

• Base → Solana: Latency is bound by Ethereum L1 finality. State updates are propagated only after the sequencer batch is posted to Ethereum and the L1 block reaches finalized status (approx. 15 minutes).

Fees

Cross-chain bridging presents a fundamental resource pricing challenge: executing a transaction on the destination chain requires paying for blockspace in that chain's native asset, but the user initiates the action on the source chain.

In our existing canonical system, deposits from Ethereum to Base are automatically included by the sequencer, whereas withdrawals from Base to Ethereum require users to manually prove and execute the transaction on L1.

We designed the Solana bridge to follow this exact pattern:

• Solana → Base: This path functions like a deposit. The protocol guarantees the ability to execute on Base by pre-validating the transaction. The bridge collects a fee to cover the cost of this submission. Users can optionally pay for automatic relaying by specifying a gas limit as well. The exact fee collected is derived algorithmically via a mechanism adapted from Ethereum’s EIP-1559.

• Base → Solana: This path functions like a withdrawal. The protocol propagates state roots but does not perform execution. Users or third-party solvers are responsible for submitting inclusion proofs and paying the requisite SOL gas fees directly on Solana. No in-protocol fee is required.

Architecture

The bridge relies on two primary onchain deployments: a monolithic Anchor program on Solana and a set of modular smart contracts on Base. It also relies on offchain validators operated by Coinbase and Chainlink.

Solana Architecture

On Solana, we deployed a single Anchor-based bridge program as the gateway for all cross-chain activity. This program handles three critical functions.

• Message Egress: Creates discrete OutgoingMessage accounts for every action targeting Base.

• State Verification: Maintains a registry of valid Base roots and verifies inclusion proofs for incoming messages.

• Asset Custody: Manages Program Derived Addresses (PDAs) that act as vaults for locked SPL tokens and holds the mint authority for wrapped Base assets.

Base Architecture

On Base, we chose a modular system to handle EVM state management and execution complexity:

• Bridge: The central hub. Handles message ingress/egress, holds locked assets (ETH and ERC20s), and controls minting/burning of wrapped Solana assets.

• BridgeValidator: Verifies batches of messages from Solana before execution.

• Twin: A deterministic execution context for Solana users, allowing interactions with Base dApps without managing a separate EVM key.

• CrossChainERC20Factory: Deploys and manages canonical wrapped representations of Solana tokens.

Offchain Architecture

We operate a custom indexer to tie the onchain components together. This service monitors the state of both the Solana program and the Base contracts. When a state transition occurs (e.g., an outgoing message is emitted), the oracle:

1. Indexes the event data from the source chain.

2. Requests signatures from the Chainlink Decentralized Oracle Network (DON) and our internal validators.

3. Relays the signed state to the destination chain.

Flow Diagrams

Solana → Base Bridging

1. A user calls the Bridge program on Solana.

   • Note that because the calldata required for an EVM transaction can easily exceed the transaction size limits on Solana (1232 bytes), this can optionally be broken into multiple steps where the calldata is loaded into a temporary buffer account before initiating the bridging flow.

2. The program locks funds in a PDA vault and initializes an OutgoingMessage account containing the execution payload.

3. The Base oracle indexes the new OutgoingMessage account.

4. The oracle computes the message hash and requests ECDSA signatures from Base and Chainlink validators.

5. The oracle submits the message and validator signatures to the BridgeValidator contract on Base.

6. A relayer or user calls the Bridge contract to execute the message.

7. The Bridge contract verifies pre-validation in BridgeValidator and executes the payload.

Base → Solana Bridging

1. A user calls the Bridge contract on Base.

2. The contract appends the encoded message to an onchain Merkle Mountain Range (MMR) data structure.

   • We chose an MMR because it generates compact inclusion proofs that fit easily within Solana’s transaction size limits. It is also highly efficient to maintain; appending to the structure on Base costs less than 1/10th of a cent, and we won't hit Solana’s size constraints until the tree reaches ~17 billion nodes.

3. The Base oracle detects a new MMR root at a finalized block height.

4. The oracle requests ECDSA signatures for the new root from Base and Chainlink validators.

5. The oracle submits the signed root to the bridge program on Solana.

6. A relayer or user generates an inclusion proof against the updated root (via Bridge.generateProof).

7. The relayer or user submits the inclusion proof to Solana.

8. The program verifies the proof and executes the message.

Security

The bridge was designed with security as a top priority to ensure solvency and safe bridging. While building the bridge, several invariants we viewed as foundational were:

• Solana → Base: Transactions executed on Base match a deposit on Solana

• Base → Solana: 

  • State roots posted on Solana match those derived on Base

  • Withdrawals proved against state roots match a transaction on Base

• The amount of minted wrapped tokens on any chain cannot exceed the amount of locked tokens on the opposite chain

To increase our confidence in the bridge’s security, we conducted: 

• Internal audits of the codebase that spanned from the design phase to deployment

• A threat model and evaluated design trade offs

• Penetration tests on the infrastructure

• Extensive external audits by

  • Cantina for the smart contracts

  • Trail of Bits for the oracle

• Unit tests and end-to-end tests of all important workflows

As the current design involves a centralized oracle, we worked towards mitigating risks produced by this component until decentralization is achieved.

As explained in the design, one of the novel aspects of this bridge is the use of a Merkle Mountain Range for state roots instead of a traditional Merkle tree. Our own cryptography team worked with our internal auditors to find hash collisions and write a proof that the current implementation is sound.

We also have several monitors set up to alert us of anomalous behaviour or broken invariants, such as

• Unexpected deposits/withdrawals 

• Discrepancies between the locked amount and minted amount of a bridged token

• Any privileged function call

• Delayed or failed transactions by the oracle

• Changes to our bridge partner’s smart contracts or API availability 

Runbooks were also created to prepare our team for incident response. These cover escalation paths and playbooks for specific scenarios from on-chain hacks and transaction discrepancies to off-chain oracle outages and partner availability.

Key Management

Bridge exploits frequently occur due to key compromise, so we implemented a separation of concerns for the private keys involved with the operation of the bridge:

• Configuration keys: Controlled by a multisig for parameter changes and emergency pauses

• Upgrade keys: Separate multisig with different owners for contract upgrades

• Signing keys: Used to sign messages between Base and Solana. These are split between Coinbase and Chainlink infrastructure, requiring signatures from both parties

Each of these operations have designated independent multisignature accounts with at least a 3-of-5 threshold. In particular, as the signing keys are particularly critical to bridge operations, our partnership with Chainlink ensures that the keys are distributed among separate infrastructure, so compromising either party alone cannot move funds.

To decrease the risk exposed by these keys, our vision is to decentralize as much as possible so that the trust model is similar to our current bridge between Ethereum and Base, as explained in the next section.

Decentralization Roadmap

While the distributed validator set gives us good security properties, our preference is to explore cryptographic unlocks enabling a future system secured only by the consensus of Solana + Ethereum.

The transition to a fully trust-minimized bridge, we’re thinking in three phases, beginning with the current Proof-of-Authority model secured via independent validator attestations. Subsequent phases will detail efforts toward protocol enshrinement, integrating verification logic for improved efficiency, and the long-term goal of the ZK Prove architecture, which seeks to achieve full decentralization by replacing attestations with cryptographic proofs of consensus.

Phase 1: Proof-of-Authority (Current State)

We secure Phase 1 with a shared responsibility model requiring independent attestations from two parties: an oracle run by Base and the Chainlink DON.

The Chainlink DON attestation currently operates with a 3-of-5 multisignature scheme, and our plan is to increase to a 9-of-16 threshold in the near future. Both the Base oracle and the Chainlink DON must attest to a message for successful processing.

Validator operators maintain two distinct secp256k1 keypairs to generate ECDSA signatures—one dedicated to Base and another to Solana. We enforce this key isolation to ensure that a compromise of a validator's key on one chain does not put the other chain at risk. For tracking these addresses, Chainlink manages an onchain registry (a smart contract on Base and a program on Solana) where these chain-specific public keys are registered. Our bridge contracts query these registries dynamically to verify signatures.

Solana → Base Validation

For transactions moving from Solana to Base, the Base Oracle and Chainlink validators verify message batches before they are relayed to our BridgeValidator contract.

1. The Base oracle calls the Chainlink API with an array of message hashes corresponding to OutgoingMessage accounts on Solana.

2. Validators confirm that every message hash in the batch corresponds to a valid OutgoingMessage account created by the Solana bridge program.

3. Once verified, validators generate an ECDSA signature over the Keccak-256 hash of the tightly packed array of message hashes (keccak256(abi.encodePacked(messageHashes))).

4. The Chainlink API collects the required threshold of signatures and returns them to the Base oracle, which submits the batch onchain in a single transaction.

Base → Solana Validation

As mentioned above, the process for validating transactions from Base to Solana uses an MMR to represent the state of the bridge, which helps keep proofs under Solana’s transaction size limit.

1. The Base oracle fetches the latest MMR root, the associated Base block number, and the MMR leaf count from the getRoot function on the Base bridge contract.

2. Chainlink validators verify that the proposed Base block number is finalized and that the output root proposed by the oracle matches the onchain state.

3. Validators provide an ECDSA signature over the Keccak-256 hash of the concatenated MMR root, Base block number, and MMR leaf count.

4. The Base oracle collects these signatures and includes them in the register_output_root transaction it submits to the Solana bridge program.

Phase 2: Enshrinement

Phase 2 improves cost and latency by moving verification logic into the protocol layer. Rather than verifying Solana messages via smart contracts, we modify the Base protocol to natively index Solana data.

We plan to utilize a component analogous to the Optimism Superchain's op-supervisor. This service ingests OutgoingMessage accounts from Solana and forwards them to the execution engine, enabling nodes to verify cross-chain transactions natively.

However, native indexing introduces a security paradox. Base derives its security from Ethereum via an optimistic fault proof system. This system is capable of verifying state transitions because it has access to all needed inputs on L1 (deposits and blobs). Since L1 has no visibility into Solana's state, it cannot verify the validity of transactions derived from natively indexed Solana data.

To resolve this, we must make Solana state available on Ethereum. We introduce a State Prover service that posts Solana state representations to L1, allowing the fault proof system to verify inclusion proofs against a trusted root.

Solana's architecture complicates this. Unlike EVM chains, Solana does not include a global state root in its block header. To bridge this gap, we run a sidecar to Solana validator nodes that computes a merklized root of the bridge state. In Phase 2, Chainlink and Base validators attest to this derived root.

For the Base → Solana path, we integrate op-enclave, a relatively small modification to the op-stack that proves state transitions in an AWS Nitro Enclave and outputs the resulting state root. This removes the need for the 7-day challenge period and allows for immediate withdrawals. The State Prover relays these roots to Solana accompanied by the TEE proof, eliminating the need for validator attestations in this direction.

We intend to modify op-enclave to prove the bridge MMR root directly, rather than the entire Base state root, preserving the existing client-side proof interface.

Phase 3: ZK Prove

We are sharing our current thinking to provide transparency into our long-term roadmap towards fully trust-minimized architecture, though we have not yet committed to specific design choices. We welcome any and all feedback on the following.

The objective of Phase 3 is to remove the need for validator attestations entirely. Instead, we aim to rely solely on cryptographic proofs of consensus.

The primary engineering constraint is verifying Solana's consensus rules within the EVM's resource limits. Solana currently operates with 400ms slot times and a large validator set, requiring the verification of thousands of Ed25519 signatures per block. Replicating this logic directly in a solidity smart contract is gas-prohibitive due to the lack of cheap Ed25519 precompiles and the prohibitive cost of calldata for the signatures.

We are investigating a ZK-based approach to compress this verification. The proposed system would utilize a ZK circuit to ingest Solana block headers and aggregate signatures, outputting a succinct proof of the valid state root.

For the Base → Solana path, we propose leveraging the output roots Base already posts to Ethereum. Since verifying Ethereum consensus via ZK is a well-understood problem space, we aim to submit Base roots to Solana accompanied by two proofs:

1. Consensus Proof: Verifies the Ethereum state root.

2. Storage Proof: Proves the inclusion of the Base output root within that Ethereum state.

A critical open question is the latency of this path. Under the current optimistic fault proof system, Base output roots on Ethereum are subject to a 7-day challenge period. Waiting for this finality would degrade the bridge experience significantly (15 minutes → 7 days). Thus, this design assumes Base has a future as a zk-rollup where time to finality is far lower.

Looking Forward

The Base-Solana bridge is live on mainnet today. We invite you to learn more in our docs and Github repo and share your feedback.

We'll continue to push the limits of what is possible. We envision Base as the central hub of the global economy, with native ability to interop with all major chains–Solana is only the beginning. If you're interested in working on the hardest problems in the industry, we're hiring, and we'd love to hear from you.

Follow us on social to stay up to date with the latest: X (Base team on X) | Farcaster | Discord

Payments are one of the most exciting areas in crypto today, but the actual experience of paying with crypto leaves a lot to be desired. Generally, it is a two to three step process, requiring a user to switch context between their wallet and the app where they are paying multiple times:

1. Connect wallet

2. Switch network (if needed)

3. Sign 

Crypto payments are constrained by wallet APIs and UX patterns that were built for a different era: one in which users were connecting a wallet to an app for a long lived session. For onchain payments to succeed at scale, we must provide something far simpler. 

Today, we're excited to introduce a new standard for one-step crypto payments. It's built on open standards that are available to anyone, ready to be adopted industry-wide. Try it on Shopify today using Base Pay here, and start building with it here.

There are three innovations powering this experience:

1. Prolinks

2. Stateless Interactions

3. Callbacks

Let's dive into each.

1. Prolinks

Prolinks are a new standard (ERC-8050) for representing JSON-RPC requests in a highly compressed URI.

There have been several previous attempts to standardize a URI format for wallet requests. However, past ERCs have been too opinionated, e.g. assuming that the URI represents a transaction. 

Prolinks are generic: allowing communication about any existing or future wallet APIs. They are also size efficient, leveraging protocol buffers and Brotli compression. 

2. Stateless Interactions

This simplified payments flow also requires wallet APIs that can function without an existing app connection. Historically, wallets will reject API calls like eth_sendTransaction if the user does not have an existing connection to the app. For one-time interactions like payments, this leads to a very cumbersome experience of having to connect and pay as separate steps. 

EIP-5792’s wallet_sendCalls dropped the requirement of a from address, allowing apps to make transaction requests without knowing anything about the user. This leads to better experiences and is also more privacy friendly. 

wallet_sign (ERC-7871), used by Base Pay on Shopify, works the same way; users can skip the unnecessary setup and pay immediately

3. Callbacks

Finally, the wallet needs a way to share info (e.g. status updates, transaction hash, signed data, etc.) back to the app. The web2 world has a time-tested solution: callbacks. 

We bring callbacks into the onchain world via a new EIP-5792-compliant capability: data callback. (This is the same capability powering our Profile feature for Base Account!) 

Start building with Base Pay 

Try the new Base Pay experience here, and start building with the developer playground here. We’re excited to collaborate with other wallets and payment providers to see these standards improved and adopted.

Follow us on social to stay up to date with the latest: X (Base team on X) | Base App | Discord

TLDR: With the Fusaka upgrade scheduled to go live on Ethereum mainnet on December 3, the core dev community has now shifted their attention to deciding which EIPs to include in the next upgrade: Glamsterdam. The Base engineering team is most excited by six EIPs that fall into three categories: blob scaling (EIP-8070), gas repricing (EIP-2780 and EIP-8032), and builder UX improvements (EIP-5920, EIP-7907, and EIP-8024).

Upgrades to the Ethereum L1 can have major benefits for users and builders on Base. For example, the Fusaka upgrade will enable an 8x increase of blobs on a scheduled and safe basis via PeerDAS and BPO hardforks. This increase in blob capacity will provide Base and other L2s with the data availability (DA) capacity necessary to continue to scale and support more users and builders coming onchain. 

The next Ethereum upgrade, Glamsterdam, is expected to hit mainnet in 2026. The headliner EIPs for Glamsterdam are EIP-7732: Enshrined Proposer-Builder Separation (ePBS) and EIP-7928: Block-Level Access Lists, which will support increased blob capacity and more efficient execution performance, respectively. The Ethereum core dev community is now in the process of submitting their support for the non-headliner EIPs they would like to see included. 

From the list of nearly 50 non-headliner EIPs proposed for inclusion, we have boiled our list down to six that we see as most promising. The EIPs we are most excited about fall into three categories: blob scaling, gas repricing, and builder UX improvements. It’s important to note that exclusion from the list below does not mean we are necessarily against any EIP; however, we do share the concern raised by EthPandaOps and others during the November 13 All Core Devs call that if EIP-7805: Fork-Choice Inclusion Lists (FOCIL) is included in Glamsterdam, the complexity and unknowns of testing it alongside ePBS could delay the upgrade beyond 2026. While we do not think we should introduce further complexity and risk to Glamsterdam by including FOCIL, the censorship resistance properties FOCIL will bring to Ethereum are important for all users and we hope FOCIL will be prioritized in a future upgrade. 

Blob scaling

As we covered above and in our scaling blog from last month, blobs play an important role in scaling the Ethereum ecosystem. When blob usage is consistently saturated, L1 DA can become a bottleneck for L2s such as Base to support more onchain activity. 

Both PeerDAS and Glamsterdam’s consensus layer (CL) headliner, EIP-7732, will support an increasing blob target; however, as the blob target begins to grow beyond 48/block, the execution layer (EL) blobpool is expected to become the primary consumer of a given node’s bandwidth. EIP-8070 will address these bandwidth concerns.

EIP-8070: Sparse Blobpool (spec)

What is EIP-8070?

Similar to how PeerDAS allows for sampling of blob data on the CL, the Sparse Blobpool EIP will allow for cell-level, custody-aligned sampling on the EL. This EIP would reduce the probability of an EL node sampling a full blob payload to p = 0.15. This means EL nodes have a p = 0.85 probability of sampling the same custody assignment as their CL counterpart and downloading as little as 1/8 of the blob data. Altogether, this is expected to reduce the average bandwidth consumption of the blobpool by ~4x.

Why is EIP-8070 important?

Ensuring that both the CL and EL can support higher blob targets is important for Base and Ethereum to continue to scale and support more usage. As stated by the EIP’s authors, the EL blobpool dominated average bandwidth consumption on full nodes in Fusaka devnets with high blob targets. This raises the concern that block and attestation propagation will not have enough bandwidth left to consume. If block and attestation propagation lack proper bandwidth, network liveness and stability could be put at risk, which would make raising the blob target any further a nonstarter. 

Gas repricing

Gas mispricings are one of the biggest issues for scaling Base today, since execution client performance is bottlenecked by needing to efficiently build any block. A block full of the most mispriced opcodes can create major strain on performance due to the requirement for sequencer and validator nodes to be able to handle the worst-case. These worst-case blocks greatly limit how high we can scale. 

Glamsterdam’s gas repricings intend to more accurately set gas costs with the goal of reducing the impact of scaling bottlenecks created by mispricings and inefficient gas models. These repricings are organized in a meta-EIP: EIP-8007. While there are many interesting proposals in the EIP-8007 directory, EIP-2780 and EIP-8032 strike us as the most impactful for Base Chain.

EIP-2780: Reduce intrinsic transaction gas (spec)

What is EIP-2780?

As its title suggests, EIP-2780 reduces the intrinsic base cost of a transaction from 21,000 to 4,500, which would make the gas cost of a simple ETH transfer 6,000. In addition, this EIP introduces GAS_NEW_ACCOUNT which charges an extra 25,000 when a transfer targets an empty account (i.e. more accurately charges for the state growth caused by account creation) and refines gas accounting around cold/warm account reading and writing. 

Why is EIP-2780 important?

EIP-2780 will make simple ETH transfers less expensive for Base users in addition to allowing for more of them in a given block. In addition, the GAS_NEW_ACCOUNT portion of this EIP will allow for more accurately priced account creation on Base Chain (assuming its value can be tweaked at the L2 level), reducing potential scaling bottlenecks.

EIP-8032: Size-Based Storage Gas Pricing (spec)

What is EIP-8032?

EIP-8032 intends to help with state bloat concerns by dynamically pricing SSTORE operations based on a given contract’s storage size. In doing so, this EIP more accurately aligns storage write costs with the work EVM clients perform. In addition, this EIP uses an activation threshold parameter to ensure that the progressive increases to storage writes only impact extremely large contracts. 

Why is EIP-8032 important?

The current gas pricing model is not accurately tuned for contracts with large storage size, leaving both Ethereum mainnet and Base susceptible to state bloat often caused by contracts intended for low-cost data anchoring and spam. These types of contracts increase state root calculation time, creating a scaling bottleneck that penalizes normal usage of our network. By adjusting the gas pricing model to capture the O(log(n)) cost of storage root calculation, Base can continue to scale for normal usage by builders and users.

Builder UX improvements

Builders are foundational to Base. With this in mind, it is important to us to ensure our builders have a secure and smooth experience building on Base Chain. EIP-5920, EIP-7907, and EIP-8024 will help improve this experience.

EIP-5920: PAY opcode (spec)

What is EIP-5920?

EIP-5920 introduces a new PAY opcode that can be used for ETH transfers without the need to call into the recipient address. 

Why is EIP-5920 important?

This will benefit builders who need to transfer ETH to their contracts by removing the need to call into the recipient address and transfer execution context to that address. This change will remove a major reentrancy vector and reduce security considerations for our builders. 

EIP-7907: Meter Contract Code Size and Increase Limit (spec)

What is EIP-7907?

EIP-7907 increases both the contract code size limit (from 24KB to 48KB) and the initcode size limit (from 48KB to 96KB). In addition, it introduces gas metering (4 gas per 32 bytes above 24KB) to prevent a potential DoS vector via these larger contracts.

Why is EIP-7907 important?

EIP-7907 would allow our builders to deploy more complex logic in a single contract. Our builders have given us feedback that the current code size limit is too restrictive and requires them to break their more complex contracts into multiple smaller contracts. This practice introduces additional technical complexity and is also gas inefficient due to the necessity of cross-contract calls.

EIP-8024: Backward compatible SWAPN, DUPN, EXCHANGE (spec)

What is EIP-8024?

EIP-8024 introduces three new instructions: SWAPN, DUPN, and EXCHANGE. These instructions allow compilers to access deep stack items below the depth of 16 currently supported by the SWAP* and DUP* instructions.

Why is EIP-8024 important?

Once these new instructions are supported in solidity compilers, they will reduce the occurrence of stack too deep errors, which in turn will relieve friction for smart contract developers and make smart contract development more approachable for newer Solidity developers. 

Conclusion

Base is excited to see Ethereum continue to improve with next year’s Glamsterdam upgrade. We believe EIP-8070, EIP-2780, EIP-8032, EIP-5920, EIP-7907, and EIP-8024 are the most impactful for our users and builders. 

If you are a Base user or builder and have other EIPs you think would be impactful to you, please let us know and show your support on the relevant Ethereum Magicians thread. Another resource we recommend checking out is Forkcast, a great tool developed by the Ethereum Foundation to provide an overview of a given upgrade’s EIPs and the Ethereum upgrade process more generally.

As Base grows, we’re seeing more onchain activity than ever before, with an all-time high of 15.4M+ transactions recorded this week. To meet growing demand, we’re significantly investing in scaling efforts:   for example, this month alone we’ve doubled Base Chain’s capacity.

To scale safely, we must anticipate any performance challenges that could arise ahead of time so we can keep growing without bottlenecks. To accomplish this, we built Base Benchmark: a new Ethereum L2 benchmarking tool, which simulates running the chain at higher loads to identify bottlenecks in the execution client.

Why did we build Base Benchmark?

The biggest scaling challenge we face today is execution speed. Many variables can affect execution speed, such as machine size, available cache, and client implementation. Additionally, transaction patterns vary widely across blocks, so a hardware setup that works perfectly for one CPU-bound workload may not work as well for a storage-bound workload. Also, different precompiles, storage operations, and transaction types can lead to variable performance across clients. 

When we increase Base Chain’s gas limit, we need to ensure the network continues to run smoothly and transactions are processed quickly for everyone. This means ensuring that the gas limit we plan to scale to is safe across all traffic types and patterns, and that we have a good understanding of the recommended hardware configurations for nodes. As we scale, the chain must remain resilient to processing spam and other resource intensive transactions.

We needed a way to test the worst case blocks under various conditions. Unfortunately, testnets aren’t sufficient for simulating worst case conditions because state size (the size of all accounts/contract data deployed on the blockchain) has a huge impact on storage performance, and testnets generally don’t have the same state size as mainnet.

We considered various alternatives, but none offered the automation and flexibility that we wanted in a blockchain performance testing tool.

• Spamoor, contender, tx-fuzz: These tools allow generating a transaction workload, but don’t handle setting up the network and collecting metrics. We designed Base Benchmark to allow running these as external transaction generators. 

• Kurtosis: This sets up an L1 blockchain to run transaction spammers against, but we wanted an automated and lightweight mechanism to setup and teardown hundreds of test chains quickly.

• Bloatnet: This is a public test network with a large amount of state, allowing storage opcodes to be more accurately tested. However, we want to test with an actual Base Mainnet snapshot. Results weren’t ready as of the time of this blog post.

Since no existing tools fulfilled all the requirements enabling us to scale safely and efficiently, we built our own tool.

Base Benchmark

Base Benchmark is our tool for testing Ethereum client performance against various transaction workloads.

With Base Benchmark, a user defines a benchmark suite to run. We allow testing various gas targets, transaction payloads, clients, and tuning options. Each combination of these runs a block builder that accepts transactions from RPC and builds blocks using the engine API, along with a verifier which accepts built blocks and applies them to the chain state.

Importantly, Base Benchmark also supports running benchmarks from a snapshot, building blocks on top of an existing chain like Base Mainnet. This allows us to quickly test storage operations against a database with a large state size.

Base Benchmark helps client developers and anyone who runs L2 nodes measure performance. It can answer questions like:

• How fast can the sequencer build blocks?

• How fast can validators validate those blocks?

• How fast can we prove execution of a block?

• What are the slowest precompiles/opcodes in Reth?

• How much performance gain will I see after a specific optimization is made?

Let’s take a look at some of the ways Base Benchmark can be used to measure and compare client performance.

Use Case 1: Comparing performance of Ethereum clients

Base is in the process of moving from mostly running Geth to mostly running Reth. Unlike Geth, Reth syncs blocks in stages, and stores less data, which makes it faster in many cases.

To compare client speeds we ran a simple benchmark on different cloud instance types, using a chain with no state and mimicking the opcode and storage distribution of Base mainnet. The benchmark tool will run a benchmark for each combination of parameters. This was intended as an approximate simulation rather than an  accurate comparison. The results for one of the transaction payloads is shown below.

The results page is a great starting point for understanding overall performance and notice any issues that warrant deeper investigation.

For each test case, the benchmark tool first builds blocks by sending transactions to a sequencer. We measure how fast the sequencer can accept incoming transactions. After a certain gas limit, the sequencer stops accepting transactions and builds smaller blocks. This helps us understand the limits of our sequencer under conditions very close to what we would see on Base Mainnet.

After sequencing the blocks, the blocks are then tested for syncing speed by sending them to a separate validator node. The validator node has to do the work of executing the block, but can skip the mempool work that the sequencer already did. This helps us test how fast external nodes other than the sequencer can process transactions. We run our sequencer on a large server to be able to handle the sequencing workload, but we don’t expect everyone to run Base on such a large server. 

💡This testing is critical to ensure we scale with accurate measurements of the limitations of validator nodes run by teams outside Base.

In this test, Reth outperforms Geth. The actual benchmarks we use are more complicated and still in development, but this shows how the tool can be used to compare Ethereum L2 client implementations.

Use Case 2: Comparing machine instance types

Another question we often get is: what is the optimal node configuration for my validator node? Base Benchmark helps answer this by providing a consistent workload to benchmark against.

For this test, we ran our suite of tests against two different instance types: AWS i7ie.48xlarge and GCP z3-highmem-88-highlssd. We can easily compare the metrics of each instance.

Again, this benchmark run is not necessarily indicative of real-world performance, but provides a good relative testing setup for investigating performance issues in clients.

The metrics page shown above allows for comparing the block-by-block performance of each testing setup. This allows node providers to test out performance on various node sizes before switching, and also allows us to ensure that gas limit increases are safe across a range of clients and configurations. This page also includes metrics breaking down how long each phase of block processing took.

Use Case 3: Tuning node parameters like cache size

Finally, we can use this tool to test the performance impact of code and parameter changes. For example, we can test Reth with the SAFE_NO_SYNC flag on MDBX which removes the need for committing to disk in exchange for possibly losing some transactions if the program crashes.

The results of this test showed a negligible difference between the DURABLE and SAFE_NO_SYNC options in Reth. This means there may not be a huge benefit to turning on the SAFE_NO_SYNC option in Reth.

This run shows how the benchmark tool can be helpful for testing out new client features. Reth recently added parallel state root calculation which could be interesting to compare against single-threaded calculation. Base Benchmark should make it easier for client developers to push performance forward.

All of the configuration and results for these tests are available at this link.

How Ethereum can scale faster by identifying DoS risks

In the long run, scaling is all about doing more with less. By reducing risks like DoS vulnerabilities, updates like certain EIPs can unlock higher scaling ceilings, allowing the network to grow faster and serve more users.

For example, in the Dencun hardfork, one change reduced the possibility of slow database operations triggered by the SELFDESTRUCT opcode. By reducing the performance burden of the opcode, Ethereum removed a security risk that was worsened by scaling. The new Base Benchmark tool aims to surface bottlenecks like this so we can get ahead of addressing them to continue scaling Base safely.

Help make Ethereum Faster

With Base Benchmark, our hope is to have a standardized set of benchmarks that we can run for any client to evaluate scaling limits. You can download and run Base Benchmark immediately by following the instructions in the repo.

For node providers running Base, we suggest following our recommended hardware specs and the configuration available in the base/node repo. We encourage you to play around with different hardware specs and configurations using the Base Benchmark tool to measure performance. Our hope is that we can collaborate to improve node configurations so everyone can benefit from performance tuning improvements.

If you are a client developer, we highly recommend implementing the client in Base Benchmark to include it in our testing suite. This will help compare performance of different transaction types against other clients to find performance regressions or optimization opportunities. Once implemented, the client will show up on our public test page.

Anybody else is welcome to contribute to transaction payloads that can be tested, supported nodes and configurations, and metrics to collect. Although we currently support Geth and Reth out of the box, we’d love to expand support to other clients like Nethermind and Erigon.

As part of building in the open, we intend to make our benchmarking results public and share them out as part of our scaling journey and process. Right now, our public test page shows results from a devnet run with no existing state. We’ll soon expand this to include results run on Base Mainnet state. 

If you’re interested in helping us build a global economy that increases innovation, creativity, and freedom, we’re hiring.

Follow us on social to stay up to date with the latest: X (Base team on X) | Base App | Discord

Special thanks to Trent Van Epps (Protocol Guild, Ethereum Foundation), Alex Stokes (Ethereum Foundation), Eli Haims (OP Labs) for reviewing drafts of this blog.

Base’s mission is to build a global economy. To achieve this, we’re committed to continuously scaling Base Chain so it can serve as a platform for billions of people to come onchain. We started 2025 at 10x the scale from when we launched Base Chain a year before, and have since made significant progress towards unlocking more capacity to meet growing demand while maintaining sub-cent transaction fees.

At the beginning of this year, we identified multiple scaling bottlenecks that we’ve been proactively addressing through large scaling projects that are now nearing completion, such as migrating our infrastructure to Reth, optimizing performance with TrieDB, and expanding L1 data availability with PeerDAS.

These projects unlock stepwise performance gains that now enable us to scale Base Chain much more quickly. As a result, in Q4, our goal is to double Base Chain’s gas limit from 75 to 150 Mgas/s.

Our progress thus far

Through the first half of 2025, we performed scaling increases on Base Chain nearly every week. As a result, we saw median fees drop from ~30 cents per transaction to fractions of a cent. In mid-Q2, we paused these increases to ensure chain stability and focus on the longer-term scaling efforts that promised to unlock larger scaling gains.

In the past several months, Base has continued to grow: more breakout apps have emerged, bringing 10x more onchain activity to the network. In June 2025, Base Chain successfully handled periods of up to ~1,500 transactions per second with median fees of under 5 cents.

During this time, we reflected on how proactively increasing Base Chain’s gas target ahead of organic traffic can lead to a suboptimal fee market. Therefore, we’re now continuing to scale Base Chain by increasing its gas limit (i.e. maximum capacity) instead of the gas target, since gas limit increases have less impact on the fee market. We reserve gas target increases for when we observe high fees.

As we charge ahead with continuing to scale Base Chain’s gas limit, we provide an update on the progress we’ve made on tackling scaling bottlenecks.

Scaling Bottleneck Review

We have made significant progress towards removing scaling bottlenecks since our last update. As a reminder, we track 4 main scaling bottlenecks: 

• L1 DA: How much data we can post to Ethereum

• Client Execution Speed: How quickly blocks can be built and validated

• Fault Proof Performance: How quickly fault proof games can be played out 

• State and History Growth: How much disk usage nodes are required to maintain

Bottleneck 1: L1 Data Availability

On May 7, the Pectra hardfork went live on Ethereum mainnet, doubling the available blob space. For more than 6 months leading up to this, blobs usage was at capacity; after the hardfork, L2s were able to utilize more space and accordingly settle more onchain activity.

PeerDAS, projected to go live in early December as part of the Fusaka hardfork, represents the next significant advancement for L1 DA. It addresses the challenge of increasing blobs without burdening L1 consensus nodes, by sharding blobs across various nodes.

The implementation of PeerDAS was a huge collaborative effort, with numerous ecosystem teams advocating for its accelerated release (1, 2, 3), effectively reducing the timeline by several months. Fusaka lays the crucial technical groundwork of PeerDAS, without increasing blobs. Once the implementation is observed to be stable, blobs will increase in Blob Parameter Only (BPO) forks, anticipated to land very shortly after.

As a result, we’re on track to more than 2x blobs as an ecosystem by early 2026, which we hope will be sufficient to support Base Chain and other L2’s continued scaling plans in the near future. 

Bottleneck 2: Client Execution Speed

This is our biggest bottleneck today and the focus of several of our active projects. 

To scale safely, we need to ensure that both sequencer and validator nodes are able to build blocks fast enough. These blocks continue to become larger as we scale, and we ideally can build confidence in nodes being able to build these larger blocks before we scale. To solve this, we built a benchmarking tool to simulate block building times at a gas limit we specify, with various traffic patterns. We will share more details on this tool in the coming weeks, but this groundwork illuminated specific performance constraints we needed to address prior to scaling.

Effort 1: Reth Everywhere

We are actively migrating Base Chain nodes from the original default client, op-geth, to our new Base client, based on op-reth, which we have measured to be significantly more performant. We have made notable progress by migrating almost all internal node infrastructure, most recently our sequencer nodes, to Reth.  

The only nodes we still run on op-geth are parts of the fault proof system, however we will be moving to Kona, a Reth-based fault proof program built by OP Labs, after an upcoming Base Chain upgrade, U18, enables this.

Finally, to fully realize the performance improvements of Reth, we need to enable Reth to fetch historical state efficiently, which it currently is not designed to do. We designed an ExEx to improve efficiency, which we are collaborating with OP Labs to finish implementing and rolling out. 

For external validators, we recommend Reth as the default client moving forward.

Effort 2: TrieDB

Over a year ago, when our team benchmarked Reth, we noticed that, while Reth was far more performant than Geth, storage reads and writes were the long tail of execution speed. Speeding these up could provide an 8-10x performance improvement.

As a result, we invested in TrieDB: a project which restructured the database format to make fetching state much faster. We’ve been actively developing this project for several months and are close to having a final version. We have spoken about and open-sourced this project and will be sharing a more detailed technical explainer and timelines soon.

Effort 3: Resource metering and opcode repricing

While TrieDB focuses primarily on improving the speed of storage reads and writes, there are other opcodes that are also mispriced today, compared to the resource load they put on the network. The ideal solution would be to reprice these opcodes across the board. This sounds trivial, but in practice is a massive coordination and execution effort, so we are working on this in parallel to a more immediate solution.

One solution is managing resource usage, or “resource metering”, to ensure that Base Chain nodes remain stable while ensuring that user transactions are quickly confirmed. We already use this today to manage Base Chain's blob usage, the most critical resource that rollups rely on to inherit security guarantees from L1. Optimism is formalizing this in the next OP Stack upgrade by adding in-protocol metering. This allows the congestion management from Ethereum’s EIP-1559 to kick in so users are less likely to experience delays in transaction inclusion.

Separately, we have been working on a new project to revamp the mempool on Base Chain, which enables features like bundle support and transaction status tracking for users. One big scaling benefit of this project is that it allows us to more easily apply resource metering to other resources besides blob usage. There are several open questions and decisions around the design of this, which we will be sharing and soliciting feedback shortly. 

Effort 4: Access lists

We have begun exploring Flashblock Access Lists (FAL), an adaptation of EIP-7928 for OP Stack chains that produce Flashblocks, along with OP Labs. FAL improves execution performance of validator nodes by enabling parallel disk reads, parallel transaction validation, and executionless state updates.

Summarizing all of these efforts around execution, the Reth sequencer migration has made it safe to increase gas limit to at least 150 Mgas/s, and we believe we can unlock a gas limit of 400-500 Mgas/s by early 2026, with efforts like TrieDB and resource metering landing soon.

Bottleneck 3: Fault Proof Performance

In our last update, a major bottleneck was fault proof performance. Given that Base Chain still relies on an optimistic proof system, we cannot produce more transaction data than can be properly proven and verified by our proof system. We are bound by how long it takes for fault proof game participants to produce successful challenges. 

However, OP Labs produced an improved version of the fault proof system which introduced multi threading and utilized a 64 bit architecture (over 32 bits) - MT+64 Cannon. These two modifications significantly improved performance, and fault proofs have since not been a concern for scaling post rollout. 

In addition, to continue decentralizing, we are exploring ZK-based proof systems for Base Chain and we believe these could have positive benefits for scaling.

Bottleneck 4: State and History Growth

Our “Reth everywhere” efforts have paid strong dividends in managing state and history growth as well. As a result, we do not currently have major concerns for historical growth becoming a scaling blocker in the near term, however this could change as we begin to significantly increase the gas limit. We anticipate that one of the next long term projects we take on to address this challenge will be around state expiry, and the team is beginning to explore potential avenues in this direction.

Bottleneck Summary

Combining all of these, we get the following summary graph. Notably, we have cleared the path to scaling to 150 Mgas/s in the next month. 

Guardrails

We believe proactively increasing Base Chain’s gas limit is core to supporting a billion people onchain, so the core metric we use to track scaling progress is gas limit per second.

However, the intended impact of scaling is to maintain sub-cent transactions on Base Chain so we must also track fees to ensure we’re sustaining this. 

Since transactions can range in complexity and therefore cost, the fee metric we track is the cost of a standard amount of gas usage. We have started with 100k gas – a bit more than what’s used by an average swap. 

Besides fees, we also track transaction inclusion time and uptime. These are tangential to scaling, but degradation in these metrics could indicate that we need to scale more or focus on infra reliability. An active goal this quarter is to improve reliability so that 99.9% of blocks are built in less than 2 seconds, which we hope to achieve by landing the projects related to execution speed. 

Looking Forward

As we have observed fees starting to increase on Base Chain during periods of heightened activity, we are committed to accelerating our scaling roadmap to reduce these fees and maintain sub-second, sub-cent transactions on Base.

Our efforts to accelerate scaling have been made possible by the support of many teams across the ecosystem. We are grateful to the protocol teams and infrastructure operators that have been so receptive to and supportive of our scaling efforts.

We’ll continue to collaborate to scale Base Chain to support 1 billion+ users. If you’re interested in working on creative and ambitious scaling solutions to enable the next billion people to come onchain, we’re hiring, and we’d love to hear from you.

Follow us on social to stay up to date with the latest: X (Base team on X) | Farcaster | Discord

Testing decentralized applications has always been fundamentally different from testing traditional web applications. While conventional apps deal with straightforward HTTP requests and predictable database states, onchain apps must navigate the complex world of blockchain interactions: wallet connections, transaction approvals, network switches, and chain state. Each of these interactions introduces unique challenges that existing testing frameworks weren't designed to handle.

We encountered many of these challenges when writing end-to-end tests for the Verified Pools project. This sophisticated DeFi application brought institutional-grade liquidity infrastructure to onchain markets, requiring testing of complex user flows across frontend, backend, and smart contract integrations. For example, a user connecting their wallet, approving token spending, signing Permit2 messages, providing liquidity to pools, and managing their positions across multiple contracts. What should have been a straightforward testing effort quickly became a weeks-long odyssey of technical challenges and productivity bottlenecks.

The Core Challenges of E2E Onchain Testing

Testing decentralized applications introduces complexities that live at the intersection of web automation and blockchain interaction. Standard end-to-end testing frameworks are not inherently built for this environment, forcing developers to solve several fundamental problems before they can write effective tests.

Based on our experience, there are 4 major testing hurdles:

1. Wallet Extension Setup Every test requires a browser wallet to be installed, configured, and funded from scratch. This process is unique for each wallet (like MetaMask or Coinbase Wallet) and can lead to brittle, custom scripts.

2. Unpredictable Wallet Pop-ups During a test, user actions trigger wallet pop-ups for transaction approvals, message signing, and network switches. These pop-ups appear asynchronously with inconsistent timing and UI patterns, leading to unpredictability and flakiness. 

3. Shared On-Chain State True test parallelism is impossible on a shared blockchain. When multiple tests run at once, they use the same wallet addresses and interact with the same smart contracts on the same blockchain. This causes tests to interfere with each other's state, leading to unpredictable failures that are difficult to debug.

4. Contract Deployment and State Management A fundamental tooling gap exists between smart contract development in Solidity (using Foundry) and end-to-end testing in TypeScript. Tests require contracts to be deployed with a specific initial state, but contract addresses are non-deterministic, which breaks the link with the frontend.

How OnchainTestKit Solves Each Problem

OnchainTestKit directly addresses each of the four critical problems with purpose-built solutions:

Solution 1: Automatic Wallet Management

Instead of manually setting up each wallet type, OnchainTestKit handles everything automatically, with a unified interface that works for all wallet types. Here's an example of how to configure a test with Coinbase Wallet:

// Configure the test with a local node and a coinbase wallet
const coinbaseWalletConfig = configure()
  .withLocalNode({
    chainId: baseSepolia.id,
    forkUrl: process.env.E2E_TEST_FORK_URL,
    forkBlockNumber: BigInt(process.env.E2E_TEST_FORK_BLOCK_NUMBER ?? "0"),
    hardfork: "cancun",
  })
  .withCoinbase()
  .withSeedPhrase({
    seedPhrase: DEFAULT_SEED_PHRASE ?? "",
    password: DEFAULT_PASSWORD,
  })
  .withNetwork({
    name: "Base Sepolia",
    chainId: baseSepolia.id,
    symbol: "ETH",
    rpcUrl: "http://localhost:8545",
  })
  .build();

Result: Developer-friendly, wallet agnostic, and easy to use. We hide all the complexity of wallet setup and management from the developer.

Solution 2: Reliable Wallet Popup Handling

OnchainTestKit provides a unified interface that abstracts all popup complexity:

// Instead of dealing with timing and popup detection:
await coinbaseWallet.handleAction(BaseActionType.CONNECT_TO_DAPP);
await coinbaseWallet.handleAction(BaseActionType.HANDLE_TRANSACTION, {
  approvalType: ActionApprovalType.APPROVE
});

await coinbaseWallet.handleAction(BaseActionType.CHANGE_SPENDING_CAP, {
  approvalType: ActionApprovalType.APPROVE
});

Intelligent Waiting Strategies & Retries: OnchainTestKit uses smart waiting strategies that understand blockchain timing patterns and wallet behavior. Built-in retry mechanisms handle transient failures automatically, while adaptive timeouts adjust based on network conditions and popup complexity.

Result: Tests pass reliably. No more flaky tests due to timing issues or unpredictable wallet behavior.

Solution 3: True Test Isolation

OnchainTestKit provides each test with its own isolated Anvil blockchain node, eliminating all state conflicts:

// Each test gets its own LocalNodeManager
test('parallel test A', async ({ localNodeManager, smartContractManager }) => {
  // Automatically starts Anvil node on available port (e.g., 10543)
  // This test's transactions only affect its own blockchain
  await page.click('#swap-button');
  // Test logic...
});

test('parallel test B', async ({ localNodeManager, smartContractManager }) => {
  // Automatically starts separate Anvil node on different port (e.g., 10847)
  // Completely independent blockchain state
  await page.click('#approve-button');
  // Test logic...
});

How LocalNodeManager Works: OnchainTestKit automatically allocates available ports across processes and spins up isolated Anvil nodes for each test. It supports three different parallel testing strategies:

1. Fork Existing Networks: Fork a testnet or mainnet at a specific block number without deploying contracts. Perfect for testing against existing protocol deployments:

.withLocalNode({
  forkUrl: process.env.BASE_MAINNET_RPC_URL,
  forkBlockNumber: process.env.E2E_TEST_FORK_BLOCK_NUMBER,
  chainId: 8453
})

2. Clean Local State: Start with a fresh blockchain and deploy all dependent contracts. Ideal for testing new protocols or complex state setups:

.withLocalNode({
  chainId: 84532,
  // No fork - starts with clean state
})

// Then deploy contracts via smartContractManager

3. Hybrid Approach: Fork a network and deploy additional test contracts on top. Combines real protocol state with custom test contracts:

.withLocalNode({
  forkUrl: process.env.BASE_SEPOLIA_RPC_URL,
  forkBlockNumber: 10_000_000n,
  chainId: 84532
})

// Then deploy additional test contracts as needed

Each approach provides complete test isolation with independent blockchain state, allowing tests to manipulate time, account balances, and contract state without affecting other tests.

Smart RPC Routing: One of the key innovations is automatic request interception. Your frontend can always use a fixed RPC URL like localhost:8545, and LocalNodeManager automatically routes these requests to the correct Anvil node for each test. No need to dynamically configure different ports—the framework handles the routing transparently.

Automatic Cleanup: LocalNodeManager handles the complete node lifecycle, gracefully terminating each Anvil process after its test completes. This ensures no resource leaks or port conflicts, even when running large test suites with dozens of parallel nodes.

Result: Fully parallelized testing with no coordination overhead. CI times drop from hours to minutes.

Solution 4: Deterministic Contract Deployments

OnchainTestKit bridges the Solidity/TypeScript gap using CREATE2 for deterministic contract deployments:

await smartContractManager.setContractState({
  deployments: [
    { 
      name: 'MockUSDC', 
      salt: '0x1234...', // CREATE2 salt for deterministic address
      deployer: admin,
      args: ['USD Coin', 'USDC', 6] 
    },
    { 
      name: 'DEXContract', 
      salt: '0x5678...', 
      deployer: admin,
      args: [mockUsdcAddress] 
    }
  ],
  calls: [
    { target: mockUsdcAddress, functionName: 'mint', args: [user, amount], account: admin },
    { target: mockUsdcAddress, functionName: 'approve', args: [dexAddress, amount], account: user }
  ]
});

How CREATE2 Works: OnchainTestKit uses CREATE2 deployment with fixed salts to ensure contracts always deploy to the same addresses. The SmartContractManager predicts deployment addresses before deployment, checks if contracts already exist at those addresses, and loads Foundry artifacts automatically from your out/ artifact directory. This creates a seamless bridge between your Solidity contracts and TypeScript tests.

Foundry Integration: Automatically loads compiled contract artifacts, eliminating manual ABI management or deployment script coordination between contract and test teams.

Result: Reliable contract testing with predictable addresses. Full user journeys from smart contract interaction to UI feedback work consistently across all test runs.

How We Use OnchainTestKit in Verified Pools

Here's a real example from our Verified Pools project showing how OnchainTestKit transforms complex onchain app testing into clean, readable tests:

// walletConfig/metamaskWalletConfig.ts
import { baseSepolia } from 'viem/chains';
import { configure } from '@coinbase/onchaintestkit';

export const DEFAULT_PASSWORD = 'PASSWORD';
export const DEFAULT_SEED_PHRASE = process.env.E2E_TEST_SEED_PHRASE;

// Reusable configuration for MetaMask tests with Base Sepolia fork
const metamaskConfig = configure()
  .withLocalNode({
    chainId: baseSepolia.id,
    forkUrl: process.env.E2E_TEST_FORK_URL,
    forkBlockNumber: BigInt(process.env.E2E_TEST_FORK_BLOCK_NUMBER ?? '0'),
    hardfork: 'cancun',
  })
  .withMetaMask()
  .withSeedPhrase({
    seedPhrase: DEFAULT_SEED_PHRASE ?? '',
    password: DEFAULT_PASSWORD,
  })
  .withNetwork({
    name: 'Base Sepolia',
    chainId: baseSepolia.id,
    symbol: 'ETH',
    rpcUrl: 'http://localhost:8545', // Fixed URL, auto-routed to correct port
  })
  .build();

export { metamaskConfig };

This test covers a complete user journey in Verified Pools:

1. Connect MetaMask wallet to the onchain app

2. Navigate to the swap interface

3. Enter swap amount (0.0001 ETH)

4. Execute the swap transaction

5. Handle all required wallet popups (spending cap approval, Permit2 signature, transaction confirmation)

6. Verify the swap completed successfully
   

// swap.spec.ts

import { createOnchainTest } from '@coinbase/onchaintestkit';
import { NotificationPageType } from '@coinbase/onchaintestkit/wallets/MetaMask';
import { ActionApprovalType, BaseActionType } from '@coinbase/onchaintestkit/wallets/BaseWallet';
import { metamaskConfig } from './walletConfig/metamaskWalletConfig';

const test = createOnchainTest(metamaskConfig);
const { expect } = test;

test.describe('Verified Pools Swap', () => {
  test('connect wallet and swap @tx', async ({ page, metamask }) => {
    if (!metamask) throw new Error('MetaMask fixture is required');

    // Navigate to swap interface
    await page.goto('/swap');

    // Connect wallet - OnchainTestKit handles all the complexity
    await page.getByTestId('ockConnectButton').first().click();
    await page.getByTestId('ockModalOverlay')
      .first()
      .getByRole('button', { name: 'MetaMask' })
      .click();
    await metamask.handleAction(BaseActionType.CONNECT_TO_DAPP);
    await page.getByRole('button', { name: /^Accept$/ }).click();

    // Set up the swap
    const inputField = page.locator('input[placeholder="0.0"]').first();
    await inputField.fill('0.0001');

    // Execute swap
    await page.getByRole('button', { name: 'Swap' }).click();
    await page.getByRole('button', { name: 'Confirm' }).click();

    // Handle spending cap approval (Permit2)
    let notificationType = await metamask.identifyNotificationType();
    if (notificationType === NotificationPageType.SpendingCap) {
      await metamask.handleAction(BaseActionType.CHANGE_SPENDING_CAP, {
        approvalType: ActionApprovalType.APPROVE,
      });
      notificationType = await metamask.identifyNotificationType();
    }

    // Handle signature for Permit2
    if (notificationType === NotificationPageType.SpendingCap) {
      await metamask.handleAction(BaseActionType.HANDLE_SIGNATURE, {
        approvalType: ActionApprovalType.APPROVE,
      });
      notificationType = await metamask.identifyNotificationType();
    }

    // Handle the actual swap transaction
    if (notificationType === NotificationPageType.Transaction) {
      await metamask.handleAction(BaseActionType.HANDLE_TRANSACTION, {
        approvalType: ActionApprovalType.APPROVE,
      });
    }

    // Verify swap completion
    await expect(page.getByRole('link', { name: 'View on Explorer' })).toBeVisible({
      timeout: 10_000,
    });
  });
});

What This Shows:

• No Custom Wallet Setup: OnchainTestKit handles MetaMask installation and configuration automatically

• Fork Testing: Tests run against real Base Sepolia network at a specific block number where all dependent contracts are deployed, but each test gets its own isolated fork

• Reliable Popup Handling: Complex wallet interactions reduced to simple handleAction calls

• Smart RPC Routing: Frontend uses fixed localhost:8545, framework routes to correct test node

• Automatic Cleanup: No manual resource management needed

This same test would have required hundreds of lines of custom wallet automation code before OnchainTestKit. Now it's clean, readable, and maintainable.

Production CI/CD with OnchainTestKit

Here's how we run these tests at scale in our Verified Pools CI pipeline:

# .github/workflows/playwright.yml

jobs:
  e2e-tests:
    # additional setup steps omitted for brevity
    # Install xvfb for headless browser testing

    - name: Install xvfb
      run: |
        sudo apt-get update
        sudo apt-get install -y xvfb

    - name: Install dependencies
      run: yarn install --frozen-lockfile

    - name: Install Playwright Browsers
      run: yarn playwright install --with-deps

    - name: Build application
      run: yarn build
      env:
        NEXT_PUBLIC_BASE_SEPOLIA_RPC_URLS: http://localhost:8545

    - name: Prepare MetaMask Extension
      run: yarn e2e:metamask:prepare

    # Run transaction tests in parallel with 10 workers
    - name: Run Playwright TX tests with xvfb
      run: xvfb-run --auto-servernum --server-args="-screen 0 1280x960x24" yarn playwright test --workers=10 --reporter=list,github
      env:
        E2E_TEST_SEED_PHRASE: ${{ secrets.E2E_TEST_SEED_PHRASE }}

Key Production Features:

• Parallel Execution: --workers=10 runs 10 tests simultaneously, each with isolated blockchain nodes

• Environment Isolation: Each test gets its own fork of Base Sepolia without conflicts

• Robust CI Setup: Handles headless browser automation with xvfb and proper cleanup

Results: Our CI runs 100+ comprehensive onchain app tests in parallel in under 10 minutes.

Try OnchainTestKit Today

OnchainTestKit is available now and has been published to NPM. To get started, check out the documentation and examples in the GitHub repository.

Interested in Improving Onchain Developer Experience?

If increasing the impact of onchain developers piques your interest, please know that our Onchain DevX team would love to meet you! We're Hiring.

Launched on July 16th, this concluded a four-month development journey from testnet to mainnet. We built in public, and wanted to share more of the technical details of Flashblocks, the challenges we encountered during our journey, and our learnings. If you're looking for support on integrating your app or infrastructure provider with Flashblocks, we recommend checking out this blog post and FAQ page.A

A Primer on Flashblocks

Previously, Base produced a new block every 2 seconds. With Flashblocks (built with Flashbots), the builder streams 200 ms sub-blocks during that 2-second window, giving sub-second preconfirmations so transactions feel instant.

There are 10 Flashblocks per block, and each of them (flashblock_i) can contain up to i/10 of the regular block’s total gas budget. A series of Flashblocks are combined to recreate a full block.

Now that we've covered what Flashblocks are, let's dive into how we implemented them into Base Chain.

Sequencer Architecture

As part of the Flashblocks launch, we added several new infrastructure components to the sequencer. To contextualize these changes, we share what the sequencer architecture looked like both before and after Flashblocks.

Architecture before Flashblocks

At Base, we operate a high availability sequencer system, with five sequencer instances.

Each sequencer is made up  of the following infrastructure components:

• Op-node: the standard op-stack consensus layer (CL) software

• Op-geth: the standard op-stack execution layer (EL) software

  • op-node and op-geth communicate via Engine APIs for block building. 

• Op-conductor: the high availability control component, with a raft consensus for leadership election

One sequencer instance functions as the “leader” and is responsible for sequencing by building blocks and propagating them via P2P to other nodes. The remaining four sequencers act as follower Base nodes that synchronize the chain. Leadership transfer occurs if the current leader stops block production within a specified threshold.

Architecture With Flashblocks

With Flashblocks, we integrated several new components within each single sequencer in the high availability system, to allow for the addition of more custom block building functionality. These include:

• Rollup-boost (CL<>EL Engine API proxy)

  • Why it’s needed for Flashblocks: Enables sharing Flashblocks with the EL without modifying the CL, by adding a controlled interception point on Engine API calls. It localizes risk and lets us experiment off-protocol

  • What it unlocks: A stable seam for future block-building evolutions (e.g. multi-builder), without refactoring CL/EL

• Op-rbuilder (out-of-protocol builder @ 200ms cadence)

  • Why  it’s needed for Flashblocks: Produces the sub-second Flashblocks, decoupled from the EL

  • What it unlocks: A pluggable builder surface for new block building mechanisms (e.g. MEV-aware strategies, auctions across multiple builders)

• Websocket proxy (Flashblocks stream fan-out)

  • Why it’s needed for Flashblocks: A broadcast layer such that many consumers can read the Flashblocks stream without DoS-ing the builder

• Node-reth (RPC surface exposing preconfirmations)

  • Why it’s needed for Flashblocks: Converts the streamed Flashblocks into familiar RPCs so apps and wallets can consume preconfirmation state without new SDKs or protocol changes

Both rollup-boost and op-rbuilder were initially built and are currently maintained by Flashbots. While on the Base side we built and are maintaining websocket proxy and node-reth, as well as made specific changes to rollup-boost and op-rbuilder for our needs. Explained in more detail in the reliability section below.

Given these changes, how does a transaction submitted to Base now proceed?

Lifecycle of a Base Mainnet Transaction

Let’s trace the journey of a transaction when a user sends an eth_sendRawTransaction to mainnet-base.org. This flow is similar before and after Flashblocks, with modification to the block building algorithm. The request undergoes the following stages:

1. The request first reaches our DNS provider for resolution of mainnet-base.org.

2. From there, it is routed to the load balancer of the routing software, Proxyd

3. Proxyd then routes the request to the private mempool

4. The mempool receives the request and inserts the transaction into its txpool as a pending transaction

5. The mempool maintains P2P connections with the ELs (op-geth, op-rbuilder), ensuring all pending transactions are sync’d in the ELs for block building

6. During each block building loop, the ELs select transactions from their txpool

Flashblocks Block Building

With Flashblocks live, we use op-rbuilder as the block builder. Within op-rbuilder, as explained in the previous blog post, the following factors determine when a transaction is chosen

1. Transaction fee: for each 200ms block building loop, transactions are ordered by their fee, same as op-geth

2. Transaction gas limit and remaining gas available: for each flashblock FB_j, up to j/10 total block gas limit can be used. Therefore, a transaction must have sufficient fee and remain within the available gas for that flashblock

The pseudocode for Flashblock block building that captures the above factors is as follows

FUNCTION BuildFlashblocks(pending_transactions, total_block_gas_limit):
    flashblocks = []
    block_gas_used = 0
    
    FOR j FROM 0 TO MAX_FLASHBLOCKS_PER_BLOCK:
        NEXT_TIME = MONOTONIC_NOW() + 150ms // next block start time
        current_flashblock_gas_limit = (j / 10) * total_block_gas_limit
        
        // Order pending transactions by fee (descending)
        sorted_transactions = SORT_BY_FEE_DESC(pending_transactions)
        // Select transactions given gas available
        selected_transactions = TOP_TRANSACTIONS_WITHIN_GAS_LIMIT(sorted_transactions, current_flashblock_gas_limit, block_gas_used)

        // Execute transactions
        executed_info, gas_used = EXECUTE_TX(selected_transactions)
        block_gas_used += gas_used
        // Build the flashblock by computing block hash and state root
        flashblock = BUILD_BLOCK(flashblock, executed_info)
        
 // Wait for the remaining amount of time before building the next flashblock
        WAIT_UNTIL(NEXT_TIME)
    END FOR
    
    RETURN flashblocks
END FUNCTION

See here for the full implementation in op-rbuilder.

Flashblocks RPC Nodes (Node-reth)

Once the transaction is chosen and mined, it’s included as part of the flashblock data streamed to websocket proxy, which RPC nodes listen to. The RPC nodes cache the flashblock data. The exact definition of the data stream can be found here, we also explain it more thoroughly in our documentation page.

When a flashblocks supported RPC method is called, it retrieves the data from the cache and returns it if available. (E.g. eth_getTransactionReceipt)

Reliability and Performance Improvements

During the development of Flashblocks, we made several improvements to ensure the system is highly available and Flashblocks could consistently be produced in 200ms.

Enabling Builder Failover

With the integration of op-rbuilder, it became necessary to incorporate builder health into the op-conductor’s health check. We enabled healthcheck to rollup-boost which verifies if the builder remains sync’d within the tip of the chain. If the builder falls behind, the op-conductor will initiate a leadership transfer.

This significantly enhances Flashblocks’ availability as Flashblocks will not experience a long period of outage due to unhealthy builders. However, the downside is that if all builders are down, the op-conductor will be unable to elect a healthy leader, leading to a chain halt. Nevertheless, the probability of all builders being down simultaneously is rare, making this a reasonable compromise. 

Optimizing State Root Calculation

In the initial design, the state root was calculated for each flashblock. This was due to the complexity of determining which flashblock would ultimately become the finalized block that the builder needed to return to the op-node. Without a state root, the op-node cannot promote the block as finalized.

While this approach functioned correctly for Base Sepolia, the high transaction volume on Base Mainnet made each state root calculation take approximately 130ms on average. This pushed the total block building time close to 200ms, making it hard to build more than 9 flashblocks, potentially reducing throughput.

In order to fix this, instead of having the builder compute the state root for every flashblock, we modified rollup-boost to take the transactions from the builder, then used an additional FCU to use op-geth to build a block with state root. (Many thanks to Ferran from Flashbots for this suggestion!)

As a result of this change, the P50 Flashblock building time dramatically decreased from 150ms to a mere 10ms, removing this issue as a launch blocker.

Resolving the Transaction Pool discrepancy between Geth and Reth

Moving our builder from op-geth (Geth based) to op-rbuilder (Reth based) meant shifting from using Geth’s transaction pool implementation to Reth's transaction pool implementation.

Soon after our launch, we observed some unusual behavior: the Coinbase retail staking team's transactions stopped getting included, causing a large backlog of transactions.

We then thoroughly examined the differences between the Geth and Reth transaction pool implementations and identified the following distinctions:

Geth

• Pending: Next-nonce transactions with no nonce-gap.

• Queued: Transactions with nonce-gaps.

Reth

• Pending: Next-nonce transactions with a fee higher than the base fee.

• Queued:

  • Basefee subpool: Transactions below the base fee, even if they are next-nonce.

  • Transactions with a nonce-gap.

Consequently, if a transaction is a next-nonce transaction but has a fee lower than the base fee, it would remain pending for Geth but be queued for Reth. Once the transaction pool lifetime value is reached, queued transactions are dropped, and Geth would not rebroadcast these transactions as it always assumes pending transactions are successfully P2P'd.

To address this, we built the Mempool-rebroadcaster. This tool checks for discrepancies between the Geth and Reth txpools and rebroadcasts transactions between them. This ensures that even if a transaction is dropped from Reth, it continues to be picked up again.

Reducing Reorg rates

In our initial implementation, builders sent flashblocks directly to the websocket proxy. Because the builder was unaware of the actual time allocated by the op-node for block building, this could lead to tail flashblocks reorgs: the tail flashblocks were streamed out but not included in the actual block.

Flashbots team added a new mechanism to instead of letting the builder to stream to websocket proxy, the builder streams to rollup-boost then rollup-boost streams to websocket proxy. It works as follows

• Op-node sends FCU to rollup-boost, rollup-boost proxies FCU to op-rbuilder to start block building

• In each block building loop, op-rbuilder streams flashblock to rollup-boost, rollup-boost stores the flashblocks in a variable named best_payload

• At the end of the block building, op-node sends get_payload to rollup-boost, rollup-boost returns best_payload, and clears best_payload

• If op-rbuilder continues to send flashblock with the same payload_id, it gets rejected

This significantly improved our reorg rate, reducing it from 0.2% to effectively 0:

Future Work

RPC Improvements

We’re currently adding new Flashblocks-aware RPCs: eth_call and eth_estimateGas. Our implementation involves having the node copies over the latest state, replays the Flashblock streams on top, and executes the request against that overlay. This makes simulations and gas estimates reflect preconfirmation state. The feature is in active development and will land after validation and testing.

Websocket

Websocket is the low-latency backbone for traders and for teams that host their own RPC nodes. We aim to operate the public websocket with high availability and backpressure controls. However, it’s worth noting that applications should try to avoid having dependency on websocket as RPCs provide stable RPC behavior and automatic failover to regular blocks whenever Flashblocks are down.

Other block building updates

Enabling the custom builder (op-rbuilder) as part of the Flashblocks launch has paved the way for more block building innovation, with the potential to unlock more blockspace capacity and efficiency for Base users, and even provide unique capabilities for developers. To stay up to date on any planned block building changes, follow our docs and status page.

Get Involved

• Running a flashblock-aware RPC node

• Report problems: Open a GitHub issue

• Questions / feedback: Join the Discord

If you’re interested in helping us build a global economy that increases innovation, creativity, and freedom, we’re hiring and would love to hear from you.

Follow us on social to stay up to date with the latest: X (Base team on X) | Farcaster | Discord

• Proof generation time: Time it took to create the ZKP on various hardware configurations.

• Gas cost: The gas required on an EVM to verify the proof in a smart contract.

Full details on the benchmarking setup, including scripts and configurations, are available in our GitHub repository.

What Are Zero-Knowledge Proofs (ZKPs)?

Zero-knowledge proofs let you prove you know something without revealing what you know. They work by constructing mathematical proofs that demonstrate you performed a computation correctly, without revealing the secret inputs you used. Think of it like proving you're over 18 without showing your exact age, or proving you have enough money in your account without revealing your balance.

In crypto, ZKPs are making an impact on both privacy and scaling related use cases. 

For privacy, projects like Zcash or Iron Fish use ZKPs to enable fully private transactions where amounts, asset types, and transaction participants are hidden, yet the network can still verify transactions are valid. 

For scaling, zkRollups use ZKPs to process thousands of transactions offchain, then submit a single compact proof that mathematically guarantees all those transactions are valid, saving on both storage and compute cost. General-purpose zkVMs like Risc0 and SP1 enable proving arbitrary program execution, opening up use cases beyond just transaction processing.

Why Benchmark Passkey Verification in Zero-Knowledge? 

Passkeys are the modern passwordless authentication system. You might have noticed a number of major platforms such as Google, GitHub, PayPal, and other popular websites you use today offer passkey logins as opposed to just using your password. 

Passkey based smart wallets work similarly. Unlike traditional seed phrases or private keys that users must memorize or store securely, passkeys are securely stored and managed by your device's operating system. In many implementations they can be accessed via biometric data like Face ID or fingerprint offering better UX, and can be automatically synced across your devices via services like iCloud, 1Password, or Google Password Manager.

Base Accounts are passkey-based smart wallets, relying on the sec256r1 (P-256) curve for ECDSA signature generation, the same standard used by Apple, Google, and the FIDO2 WebAuthn specification. ​​Verifying a passkey signature within a zero-knowledge proof enables powerful privacy features. Users can prove ownership of a public key by proving validity of a signature without directly revealing their public key enabling:

• Anonymous group membership proofs for DAOs

• Private authentication for sensitive applications

• Delegating proof generation to relayers while maintaining privacy

Please note that in practice such proofs would have two steps: one step to prove ownership over a key (e.g. validity of a signature within a ZKP), and the second step would be to prove that the public key (or even a commitment/hash of that public key) is within a certain set, such as a merkle tree, onchain. For these benchmarks we just focused on the first step of verifying a passkey signature within a ZKP to validate the idea. 

Although these are just explorations for now, it’s a topic that the Base Privacy pod (acquired team from Iron Fish) is really passionate about. 

Generating zero-knowledge proofs for passkey signatures is also a fun technical problem. Passkeys use the P-256 elliptic curve for signatures, but most efficient and popular ZKP systems for EVMs use the BN254 curve that has a different mathematical field. This creates a "curve mismatch" problem. Think of it like trying to do math where your calculator only works with numbers 1-100, but you need to work with numbers 1-1000. You need to break down the larger numbers into smaller pieces and emulate the math you want to do. P-256 curve elements can't be directly represented as single values in BN254-based ZKP systems. Instead, they must be "emulated" through complex mathematical operations, resulting in large circuits with around 2 million constraints. For comparison, the most complex ZKP circuit in both Iron Fish and Zcash is around 100k constraints. 

Methodology

We tested four leading ZKP frameworks, each with different strengths:

• SnarkJS: JavaScript-based, runs in browsers, great for development

• Rapidsnark: C++ optimized version of SnarkJS for production speed

• Gnark: Go-based system with strong security features

• Noir: Rust-based with specialized optimizations for complex operations
  

All of these frameworks rely on circuit engines, which convert high-level code into the low-level mathematical constraints that ZKP systems understand. Each framework has its own way of expressing and optimizing these constraints.

Some ZKP systems have what’s called a “trusted setup” that is unique per every circuit and must be generated as part of the setup phase. The more complicated a circuit/program is, the more computationally intensive the trusted setup step is. Noir uses a ZKP system that relies on a “universal trusted setup” instead, which is generated just once and reused for many circuits. Not having to regenerate the trusted setup was a huge developer experience benefit. 

Key Technical Choices:

• BN254 curve vs BLS12-381: We chose BN254 for better performance and lower gas costs in EVM environments

• P-256 Implementation: Since building P-256 field arithmetic from scratch was outside our scope, we used existing optimized implementations (called "gadgets") where available

• For Noir specifically, we leveraged their "blackbox" functionality which are specialized operations handled directly by the underlying Barretenberg proving system in optimized C++ code, rather than being expressed as individual ZKP constraints.

Benchmark Setup

We ran the benchmarks on AWS EC2 instances to simulate real-world cloud environments:

• t4g.medium: ARM Graviton2, 2 vCPUs, 4GB RAM—Cost-effective ARM

• c7g.xlarge: ARM Graviton3, 4 vCPUs, 8GB RAM

• c7i.2xlarge: Intel, 8 vCPUs, 16GB RAM

• c7i.4xlarge: Intel, 16 vCPUs, 32GB RAM

• c7i.8xlarge: Intel, 32 vCPUs, 64GB RAM 

Each benchmark involved generating proofs for the ECDSA signature verification circuit multiple times to capture minimum, average, and maximum values, along with standard deviations. Gas costs were measured for on-chain verification in an EVM-compatible smart contract.

The raw data and plots are available in our results directory.

Results

Proof Generation Times

Noir dominated in speed, consistently achieving 5-50x faster proof generation than Groth16-based systems:

• c7i.2xlarge (8 vCPU, 16GB RAM): Noir ~2.1s, others 40-50s

• c7i.4xlarge (16 vCPU, 32GB RAM): Noir ~1.1s, others 20-30s

• c7i.8xlarge (32 vCPU, 64GB RAM): Noir ~0.6s, others 15-25s

Among Groth16 systems, Gnark performed best, followed by Rapidsnark and SnarkJS.

Below are summarized benchmark runs (all times in seconds):

t4g.medium (2 vCPUs, 4GB)

Couldn’t run SnarkJS and Rapidsnark due to memory overhead of generating the trusted setup

c7g.xlarge (4 vCPUs, 8GB RAM)

Couldn’t run SnarkJS and Rapidsnark due to memory overhead of generating the trusted setup

c7i.2xlarge (8 vCPUs, 16GB RAM)

c7i.4xlarge (16 vCPUs, 32GB RAM)

c7i.8xlarge (32 vCPUs, 64GB RAM)

Gas Costs for On-Chain Verification

Whereas Noir won on speed, it dramatically fell behind on gas cost. 

Gas costs largely depend on proof size. Groth16 systems produce constant-size proofs regardless of circuit complexity. Noir's UltraHonk system generates proofs that scale logarithmically with circuit complexity:

Discussion

Noir stood out on proof generation time, 5-50x faster than Groth16 counterparts on the same hardware 🙌 yet 6-7x costlier on gas.

Noir's speed advantage largely comes from its blackbox implementation. The black box functions are hand-coded mini-circuits that the Aztec team wrote directly in their proving system, barretenberg, that use highly specialized custom gates for specific operations. Specifically, barretenberg has an algebraic gate that directly evaluates non-native field operations efficiently. Noir calls these custom gates directly, dramatically reducing circuit size and proving time. 

These results reveal fundamental trade-offs rather than clear winners. Noir excels in proof generation speed for certain operations making it in some cases great for applications where users generate proofs client-side on mobile or browser environments, while having a higher gas cost due to proof size. It's also ideal when development velocity and iteration matter most or when you can use Layer 2s to reduce the gas cost impact. Groth16 systems like SnarkJS, Rapidsnark, and Gnark become the better choice for complex general computations that Noir can’t optimize for, or when onchain verification costs are the primary constraint.

However, keep in mind that the ZKP landscape continues to evolve rapidly and new innovations and techniques are coming out every day. Happy building!

For raw data, code, and plots, visit our GitHub repo. Feedback and contributions welcome!

If you’re interested in helping us build a global economy that increases innovation, creativity, and freedom, we’re hiring — and we’d love to hear from you.

Follow us on social to stay up to date with the latest: X (Base team on X) | Farcaster | Discord

Basenames are the Base-native identity layer, a decentralized open protocol built on top of ENS, and the identity solution for your Base Account. Every new user that onboards to The Base App gets a unique username that fits the form name.base.eth; that’s a Basename!

 “Primary names” are a cornerstone of the ENS protocol.  They allow any client or third party app to use the address of a connected account to reverse-lookup the name associated with that account. This is the mechanism that allows a user to look like they’re logged in as jesse.base.eth in the wallet pip in-app instead of appearing as a 0x1234… address. And if you hold multiple names, you can specify which one you want to be represented by. 

Under the hood, resolving names or addresses are called forward and reverse resolution respectively. Forward and reverse resolution are reciprocal processes and can be visualized simply like this: 

Today, Basenames natively supports primary names but with some caveats:

• When Basenames launched there wasn’t support from the ENS protocol to achieve primary names for subdomain issuers on L2s. The only supported path to primary name setting required an expensive transaction on mainnet against ENS’s ReverseRegistrar contract.

• Apps that want to support Basenames primary names have to use a Basenames-specific lookup, supported most commonly by our OnchainKit snippet.

This means apps that don’t specifically integrate with the custom Basenames reverse resolution flow are unable to check our users’ primary names. Additionally, if a user wants to take their Basename identity to other chains like Ethereum L1 or Optimism, their Basename can’t follow them.

Enter ENSIP-19

In close collaboration with the Basenames team, ENS has refined and produced a formal specification for supporting L2 primary names. The ENS DAO voted to enable this protocol upgrade as of Tuesday 7/29 with overwhelming support from the community. With the finalization of this update, Basenames is now moving to upgrade to support this spec. 

Once fully integrated, we get the following benefits for all Basename users:

• Primary name resolution on all apps using modern webapp clients like wagmi; not just ones that integrate directly with Basenames via onchainkit. 

• Basenames can serve as your primary name for many networks, not just Base. 

How ENSIP-19 works under the hood

ENS deployed a new contract called the L2ReverseRegistrar to each supported chain. These contracts let any address set its primary name for that chain. When a user connects their wallet to an app on one of these supported chains, the client can begin the reverse resolution flow for the user.

Let’s explore how this works  by following a reverse resolution request for Jesse connecting to an app on Optimism: 

1. Jesse connects his wallet to an app on Optimism which kicks off the ENSIP-19 reverse resolution flow. 

2. A reverse resolution request is sent to the ENS Universal Resolver on L1 asking for the primary name of Jesse’s address for the Optimism network. 

3. The resolution request is forwarded to an L1 Resolver contract responsible for reverse resolution on Optimism specifically.

4. This request kicks off a CCIP-read flow which delegates the resolution to an offchain Gateway.

5. The Gateway queries for the Name set in the L2ReverseRegistrar associated with Jesse’s address on Optimism and constructs a state proof for the fetched data.

6. The Gateway provides this response to the client so it can call back into the L1 Resolver with the data and the state proof used for verifying validity.

The client now knows that Jesse’s address is associated with jesse.base.eth, but we’re not done! When setting a name on the L2 Reverse Registrar, this contract cannot verify that an address is setting its primary name to a name that it controls. As such, there’s a close-loop validation step to the ENSIP-19 flow, very similar to the existing reverse resolution flow which verifies the retrieved name forward resolves to the original address.   

7. The client now requests the forward resolution data for jesse.base.eth for the optimism network which is configured in the Basenames contracts on Base in accordance with ENSIP-11. 

8. Through a similar CCIP-read flow, the forward resolution data for Jesse’s name is fetched from the Basenames contracts.

9. If the address connected to the client matches the address returned by the optimism-specific forward resolution request (ENSIP-11), then the Primary Name is valid and Jesse shows up as jesse.base.eth! 

A complete swimlane for this flow can be found in the Appendix below. 

Next steps for Basenames

With the ENS contracts, gateway and tooling integrations live, modern clients will be capable of using ENSIP-19 to reverse resolve any Basename. However,  Basenames user data is missing two pieces to support these requests: 

• Basenames users today write their reverse resolution data straight into a generic  resolver contract deployed before ENSIP-19 was finalized. This data instead needs to be located in the ENSIP-19-defined L2ReverseRegistrar to be available for the ENSIP-19 lookup flow (steps 3-6 above).

• The ENSIP-19 flow requires that users write network-specific data defined by ENSIP-11 for each network where they want a name to be primary. Many Basename users today are missing data in this format for any network other than Ethereum mainnet.
  

Since existing Basenames user data exists with accurate content already, but is located in the nonstandardized combination of contracts or storage slots, the Basenames team is taking a proactive approach. We are choosing to migrate the data on behalf of all users. In so doing, users won’t have to return to a Basenames surface to migrate their own data and will inherit the benefits of ENSIP-19 as soon as the migration and integrations are complete.

New Contracts 

To support these efforts, we are deploying three new contracts. Each of these contracts is undergoing rigorous testing today and will be externally audited before going live. 

Upgradeable Registrar Controller

Today our existing RegistrarController manages the business logic associated with Basenames. It handles registrations, discounted registrations and renewals. Since it can register new names, it has unique permissions within the protocol. Specifically, it is allowed to write records to our immutable BaseRegistrar contract which tokenizes unique names and handles expiry. This upgradeable version will do everything the existing registrar does and will also write ENSIP-19 compliant records on behalf of users during registrations. 

Upgradeable L2 Resolver

The L2 Resolver contract currently deployed is immutable. Though it inherits all of the most modern ENS resolver profiles, the Basenames team has plans to add functionality and features in the future. We also need a new Resolver target for our new Upgradeable Registrar Controller. So we’re taking this as an opportunity to get more data into a resolver which can accept new functionality seamlessly. Functionally, the only change to this contract over our existing L2Resolver is upgradeability.   

Migration Controller

This temporary contract is designed to assist in the forward resolution data migration.  It has an admin-only hook that can be used to set ENSIP-11-compliant forward resolution data on behalf of Basename users. The primary motivations for building this hook into this contract are twofold: 

1. It has a planned obsolescence at the end of this project

2. It has permission to write records on behalf of users in the L2Resolver contract where the forward resolution records need to land.  

Migration Steps

There are two large data migrations that need to be accomplished to convert all existing records into ENSIP-19 compliance. With over 750,000 Basenames active today, we need to perform a large scale series of transactions over multiple blocks. To ensure this migration doesn’t cause network congestion or spike gas costs on Base for everyone, we’re going to throttle the number of records we write per block to ensure our activities will have minimal impact on the gas market for other users. 

Since the migration itself cannot occur atomically and will instead take place over 3000 blocks, our contracts and surfaces need to be configured in a way to support a zero-downtime switchover. To accomplish this, we are leveraging two strategies: 

1. Set up a new, parallel registration path through our new Upgradeable Registrar Controller which can accomplish both legacy and ENSIP-19 reverse resolution writes. 

2. Similarly, perform “dual writes” when users opt to change their primary name ensuring legacy and modern reverse records are available to integrators. 

Once all new registrations and primary changes are ENSIP-19 compliant we can safely deprecate the legacy registration paths. This deprecation ensures no data will be missed when we migrate state. 

First, we’ll migrate user forward resolution data. By leveraging our new Migration Controller, we can safely copy the data that exists for users in the coinType == 60 address field and move it into the Base chain-specific slot at coinType == 0x80002105. This means that our users will now have Base-specific forward resolution data available for the close-loop steps of ENSIP-19. 

Second, we can begin moving the reverse resolution data from our L2 Resolver to ENS’s L2ReverseRegistrar. ENS was kind enough to include an admin hook for us in the Base implementation so that we can safely migrate the data on behalf of our users.

Once both data migrations are complete, the Basenames technical work is complete! At this point we will start working with integrators to switch over to using updated tooling (wagmi, ethers, viem) which supports ENSIP-19. 

Conclusion

We’re well into the development cycle for this project and our most recent batch of contracts to support this are currently under external audit. At current pace, we’re targeting an early September data migration with earlier cut-overs to the new registration and set-primary flows.

 If you run an app on Base and either integrate with Basenames today or want to in the future, we’ll have updated docs published along with the public announcements soon. If your app integrates with Basenames today, rest assured our migration is initially backwards compatible. However, you will need to upgrade when we deactivate legacy data writing for the sake of saving users’ gas.  We will contact our ecosystem with details as integrators must upgrade.   

That’s all for now! If you don’t already have your basename, register one today at https://base.org/name. And please stay tuned for updates from the Base Account squad as we roll this out.

Appendix

Bringing Coinbase’s security best practices to Base builders

From day one, Base Chain has been built with a security-first approach, leveraging Coinbase's enterprise-grade practices to secure the network.

To bring the next billion users onchain, we’re now looking to empower builders with the tools they need to build secure, reliable apps and protocols for their users. Last year, we introduced free onchain monitoring for Base builders, powered by Hexagate.

Now, we’re taking another major step towards bringing best-in-class security practices to apps on Base. Today, we’re excited to launch free security reviews to a cohort of apps and protocols on Base, in beta. Selected teams will receive a scoped review, security-related recommendations, and assistance to improve security posture at no cost. Spots are limited—apply now.

Empowering builders on Base with proactive security reviews

We’re extending our security offering upstream by proactively supporting builders in their security practices—reviewing their smart contracts during the development process and helping to identify and mitigate some of the potential vulnerabilities before they become critical issues.

The Coinbase Protocol Security team has conducted extensive audits across various DeFi protocols, including many on Base, and has started developing a streamlined process focusing on high-risk areas, leveraging static analysis and cutting-edge AI-based tooling.

This new beta program provides complimentary security reviews to help builders strengthen their protocols. This initiative leverages the expertise of Coinbase’s Protocol Security team (ProtoSec), offering builders the opportunity to benefit from our deep experience in securing onchain protocols.

How it works

Selected builders will receive:

• Smart contract and security practice reviews: Coinbase’s Protocol Security team will perform targeted reviews focused on identifying certain critical vulnerabilities using advanced static analysis tools and AI-powered insights.

• Security-related recommendations: Builders will receive clear, prioritized recommendations tailored specifically to their protocol's unique risks.

• Ongoing support: We’ll actively engage with builder teams throughout the review process and offer best practices to enhance their security posture.

Building a more secure onchain future

We’re committed to fostering a secure and transparent environment for everyone on Base, and will continue expanding our security offering to empower more builders to deploy secure onchain apps and protocols.

In this initial phase of the beta, we'll accept a limited number of applications, gradually expanding the program over the coming months. If you’re selected, you’ll receive direct communication with details on next steps. Apply here.

And if you’re interested in helping us build a global economy that increases innovation, creativity, and freedom, we’re hiring — and we’d love to hear from you.

Follow us on social to stay up to date with the latest: X (Base team on X) | Farcaster | Discord

Disclaimer: While these reviews are a powerful resource, they’re designed to complement, not replace, formal audits and other security practices. Builders remain fully responsible for their security and should pursue comprehensive third-party audits from formal security auditors. Coinbase does not provide any guarantees as to the accuracy of the reviews or any suggested mitigations. Selected protocols will be required to accept applicable terms of service before enrolling in the beta program.

What is Base Account?

Base Account is the onchain account and identity layer powering the new Base app. Onchain, it’s built on our Smart Wallet platform and Basenames. Offchain, Base Account provides a private and secure place to store personal information like name, email, phone number, and shipping address for easy sharing with apps. 

Every existing Coinbase Wallet user with a Smart Wallet has a Base Account on day one – over 185k accounts. Every new user of the Base app will be using Base Account by default. We will be sharing migration paths to Base Account for EOA users over the coming months: see our migration guide to ensure all users can continue to use your app.  

Users can manage their Base Account within the Base app or at account.base.app.

What’s New in the SDK?

The Base Account SDK is streamlined and has new tools that make it easier than ever for builders to make amazing apps. All of our documentation can be found here.

Pay

There is a new pay module in the SDK, with simple functions for onchain USDC payments.

import { pay } from '@base-org/account/pay'; 

const payment = await pay({ amount: "25.00", "0xYourWalletAddressHere" });

const response = await getPaymentStatus({ transactionId: payment.transactionId });

UI Components

The SDK now comes with UI Components for standardized buttons:

• “Sign in with Base” or “Base” for authentication contexts

• “Base Pay” for payments contexts

// Also available in Vue/Preact/Svelte
import { BasePayButton, SignInWithBaseButton } from '@base-org/account-ui/react';

function SignIn() {
  return (
    <SignInWithBaseButton 
      onClick={handleClick}
      align="center"
      variant="solid"
      colorScheme="system"
    />
  );
}

function PayComponent() {
  return (
    <BasePayButton 
      onClick={handlePay}
      colorScheme="system"
    />
  );
}

See our UI Component documentation for more info. 

Sub Accounts

Sub accounts are live on mainnets in the new SDK. Sub Accounts have been live on testnet since February. They unlock seamless in-app transactions and allow users to aggregate and manage all of their app accounts on account.base.app. See our Sub Account documentation for more info. 

Our Vision 

Our mission is to build a universal and self-sovereign account for the open internet. We want to provide users with an account they control and that works with them across all apps and chains.

We want the Base Account SDK to be the easiest way for developers to build onchain: connecting them to thousands of funded accounts, with quick and easy ways to request sharing of things like email and shipping address. 

We’re just getting started, and there’s so much more to do: still day 1. We’re excited to build with you.

Base’s mission is to build a global onchain economy. To achieve this, we’re committed to continuously scaling Base so it can serve as a platform for billions of people to come onchain.

Over the past month, we’ve seen more onchain activity than ever before, with various breakout apps bringing 10x more traffic to Base. For instance, Base recently saw blocks with over 1.5k transactions per second during the Solace launch on Virtuals, with median fees of remaining under 5 cents:

As Base continues to grow, our scaling approach is evolving to ensure the network can sustain high traffic periods while maintaining sub-cent transaction fees. Our proactive scaling efforts have successfully handled significant surges in network activity, and we’re continuing to enhance our strategy to support the next generation of apps bringing 100x more traffic to Base.

Our new scaling strategy focuses on optimizing the fee market mechanism to effectively manage network congestion and user demand. Our scaling plan involves several key approaches:

1. Adjusting the elasticity ratio to control traffic flow and provide a better user experience

2. Updating dynamic fee parameters to improve fee responsiveness

3. Enhancing network capacity through targeted infrastructure improvements

This approach ensures that as more people come onchain, they benefit from both affordable fees and fast onchain UX, even during peak times.

We build in the open, and want to share our learnings as we continue to scale. Here’s more on our progress so far, what’s next, and how we’ll continue to scale Base to serve as a platform for the global onchain economy.

Our scaling approach thus far: Increasing gas target from 2.5 Mgas/s to 35 Mgas/s

To date, we’ve increased Base's throughput by continuously raising the network’s gas target—starting 2.5 Mgas/s at launch and increasing it to 35 Mgas/s so far. Prior to scaling, we saw median fees around ~30 cents. Our scaling efforts have lowered median transaction fees >10x to fractions of a cent. Increasing Base’s throughput future-proofs the network so that it can sustain even bigger spikes in traffic.

However, with fees now so low, we’re shifting our focus to better sustain periods of high traffic with greater throughput while continuing to maintain low fees. To better understand how we’re approaching this, we must first provide some context on the fee market mechanism on Base.

Explaining the fee market mechanism on Base

The transaction fees that control traffic on Base include “base fees” and “priority fees”. This can be compared to an amusement park, where the base fee is the cost to enter the park, and the priority fee is an extra amount you may choose to pay to skip a long line for a ride.

In ideal circumstances, this fast lane enables someone to get a front row seat on the ride, but causes minimal delays to the people in the standard lane. However, sometimes someone in the standard lane could end up waiting indefinitely as new people keep paying extra to skip ahead via the fast lane.

The base and priority fees are used to keep Base’s throughput close to the gas target. This is done via the EIP-1559 fee mechanism: when a block is above target, base fees rise, and when the block is below target, base fees get cheaper. Due to this, average gas used or throughput stabilizes around the gas target.

The “gas limit” dictates the upper bound capacity of a block. Today, the gas limit is 70 Mgas/s and the gas target is half of that at 35 Mgas/s. Given Base’s 2 second block times, this means the gas limit is 140 Mgas/block and target is 70 Mgas/block. This can be visualized in block explorers, where the following block used slightly above the gas target:

The gas target is essentially the ideal and sustainable number of guests in an amusement park, where everyone is still having a positive experience. The gas limit is the maximum capacity of the park.

Our observations from scaling thus far

As we proactively scale Base by increasing our gas target alongside the gas limit, we have observed a few trends:

• Bloated Gas Target: our current gas target (35 Mgas/s) is higher than the sustained organic traffic on Base. Consequently, we are observing higher rates of spam and inefficient resource usage. Essentially, the amusement park is not at ideal capacity - guests are paying very low fees, but it’s not a sustainable model for the park.

• Slow Fee Responsiveness and Reliance on Priority Fees: During traffic spikes, fees have not risen fast enough to account for this increased activity. During peak traffic, some people may submit transactions to the Base mempool, but end up waiting a long time for their transaction to get included, if it ever does. People turn to paying additional priority fees to avoid lines, and only those who pay these extra fees end up having a decent experience. Those in the standard lane pay a deceptively low ticket price to enter the park, but then get stuck in a long, stagnant line for a ride.

• Scaling bottlenecks: Somewhat tangential to the other observations, we acknowledge that Base is functioning around the limits of certain scaling bottlenecks, which we have discussed in the past. Two specific constraints prevent us from scaling significantly at the moment:

  • Geth constraints: node providers sometimes report issues with Geth nodes keeping up during peaks in traffic. Our efforts to migrate to Reth, and some amount of optimizing Geth should reduce this constraint significantly.

  • L1 DA limits: Despite the increase of L1 blobs in the recent Pectra hardfork, L1 data availability capacity is still limited, and Base can still exceed these limits at its current gas target. We are actively supporting PeerDAS efforts for the upcoming Fusaka hard fork, which will provide much more wiggle room here.

To understand our path forward, we are reorienting around what our core goals of scaling are: we aim to maintain low fees on Base to bring more people onchain. But simply lowering fees by increasing throughput is not the ultimate marker of success. Importantly, changes in traffic patterns should not degrade user experience or chain functionality.

Creating a healthier fee market

We started making modifications to our fee market to create a better experience for users and ensure the chain is functioning in a stable and sustainable way.

Scaling while reducing throughput

To reduce reliance on priority fees, the base fees need to better control traffic – i.e. people would be better served by paying a fair price to enter an amusement park that isn't overly crowded. If the base fee functions properly, this is like making entrance pricing more expensive during peak times like weekends and holidays, to control traffic and incentivize those with flexibility to come when it’s less busy. This model should make the number of visitors to the park more evenly distributed across days. 

We are planning to achieve this by modifying the ratio between gas target and gas limit, also called “elasticity”. As described, this is currently a 2x elasticity ratio, with gas limit being double the gas target. Moving to a higher ratio allows base fees to better signal network congestion. This reduces the need for users to engage in speculative priority fee bidding.

As a result, users are less likely to experience delays in transaction inclusion during traffic spikes. They’ll receive more immediate feedback via an error response if their transaction has too low of a base fee, as opposed to their transaction sitting in the mempool for a long time because they did not pay enough priority fees.

We’ve decided to update elasticity to 3x by reducing the gas target from 35 Mgas/s to 25 Mgas/s, and increasing the gas limit from 70 Mgas/s to 75 Mgas/s. This accomplishes a few things:

• Continuing to scale: Gas limit ultimately dictates the burst capacity of Base, so this change allows Base to continue scaling

• Scaling safely: If we kept the gas target the same and moved to a 3x elasticity, we would need to increase the gas limit by 50% to 105 Mgas/s. By making a jump this large, we cannot ensure the health and stability of Base nodes, most of which are operated outside of the Base team.

• Avoiding L1 DA Limits: Reducing the gas target will ensure we do not exceed healthy L1 DA consumption levels, while this is still a scaling constraint.

More responsive fees

In addition to modifying elasticity, we are adjusting the rate at which fees increase via the “EIP-1559 denominator” value. This makes the base fee respond even more dynamically to account for network congestion, similar to how rideshare app prices update in real time. We have already made modifications to this parameter and seen the fee markets successfully adapting to network congestion more effectively. A higher elasticity value enables a larger range of values here.

Wallet providers should be aware of these changes to make base fees more responsive to transaction demand. Transactions should account for this variability by setting the 1559 maxFeePerGas field to a multiple of the latest baseFee. We still intend to keep fees very low (<1 cent) for most use cases, to give users the best experience on Base.

Additional explorations

We will continue to evaluate usage of the chain, including the fee market, and explore other ideas to create a healthy ecosystem on Base. Some ideas include:

• Implementing a minimum base fee: this should disincentivize spam, but also be low enough that users do not notice an impact.  

• Adjusting calldata costs to better account for the upper bound of Ethereum L1 DA constraints. 

• Repricing other opcodes to more accurately reflect execution times and therefore more predictably estimate a “fair” fee.

• Redesigning the mempool to better support traffic bursts and provide users more transparency and ability to modify transactions submitted to the sequencer.

• Explore multidimensional and localized fee markets to reduce the impact of high traffic for certain launches on everyday chain usage.

These ideas range in complexity and tradeoffs, and we will continue to explore and analyze them based on data and observations.

What’s next

We will soon increase the gas limit from 70 Mgas/s to 75 Mgas/s and simultaneously reduce the gas target from 35 Mgas/s to 25 Mgas/s. We will continue to monitor and track activity on Base to see how these types of changes impact network functionality. We are also working to redefine our North Star metric for scaling, which has historically been anchored on throughput – since we believe this captures only part of the full picture of our scaling goals.

We continue to scale Base, so it can serve as a platform for billions of people and millions of builders. But it’s still Day 1 - we continue to evaluate the success of our scaling efforts and iterate to maintain low fees for users, thus allowing the world to come onchain.

If you’re interested in helping us build a global economy that increases innovation, creativity, and freedom, we’re hiring — and we’d love to hear from you.

Follow us on social to stay up to date with the latest: X (Base team on X) | Farcaster | Discord

This protocol brings sophisticated, multi-step payment flows onchain, while preserving crypto’s core advantages of speed, low cost, and global reach. It bridges the promise of crypto with the realities of commerce.

Available now on Base and open to all developers, this protocol powers Shopify’s new USDC payment method, which is rolling out to millions of stores using Shopify Payments. This means merchants worldwide can soon accept USDC on Base seamlessly through Shopify Payments.

Why Crypto Payments Matter

Crypto payments with Base improve the traditional payment experience and unlock entirely new opportunities. Payments settle faster, cheaper, globally and without intermediaries. Onchain payments are also programmable, carrying not just value but also instructions that can trigger other actions across the financial ecosystem.

Faster

For cashflow-conscious businesses, the difference between having money now and having money next week can be existential. For goods and services that are delivered immediately, delayed settlement puts merchants at risk of bounced payments and being at a loss. On Base, payments can land as quickly as 200 milliseconds, even across international borders, providing an unmatched merchant experience.

Cheaper

Transaction fees imposed by existing payment networks can detract a significant amount of merchants’ take-home profits, especially internationally. Transaction fees on Base are dramatically cheaper at typically less than $0.01 and consistently decreasing as network capacity grows. Base’s cheaper fees enable a more fluid economy where commerce can put more value in the pockets of those creating it.

Globally Accessible

Base is internet-native and does not have borders. Anyone with an internet connection can have the opportunity to transact in a global economy. This opens up new markets for merchants and access to goods and services for buyers around the world.

Composable

Existing financial infrastructure is a patchwork of different gatekeepers and standards. This increases the difficulty of building integrated systems and leads to a proliferation of different apps and accounts for users, complicating the experience for everyone. Blockchains establish a shared ledger that enables different systems to reference the same source of truth. This has led to the emergence of shared standards that simplify the integration process, empowering developers to build novel, interconnected experiences that benefit all.

Commerce: The Missing Piece

Crypto payments have been around for many years, but large-scale commerce has lagged. 

Fifteen years ago, someone successfully paid for two pizzas with Bitcoin. Most onchain payments today still have not deviated from these direct token transfer implementations. We have been unfortunately stuck in a local maximum that works enough for basic things but not beyond.

Commerce demands more sophistication. Commercial payments involve race conditions between checkout, settlement, and fulfillment. Inventory can sell out between completing checkout and payment processing. Tax obligations can change between checkout and settlement. Buyers or merchants may want to cancel partial or full orders and refund payment.

Traditional finance addresses some of these concerns by separating buyer approval (e.g. entering card details) from the asynchronous checks a storefront performs before executing payment. The crypto analogy is letting buyers sign off on spending funds without immediately broadcasting a blockchain transaction.

After buyers approve a payment, funds must be locked while still allowing either party to cancel if needed. Traditional payments handle this with a two-step “authorize and capture” process: first locking buyer funds (authorize), then disbursing them to the merchant (capture).

This simple pattern has supported commerce complexities well before blockchains by providing:

• Merchant protection through payment guarantees

• Buyer protection through reserved but not yet finalized payment

• Lower costs for merchants because they only pay fees on captured payments

• Custom payment finalization by capturing in parts, potentially not up to the full amount

Until now, onchain payments have been missing this capability. To make onchain payments work for commerce at scale, we needed to design a new protocol capable of achieving the same payment properties.

Escrow Architecture

To implement authorization and capture, we introduce an escrow smart contract to sit between buyer and merchant. On authorization, funds move into the escrow from the buyer. On capture, funds move out of the escrow to the merchant. The smart contract enforces that if funds are authorized, then they are put on hold to guarantee the ability to capture at a later date. For generalization clarified later, the protocol describes a buyer as “payer” and merchant as “receiver” to state their purpose more plainly.

An escrow architecture also allows us to make no assumptions about the payer or receiver addresses and their capabilities. For example an alternative construction would be to introduce a locking mechanism on the payer’s wallet, but this comes with many assumptions about the payer that reduce compatibility. 

Anyone can use the escrow smart contract and no one can turn it off or change its code. This provides best-in-class guarantees for prospective integrators and users. It is meant to be shared for all payments across the ecosystem and is a hub for commerce.

Operators

Like normal payments, blockchain transactions require a fee to execute. While the status quo in crypto expects payers to incur this fee, traditional commerce places this burden on the receiver. A fee-free payer experience is important for conversion, but introduces a new problem for receivers who would have to manage blockchain transactions to authorize their payments. To resolve this friction, we introduce a new role called an operator to facilitate movement of funds between the transacting parties.

Similar to payers and receivers, the protocol is not concerned with how the operator is implemented and just recognizes it as an address. Operators could be simple externally-owned accounts or advanced smart contracts. Operators could also be controlled via API to easily integrate with existing commerce workflows. Coinbase provides such a service and the protocol is open for anyone to build their own as well.

While operators exist for payer and receiver convenience, this benefit should not supersede security. Users should not have to trust any operator or managing entity to be safe. We have invested in multiple efforts to limit the controls given to operators to stay true to this crypto ethos.

First, operators cannot modify the original payment intent of the payer. This includes things like the receiver address, token of payment, maximum amount to be paid, and expiries for authorization and other operations. We mitigate the ability for operators to mutate any of these fields by having the payer sign over a hash of these details. By hashing this information, we probabilistically guarantee that any change to any field will result in a new hash easily identifiable as different from the original. By signing over this hash, we guarantee that a given set of payment information is aligned with the payer’s intent. Additionally, the protocol rejects attempts at using a signed payment more than once.

Second, operators cannot lock funds in the escrow. If the authorization expires and the operator has not yet captured or voided the payment, the payer is able to reclaim funds directly from the escrow without operator intervention. This hopefully never needs to happen as this mitigation and lack of incentive is not clearly worth a potentially malicious operator’s time.

Third, operators cannot impact the activities of another operator. Given anyone can become an operator, this is important to protect all honest actors even if some begin to act maliciously. The operator address is encoded into the payment information sealed by the payer in the signing process. This guarantees that only one operator can manage the payment through its lifecycle. Additionally, the payments managed by different operators are escrowed in different buckets. This measure proactively reduces the risk of a theoretical vulnerability being discovered in the future. You can read more about our security preparation here.

Payment Operations

The protocol implements six core operations that cover the complete payment lifecycle:

1. authorize: transfer funds from payer to escrow

2. capture: transfer funds from escrow to receiver

3. charge: transfer funds from payer to escrow to receiver (1-step authorization + capture)

4. void: return of uncaptured funds from escrow to payer

5. reclaim: payer-initiated void, only available after authorization expires

6. refund: return of captured funds to payer
   

Each operation updates payment accounting in the protocol, tracking authorized payments available for capture and captured payments available for refund. The protocol enforces that payment transitions only occur in the valid time window defined by the payment’s various expiries.

Authorize

Reserve payer funds in escrow for future capture, enabling delayed settlement and guaranteeing merchant payment. The protocol leaves collecting funds from payers open-ended and extensible, but our initial implementation integrates with the ERC-3009 standard. This standard allows payers of all wallet types to grant permission to spend funds with just a signature, deferring transactions to operators. The protocol enforces that “pre-approvals” like this signature must be used to authorize payment before an expiry.

Capture

Transfer authorized funds from escrow to receivers to finalize payment. Captures can be made in multiple partial increments to support merchants that may fulfill goods in multiple deliveries. The protocol enforces that the total captured amount cannot exceed the authorized amount. Captures must be made before the authorization expires, defined at the time of payment signing.

Charge

Combines authorization and capture into a single transaction to improve efficiency for payments that do not require delayed captures. Follows the same flexible payment collection and pre-approval expiry patterns as authorize. This is analogous to the “sale” credit card transaction type.

Void

Cancel an authorized payment, returning escrowed funds back to the payer. Used to cancel transactions for errors potentially unrelated to payment or if merchants are no longer able to fulfill the order. Can be made at any time but only once per payment, reversing the entire remaining authorized amount.

Reclaim

Effectively a payer-initiated void where payers retrieve their own funds from the escrow. Can only be performed if an authorization has expired and serves primarily as a safety mechanism against malfunctioning operators. This is the only payment operation not controlled by the operator.

Refund

Return funds to payers after payment has been captured to the receiver. The protocol leaves collecting funds for payers open-ended and extensible, but our initial implementation integrates with the ERC-3009 standard. We use this standard to add flexibility to withdraw capital from multiple potential sources such as the receiver, another merchant-controlled address, or the operator. Refunds must be made before an expiry after which captured payments are considered final.

Example Payment Flow

To start paying with crypto, a merchant storefront requests a buyer to sign payment information with their wallet. The merchant storefront requests payment authorization from an operator service, providing the signed payment information. The operator service submits a blockchain transaction, directing the operator to call the escrow smart contract to authorize the provided payment. On successful execution, the buyer is given confirmation that they have paid. At a later point in time, the merchant can capture or void this payment.

Build With Us

Coinbase and Shopify are stewards of the protocol and its initial participants, but the protocol is open. Anyone can build on it and no one can shut it off.

The core of the protocol is radically simple with only 6 payment operations. This helped us reach confidence in its security, but also left open the potential to build new features on top of this foundation.

To call out a few design directions we are excited about:

1. Operator smart contracts. As the drivers of money movement, composing payment with additional smart contract systems is powerful at the operator layer. It is also possible here to peel back some of the control given to 3rd parties and delegate operations to other roles or back to payers and receivers.

2. Receiver smart contracts. Layer in revenue splits, currency swaps, privacy systems, and more.

3. Token Collector smart contracts. Our exact mechanics for collecting tokens for payment and refunds are under-discussed thus far for brevity. We originally implemented an integration with ERC-3009 to support gas-less payments with USDC, but many other opportunities exist for signing payment authorization. This pattern also extends to refunds where liquidity to make a payer whole can come from any location, allowing more flexible resolution between operator and merchant. Opportunities for discounts, chain abstraction, and paying with any token likely exist here.

For a complete breakdown of the protocol, find the full implementation and documentation here. You can also reach out with questions in the Base Discord server.

The future of commerce is onchain, permissionless, and decentralized. The infrastructure is ready. Now it's time to build.