Builder Codes let Base identify which app originated a transaction. ERC-8021 defines the attribution suffix that the app appends to the transaction calldata.

This solves a common attribution problem: a protocol can see which wallet called its contract, but it cannot normally tell whether the transaction came from a particular frontend, wallet, aggregator, or agent.

• The ERC-8021 suffix contains the attribution code, its encoding metadata, and a fixed marker at the end: 0x80218021802180218021802180218021
• An indexer reads backward from the end of the calldata, identifies the marker, and extracts the Builder Code. The target contract continues to decode its normal function arguments from the beginning of the calldata.
• For contracts using standard ABI decoding, no contract upgrade or ABI change is required. The attribution is added by the app or wallet when it constructs the transaction.
• Base provides the first ERC-8021 Code Registry. Builders can claim a code and append it with supported libraries and wallet flows. The result is a verifiable record of which app generated each attributed transaction.
• That data can support app leaderboards, builder rewards, referral fees, and analysis of which integrations generate meaningful activity.

Curious to learn more? We wrote a technical breakdown of the suffix, parsing flow, and implementation options here: https://formo.so/blog/builder-codes-erc-8021-explained

--

For Base builders: have you implemented Builder Codes yet? Which wallet or transaction stack are you using, and did you encounter any compatibility issues?

A DeFi tracking plan defines each analytics event, when it fires, and the properties it carries. Without one, frontend events and onchain metrics quickly drift apart and you''ll struggle to measure ROI.

Based on work with builders in DeFi, we created a practical event taxonomy for DEXs, lending apps, and yield vaults.

The naming convention is `[Object] + [Past-Tense Action]`:

• `Swap Initiated`
• `Swap Completed`
• `Supply Completed`
• `Deposit Initiated`
• `Vault Viewed`

Start with the core conversion events.

• DEX: `Swap Review Opened`, `Swap Initiated`, `Swap Completed`, `Swap Failed
• Lending: `Supply Initiated`, `Supply Completed`, `Borrow Initiated`, `Borrow Completed`, `Liquidation Occurred`
• Yield vault: `Deposit Initiated`, `Deposit Completed`, `Withdraw Initiated`, `Withdraw Completed`

And some best practices from real-world projects:

1. Fire intent events before the wallet confirmation prompt e.g. 'Swap Initiated'.

2. Fire completion events only after onchain confirmation. Send filled events for order completion.

3. Include USD `volume` on volume-generating events and protocol `revenue` where applicable.

4. Capture liquidations and other asynchronous events from a backend or indexer.

5. Start with your the core funnel before adding discovery, UI events, and other non-conversion events.

Code example:

formo.track("Swap Initiated", {

from_token: "ETH",

to_token: "USDC",

pair: "ETH/USDC",

chain: "base",

volume: 1000

})

Interested to learn more? The full DeFi tracking plan comes with event triggers and property schemas for all major DeFi app verticals: https://formo.so/blog/defi-analytics-tracking-plan

You have no more excuses on not having analytics for your onchain app!

Formo is an analytics platform for onchain apps. We recently added an MCP server so AI agents can query product analytics and onchain data, then act on the results.

It covers:

• Web traffic and acquisition sources
• Product events and funnels
• Wallet connections and onchain transactions
• Revenue and transaction volume
• Retention cohorts
• Wallet profiles, including tokens, chains, and DeFi positions

Example questions include you can ask:

1. Which campaign brought in wallets that completed a transaction?
2. Where do users drop off between wallet connect and first swap?
3. What is D30 retention by acquisition source?
4. Which tokens and protocols are our users interacting with?

Technical overview and tool examples:

https://formo.so/blog/formo-mcp

For people building analytics / data-heavy MCP servers: what has the experience been like? Are you exposing typed tools, read-only SQL, offer text-to-SQL capabailities? What are your learnings so far?

Onchain attribution connects marketing campaigns to wallet activity, transaction volume, protocol revenue, and user retention, closing the measurement gap that traditional analytics tools (like Google Analytics or Mixpanel) can't see past the moment a user connects their wallet.

This guide breaks down why traditional attribution breaks in DeFi, the three core onchain attribution methods, and how growth teams turn wallet data into real ROI reporting.

KEY TAKEAWAYS

• Onchain attribution links GTM/marketing campaigns to wallet activity, protocol revenue, transaction volume, and retention.
• A report from Oct 2025 found 70% of DeFi projects fail to demonstrate marketing ROI, a direct result of using tarditional analytics tools that lose visibility onchain.
• The three core attribution methods are: UTM-to-wallet attribution, referrer-based attribution, and builder code (onchain referral) attribution.
• Multi-wallet identity resolution is essential; without it, CAC looks inflated and retention looks worse than it is.
• Multi-touch attribution models can improve CPA efficiency by 14–36% vs. single-touch models (Impact, 2025).

TIMESTAMPS

00:00 The onchain attribution gap
00:28 Why traditional analytics tools break in DeFi
01:05 DeFi in 2026, by the numbers
01:41 The 3 core attribution methods (UTM, referrer, builder code)
02:14 Attribution models: first-touch vs last-touch vs multi-touch
03:01 Why wallets ≠ users (identity resolution)
03:34 The metrics that matter (CPT, LTV, retention, revenue)
04:09 Building your attribution stack, step by step
04:34 Common attribution mistakes to avoid
04:57 How Formo solves onchain attribution

See the full video: https://www.youtube.com/watch?v=DwpOJ612jVE

To build user-facing products, you need to measure growth, understand user behavior, and prove ROI on campaigns, but the standard tools for doing this come loaded with invasive tracking, third-party cookies, and data collection practices that violate the ethos of the space.

Six years later, the tooling landscape has matured considerably. There are now niche tools, open data platforms, and multiple valid approaches to solving the analytics problem in DeFi. But the landscape is also fragmented, confusing, and full of tradeoffs that aren't obvious until you've committed significant engineering time.

This guide covers the major platforms, the do-it-yourself approaches, and the quirks you'll discover only after you start using them. It's written for founders and growth leads at crypto neobanks, prediction markets, and DeFi apps who need to make a decision.

Key Takeaways

• Traditional analytics tools like Google Analytics and Mixpanel break in DeFi because they cannot see wallet activity and onchain-data.
• Session-level data and onchain transaction data live in separate systems with no shared identity, making attribution, funnel analysis, and retention measurement impossible without a purpose-built layer.
• The three approaches to DeFi analytics: SaaS platforms that handle data ingestion and provide out-of-the-box dashboards (fastest time-to-value, least engineering overhead); custom data pipelines built on blockchain indexers (highest flexibility, highest engineering cost); and hybrid stacks combining both (the most common architecture at scale).
• Most teams underestimate the ongoing cost of custom analytics pipelines. New chain support, API changes, and schema migrations each require dedicated engineering time that scales with protocol complexity rather than team size.
• Using an existing analytics platform lets teams spend less time building data infrastructure & analytics, and more time shipping products users want.

https://formo.so/blog/defi-crypto-analytics-stack

Key Takeaways

• Crypto GTM starts with onchain behavior, not demographics, because wallet actions like staking, swapping, and voting reveal real intent better than Web2-style user profiles.
• Community-led and product-led growth dominate crypto adoption, as protocols like Uniswap and Aave scale by reducing onboarding friction and turning users into advocates.
• Unified analytics is the GTM edge in Web3, since linking website visits to wallet transactions lets founders measure true campaign ROI instead of guessing attribution.

Most crypto projects fail. It’s a hard truth, but one that founders must face. Often, the reason isn't a technical failure or a flawed concept. It’s a poor go-to-market (GTM) execution. While a brilliant idea can get you started, it's a deliberate GTM strategy that drives adoption, liquidity, and ultimately, success. Companies like Uniswap and Aave didn't just build great products; they built a playbook to get those products into users' hands.

For crypto startups, a GTM strategy is the blueprint for acquiring users, driving onchain activity, and building sustainable revenue. Yet, our discovery calls with web3 teams show that user acquisition and product analytics remain their biggest challenges. Traditional GTM playbooks fall short because they don't account for the unique dynamics of web3, like pseudonymous users and onchain data.

This guide is for you, the onchain builder. We’ll cover the core components of a crypto-native GTM strategy, explore effective growth motions, and show you how to use data to make decisions that lead to real growth.

https://formo.so/blog/crypto-gtm-strategy

Are you launching on mainnet? Here's a guide for you: https://formo.so/blog/defi-testnet-to-mainnet-launch

Key Takeaways

• Testnet traction does not predict mainnet adoption. Testnet users are experimenting with test tokens, not committing real capital. Most testnet activity is noise.
• What matters on testnet is one thing: can your target user complete the core action end-to-end without help? Raw user counts and transaction volumes do not matter.
• You are ready for mainnet when onboarding works, analytics are instrumented, liquidity is seeded, and docs are live. If growth has to guess what is breaking, you are not ready.

Key Takeaways

• KOL campaigns work when built around a narrative, an ICP-matched creator, and multi-week exposure, not a single post.
• Impressions and follower growth measure distribution only, not whether users connected a wallet or completed any onchain action.
• Web3 attribution breaks at the wallet: offchain clicks and onchain conversions are invisible to standard analytics tools.
• Referral and UTM persistence through wallet connection is the single most impactful fix for KOL attribution most teams skip.
• Cost per activated wallet, not cost per click, is the metric that makes KOL spend comparable to any other channel.

https://formo.so/blog/defi-kol-campaign-measurement

Key Takeaways

• Glamsterdam is Ethereum's next major hard fork, combining the Amsterdam (execution layer) and Gloas (consensus layer) upgrades. It is planned for Q3 2026, though the exact timeline remains subject to devnet testing progress.
• Parallel transaction processing arrives via EIP-7928 (Block-Level Access Lists). Nodes can now see which transactions do not conflict and process them simultaneously, laying the groundwork for significantly higher gas limits.
• Third-party relays are no longer required. EIP-7732 enshrines proposer-builder separation directly into the protocol, reducing centralisation risk and expanding the block propagation window from 2 seconds to roughly 9 seconds.
• State creation and access get repriced. EIP-8037 introduces a cost-per-state-byte model targeting 120 GiB/year growth, while EIP-8038 updates state-access opcode costs to reflect modern hardware. Both changes affect contract deployment and storage-heavy applications.
• ETH transfers now emit a standard log. EIP-7708 closes a long-standing blind spot: every non-zero ETH transfer or burn will produce a trackable event, removing the need for custom tracing in bridges, exchanges, and wallets.
• Cross-chain address consistency is solved. EIP-7997 mandates a universal CREATE2 factory across all participating EVM chains, giving developers deterministic addresses without chain-specific deployment scripts.
• No action required for ETH holders. Balances and existing contracts are completely unaffected. Node operators and stakers must update client software before mainnet activation.

https://formo.so/blog/ethereum-glamsterdam-upgrade