Chapter 29 · What Crypto BD Actually Connects

A Real-World Problem

Two BD professionals, the same protocol, the same quarter.

The first reports over 400 new contacts, six industry conferences, more than thirty prospective partnerships, and twelve joint announcements. Every announcement says “strategic partnership,” with attractive graphics.

The second reports only three lines:

A wallet added an entry point to our protocol on its asset page
A market maker began continuous quoting on two trading pairs
Widely used infrastructure integrated our data interface

Three things in one quarter. The first person's presentation is clearly thicker.

Six months later, none of the first person's twelve announcements corresponds to a measurable curve change. Using Chapter 23, active addresses, volume, and inflows show no discernible change around announcement dates.

Each of the second person's outcomes corresponds to a curve: wallet-originated calls become a major source of new users; typical-trade slippage drops an order of magnitude after market making starts; three new products integrate the data interface without needing discussions.

The same role and period produced entirely different outputs.

This chapter asks: what is BD's output if it is not contact count, and how do you know it occurred?

Thought Experiment

You open a bakery in an unfamiliar city. During the first week, you list whom you need.

The list splits into categories, each wanting entirely different things:

Suppliers. Flour, butter, packaging. They want stable orders and timely payment. You offer predictable purchasing and evidence that the shop will survive.

People who sell for you. Delivery platforms, the neighboring café, office receptionists. They want something that pleases their customers without creating work. You offer consistent quality and an effortless handoff.

People who make you visible. A mall places your sign at its entrance or in a basement corner. It wants entrance tenants who bring traffic without damaging its reputation.

People lending money. They want repayment. You offer credible accounts.

People teaching or endorsing you. A respected baker lending their name wants protection of their reputation.

Notice: you want partnership, but nobody else wants partnership itself. Each wants a specific outcome tied to their own evaluation.

Every negotiation therefore fits three lines:

What I want:       Which of my curves it affects
What I offer:      Which of their curves it affects
Why they agree:    Where this ranks among their evaluation criteria

Without the third line, cooperation will not happen—or will not be executed if agreed.

Add one layer: the mall signs a strategic partnership agreement and both issue announcements, but it ultimately places you in the basement.

The announcement is real; the partnership is not. The difference is a concrete action completed and visible to a third party.

Replace the bakery with a protocol and the model applies unchanged. One difference: on-chain, third parties can usually verify completed actions directly.

Your Decision

A new protocol has one BD professional and three months. Choose the first of four routes.

What Happens

The routes differ, but all outputs fit three categories:

BD connects liquidity, distribution, and integration—not the length of an address book.

The practical common property: all are third-party verifiable, mostly on-chain.

Apply four questions to any partnership:

The industry's blunt but accurate name for partnerships answering none is announcement as delivery.

Announcements themselves have value for hiring, fundraising, and community mood. The problem is evaluating them as BD output. They are a partnership's byproduct, not the partnership.

Build a Model

Resource Network: Six Roles

Map the resources around a protocol into six roles:

Expand them. This table is the chapter's core; write it down:

Column four is most BD professionals' weakest because it requires understanding your product: depth, permissions, interface stability, and available data.

This is why BD appears in stage five: without liquidity from Chapter 15, permissions from Chapter 24, and revenue allocation from Chapter 26, column four stays blank. BD can then only discuss column one.

Exchange Model: Three Questions

Before the first email, answer:

1. What metric evaluates the counterparty? Their year-end number, not their vision.
2. Can I directly improve it? If yes, how? If no, find another angle.
3. If not, what is this partnership? Probably PR; execute and evaluate it as PR.

The first question is the model's center and most often skipped.

Wallets measure retention and revenue; market makers measure risk-adjusted returns; foundations measure ecosystem projects and usage; venues measure volume and compliance risk; integrating developers may simply ask whether integration creates extra work.

Sending identical materials to all six roles is a common inefficient habit.

Prioritize by Dependence on Market Sentiment

BD resources are limited. A better ordering criterion than pursuing the biggest partner is:

In Chapter 28's funnel, tier one affects distribution with no expiry date; tier three affects attention, whose half-life is measured in days.

An exception: during bootstrapping, tier two often precedes tier one. Without depth, wallets and integrators stay away. Reach acceptable depth before pursuing distribution.

Proposal Structure

An effective proposal has four paragraphs within one screen:

Paragraph one: Who we are, one sentence with a verifiable number.
               Not “leading,” but “X addresses completed Y transactions in
               the past thirty days, verifiable here.”

Paragraph two: The specific action we want.
               Not “explore cooperation,” but “add this route to your swap page.”

Paragraph three: Which of your metrics it improves, and why.
                 The letter's core and most commonly missing paragraph.

Paragraph four: What is already ready.
                Interface docs, audit, testnet, contact, and schedule.

Paragraph three cannot be outsourced to a template. It requires knowing the counterparty's evaluation, inferred from products, public materials, and past partnerships.

Paragraph four lowers their startup cost. Many partnerships are postponed indefinitely rather than rejected because preparation is burdensome. Do it beforehand and become a ready option rather than a request.

What It Is Called

Hands-on

select
  tx_from                   as caller,
  count(*)                  as calls,
  count(distinct tx_hash)   as txs
from <platform event table>
where contract_address = <protocol main contract>
  and block_time >= now() - interval '30' day
group by 1
order by 2 desc
limit 50

Label:       The specific entity
Thickness:   Actual contribution: calls, depth, or share of user origins
Color:       Verified / announcement only / unavailable

Strongest resource category: ______, supported by ______
Weakest category: ______, supported by ______
As its BD, next quarter I would prioritize: ______, because ______

AI Lab

Draft a four-paragraph partnership proposal, no longer than one screen.

Us: <protocol, purpose, one verifiable datapoint and source>
Them: <identity and which of the six roles>
Specific proposed action: <one sentence with a deliverable>

Paragraph one: Who we are, with a verifiable number and lookup location.
Paragraph two: The concrete action, deliverable, and timing.
Paragraph three: Which of their metrics this improves.
                 State their likely core metric, then how this advances it.
                 If unknown, write “I do not know”; do not invent it.
Paragraph four: Ready materials: docs, audits, test environment, contact, schedule.

Rules:
- Avoid “leading,” “revolutionary,” and “strategic partnership.”
- Make no promises we cannot fulfill.
- Invent no precedents or data; source every figure.
- If paragraph three is impossible, state the missing information.

Real-World Case

Change One Variable

Takeaway Questions

Chapter Check