How Crypto BD Teams Use Onchain Data

Crypto BD teams use onchain data to find integration partners, measure what each integration brings, and report results that partners trust. Onchain data shows which apps your users already touch, how many users two protocols share, and how much volume flows through each integration. Paired with first-party analytics, it turns partnership decisions from opinion into evidence.

What onchain data matters for crypto BD?

The onchain data that matters for BD answers three questions: who your users are elsewhere, who sends you users and volume, and whether those users stay. Public blockchain data covers the first question. Your own analytics, joined to wallets, covers the other two. A BD lead needs both.

If you are building the wider data function first, our data strategy guide for crypto founders covers the stack and the team. This article is about how BD uses that data.

How do you find partners from onchain data?

Find partners by starting with your own users and asking where else they spend time. The apps, chains, and tokens your users already use point to integrations that feel natural to them. A partner with a large share of your users is easier to pitch, because the integration serves people who already use both products.

1. List the apps your users use. In Formo, the Users page can filter "users who use app X and Y", and Top apps shows the most popular apps used by wallets in your audience. App data comes from DeFi positions on supported EVM chains and does not cover every wallet or protocol. Solana wallets show token balances only.

2. Weight by value, not by count. Ten whales on one lending market can matter more than a thousand dust wallets on a DEX. Filter apps by position size, for example users of a protocol with more than a set balance.

3. Look at your best users separately. Build a segment of power users or high-volume wallets, then check which apps they use. Their stack shows where your most valuable audience lives.

4. Check chains and tokens. If many of your users hold a token you do not support, or sit on a chain you are not on, that is an integration lead for the BD pipeline.

5. Map the contracts. For each candidate, note the contracts your users call. These become the contracts you track after launch.

Qualify partners

A long list is easy. A short list needs criteria. Score each candidate on:

• Overlap: the share of your users who also use the partner. High overlap means easy adoption; very high overlap can mean little new reach.

• Reach: how many of the partner's users you do not have yet. This is the growth case.

• Quality: wallet age, net worth, and activity of the shared users.

• Fit: whether a real product flow connects the two apps, such as a vault that uses a lending market or a wallet that routes swaps.

• Measurability: whether the partner will add a referral code or builder code so you can count results.

How do you measure partnership and integration impact?

Measure integration impact with two tools: a tag on the users or transactions the partner sends, and a before and after comparison of your own metrics. The tag gives you direct attribution. The comparison catches effects that tags miss, such as users who hear about you through the partner and arrive directly.

Tag the traffic and the transactions

• Referral codes. Give each partner a code such as ?ref=partner_name. Formo captures ref, referral, refcode, af, and referrer by default, and you can set custom parameter names or a URL path pattern.

• UTM parameters. Use utm_medium=partner and utm_source=<partner> on every partner link. You can filter users by referrer, referral, and UTM with first-touch or last-touch attribution.

• Builder codes (ERC-8021). When a partner's app builds the transaction, ask them to append an ERC-8021 builder code to the calldata. ERC-8021 is a draft standard that adds a data suffix with one or more human-readable codes to the end of the calldata, so the contract runs as normal. Formo detects builder codes automatically and makes them available as a breakdown for wallets, transactions, volume, and revenue. Builder codes describe who built the transaction. Formo parses them from transactions its SDK captures and from contract events for contracts you add, so with your contracts added they work even when the user never visits your site. For the standard itself, see our builder codes explainer.

• Contract arguments. Many protocols accept a referrer or integrator argument in their contract calls. When you add your contract, Formo decodes its events and function calls with their parameters, so you can see that argument on each event and group by it in the SQL Explorer.

Compare before and after cohorts

Tags miss some effects. Use cohorts to see the whole picture.

1. Set the dates. Pick the launch date and equal windows before and after, such as 30 days each.

2. Pick the population. Choose wallets that use the partner app (Apps filter) or wallets tagged with the partner's code.

3. Compare core metrics. New wallets, transactions, volume, and revenue in each window.

4. Compare retention. You can narrow Formo retention cohorts by referral, builder codes, or UTM parameters. If partner users retain like your organic users, the integration brings real users.

5. Control for the market. Compare against a similar segment that did not get the integration. A market rally lifts everything; the difference is the integration effect.

For product-side integration metrics, such as adoption of an integrated feature and depth of use, see DeFi integration analytics. This guide stays on the BD view: did the partnership pay off?

Watch for double counting

One user can carry a partner referral code and also send a transaction with a builder code. Count each wallet once per report, and say which tag you used. Also, Formo sums volume and revenue as you send them and does not convert currencies, so send values in USD.

How should BD teams report results to partners?

Report to partners with a short, repeatable summary: the same metrics, the same definitions, and the same date ranges every month. Partners trust numbers they can check onchain, so include transaction counts and volume that they can verify. Do not share wallet-level data unless your privacy policy and the partner agreement allow it.

A simple monthly partner report:

Formo boards and charts can hold these metrics in one place, and you can share them with your team. For finance or revenue share, connect a BI tool to Formo's SQL interface. Scheduled export to Google Cloud Storage or Amazon S3 (data sync) is in development; contact Formo support for access.

What should you track in a CRM vs in analytics?

Track relationships in the CRM and behavior in analytics. The CRM holds people, companies, deal stages, terms, and next steps. Analytics holds wallets, events, volume, and retention. Keep one shared key, such as the partner's referral code or builder code, in both systems so you can join them.

Some links between the two systems:

• Label wallets. Add a custom label to wallets that belong to a partner team or a partner's treasury, and filter users by that label.

• Push alerts to the team. Formo alerts check for matching events every 5 minutes and send them to a webhook or a Slack channel, so BD hears when a partner's first integrated transaction lands.

• Pull data with the API. The profiles API returns wallet profiles and attribution, so a CRM sync can add onchain context to a contact.

Do not copy raw event streams into the CRM. It becomes slow and stale. Store a few summary fields there, such as wallets this month and volume this month, and keep the detail in analytics.

Frequently asked questions

How do I find which protocols share users with mine?

Look at the apps your users hold positions in. In Formo, filter users by app and check Top apps for your audience. Then weight by position size and focus on your most active users, because their stack shows the strongest partner fit.

What is the best way to attribute volume to an integration partner?

Use an ERC-8021 builder code when the partner's app builds the transaction, because it travels with the transaction itself. For partners that only send traffic, use referral codes and UTMs. For contract-level integrations, use a referrer or integrator argument in the call.

How long should I measure an integration before I report results?

Use at least 30 days before and 30 days after launch, with the same window length on both sides. Then check 30-day retention of partner wallets. Short windows overstate launch spikes.

Can I share wallet-level data with partners?

Only if your privacy policy and your agreement with the partner allow it. In most cases, share aggregates: wallets, transactions, volume, and retention. Partners can verify transaction counts and volume onchain.

What is the difference between this and integration analytics?

Integration analytics is the product view: how users adopt and use an integrated feature. BD onchain data is the commercial view: which partners to pursue, whether the deal paid off, and how to report it.

Do I need a CRM if I have onchain analytics?

Yes. Analytics shows what wallets do, but not who you spoke to, what you agreed, or what comes next. Use both, joined by a shared partner code.

Related articles

• DeFi integration analytics

• Data strategy for crypto and DeFi founders

• Builder codes and ERC-8021 explained

• Onchain user segmentation

• DeFi cohort analysis

• DeFi go-to-market strategy

Glossary: builder codes, wallet profiles, wallet segmentation, cohort analysis, smart contract events, volume attribution.