N4 · Crypto BD & Ecosystem
Measure BD through three verifiable curves. Understand terms, calculate costs, and map your resource network.
This track serves business development, ecosystem, and partnership roles.
It starts with Chapter 29: BD connects liquidity, distribution, and integration rather than collecting contacts. These outputs are independently verifiable, often onchain. That property underpins the track.
Who This Track Serves
Your thick quarterly report corresponds to no changed curve. Contacts, meetings, intentions, and announcements abound, but six months later no number reflects them.
You negotiated a partnership that never executed. Both announcements and the coordination chat remain, but nothing followed. You cannot identify the broken step.
You cannot calculate a term sheet's costs. Token loans with options, listing commitments, and exclusivity scope are readable but their scenario payoffs are unclear.
Without industry contacts, you assume entry is impossible. Three of six counterpart categories barely depend on relationships; the others' real barriers are elsewhere too.
This track teaches making cooperation fit the counterparty's evaluation metrics and proving execution afterward, rather than socializing.
Prerequisites
Complete six Part A chapters. BD unable to fill what you offer in the fourth column can only discuss the first column; that is why this track follows the core.
| Required chapter | Role here | Consequence of omission |
|---|---|---|
| Chapter 15 · Liquidity | Depth, slippage, and exits | Unclear current market-making quality |
| Chapter 24 · Collapse and Attacks | Ten risks and permissions | Cannot advance wallet-entry prerequisites |
| Chapter 26 · Protocol Revenue | Distribution and realized take rates | Cannot explain concessions in revenue sharing |
| Chapter 27 · Crypto Product | Anyone can integrate you | Miss the most durable connection |
| Chapter 28 · Crypto Growth | Funnel, steps versus spikes | Cannot prioritize partnerships |
| Chapter 29 · Crypto BD | Backbone: six roles, three questions, three priority tiers, four proposal paragraphs | No framework for later work |
Also read Chapter 23 · Onchain Data. Every execution-verification question eventually uses its data methods.
Complete Chapter 29's resource-network Lab, especially tracing callers. Unfamiliar leading contracts are exceptionally valuable leads.
What You Will Learn
Ten topics form four groups, ordered by dependence on market sentiment.
- Integration and distribution
- Liquidity and venues
- Grants and ecosystems
- Institutions and lasting relationships
| Group | Topics | Problem addressed | Connecting chapters |
|---|---|---|---|
| Integration and distribution | Partnership, Wallet, Chain | Become a useful component and enter daily-use surfaces | 27, 28, 29 |
| Liquidity and venues | Liquidity, Market Maker, CEX, Listing | Sources of depth and hidden contractual costs | 15, 29 |
| Grants and ecosystems | Grant, Foundation | Turn applications into delivery and understand commitments | 29 |
| Institutions and lasting relationships | Institution | Enter the counterparty's internal processes | 24, 26 |
Three Skills to Practice
Much integration work reduces access costs rather than negotiates. Chapter 29 shows major integrations absent from announcements: developers read documentation and connect independently. Provide clear documentation, complete examples, stable interfaces, and responsive support. Integration can then happen organically.
Calculate terms before negotiating them. Token loans with options are common and lawful; the issue is whether signers calculated consequences. List price ranges and both parties' payoffs in every cell; do not sign what you cannot calculate. This follows Chapter 24's explicit-nonassessment principle.
Institutional decisions involve processes rather than one willing person. Risk, compliance, and operations need permission structures, responsibility allocation, compatible definitions, and reports in their format. Half this work organizes your own team's internal reality.
A partnership in which nothing happens beyond announcements from both sides.
Chapter 29's four tests: visible onchain, accessible in the product, documented by the partner, and a changed number. Failing all four indicates public relations rather than execution.
Announcements genuinely help hiring, fundraising, and sentiment. They are a partnership's byproduct, unsuitable as its sole performance measure.
The number they actually answer for at year end, rather than their vision.
This essential proposal component cannot be copied directly from public text. Wallets measure retention and revenue; market makers risk-adjusted returns; ecosystems projects and usage; venues volume and compliance; integration developers may simply ask whether you create extra work.
Investigate through their product, public materials such as governance and updates, and hiring, which reveals forthcoming priorities.
Final Deliverable
A resource-network map and three executable partnership proposals.
Executable means the reader knows the first action, owner, and deadline without asking questions.
Distinguish this from the Capstone Project. The capstone proves understanding. This work must be sent externally to three real counterparts and tested by their responses, rather than your completeness assessment.
Five acceptance criteria:
Complete six network cells with evidence grades.
Chains/ecosystems, wallets/entry points, market makers/liquidity, venues, foundations/grants, developers/integrations: omit none. Prioritize partner product interfaces, official documentation, onchain records, then joint announcements. Announcements come last.
Apply four tests to every announcement and report the pass ratio.
List partnerships over a defined period. Test onchain visibility, product access, partner documentation, and changed metrics. Count complete passes and complete failures. This ratio demonstrates actual BD execution and makes a persuasive table.
Address three distinct roles; paragraph three specifies their KPI and evidence.
Choose three categories rather than three counterparts of one type. Keep each four-paragraph proposal within one screen. Paragraph three cannot come from a template: identify their metric, your evidence, and your contribution to it.
Self-check: remove “your organization.” If the sentence merely praises your own team, rewrite it.
Include explicit and hidden costs for each proposal.
Explicit costs: fees, tokens, people, time. Hidden costs: ecosystem commitments, excluded opportunities from exclusivity, price-dependent option costs, and liquidity allocation rather than addition across venues. Omitting every hidden cost fails.
Specify a verifiable deliverable, schedule, and verification method.
Be as concrete as adding your route to their swap page, rather than exploring cooperation. Identify which curve changes, how to query it, and when.
Assess Your Readiness
Ready: entry-point acquisition shares, slippage at a specific size, or external-contract calls, with query methods.
Not ready: contacts, meetings, intentions, announcements. Chapter 29's thicker report matched no curve six months later.
Rewrite your quarterly report as three executed actions plus verifiable curves. Fewer than three is normal; none is a problem.
Ready: create price/scale scenarios with both parties' payoffs; do not sign unfilled cells.
For a token loan with an option, rising prices trigger exercise, effectively selling at the strike; low prices mean returned tokens plus your time and possible market-impact costs. The lawful, common structure is not the issue; calculation is.
Not ready: focus on no cash payment. No cash outflow does not mean no cost.
Ready: minimal overlap because KPIs differ.
Not ready: identical language indicates mass distribution without understanding counterparts. Chapter 29's advanced AI Lab tests this.
If a KPI is unclear, investigate product, public materials, and hiring. Do not send the letter until you can establish it.
Ready: regularly query callers and identify their products.
This produces actual integration results and excellent BD leads: unknown leading callers already use you, so discussions can begin beyond introductions.
Not ready: know only announced partners. The largest integrations are often unpublicized; the loudest announcement may contribute zero calls.
No standard answer; check:
- Which three roles need few contacts? Developers/integrators, foundations/grant providers, early chains/ecosystems.
- Have you improved documentation, examples, and interface stability, or left them to engineering?
- Have you applied Chapter 24's ten risks to your project? Wallet entry depends on these prerequisites.
- How often have you queried callers, and how many leads appeared?
- Can you state depth and slippage at three order sizes?
- How many current bottlenecks are inside your own team?
A contact-free first quarter may be most productive before meeting anyone: improve integration documentation, inspect permissions and safety, and discover existing callers. The last task is particularly underestimated.
Common Mistakes
Mistake one: announcements as output.
Reports measure partnerships with strategic-cooperation graphics.
Execution requires a specific completed action independently visible to others. Announcements have real secondary value, but poor evaluation value.
Use three output categories and four tests. Short-term reports become much shorter, perhaps two or three lines, while cross-functional cooperation increases because product and security own prerequisites.
Mistake two: sending everyone the same material.
A polished presentation goes to wallets, makers, foundations, and exchanges alike.
It assumes identical incentives, almost always incorrectly. Asset safety and revenue, risk-adjusted returns, or ecosystem usage give the same proposal different meanings.
Make the counterparty's third paragraph central and template the surrounding three. Rewrite the part about them every time.
Mistake three: assuming unreadable terms are safe.
“They are a major institution; terms must be standard,” or “No cash is required.”
Costs hide in options, liquidity commitments, ecosystem ties, and exclusivity outside the headline amount.
Write every cost explicitly. Do not sign uncalculable terms. The first four stages supply the tools BD needs, explaining its placement in stage five.
Mistake four: treating liquidity across venues as additive.
Another listing seems automatically beneficial, yet onchain depth falls afterward.
Liquidity is finite and allocated across venues. Supporting a new book diverts resources from passive pools that nobody replenishes, worsening execution despite more venues.
Ask where resources come from and evaluate subsequent depth and slippage rather than announcement-day price.
Next Steps
Complete two Labs: Chapter 29's network map and Chapter 23's data exercise. The latter fills each cell's verification method, the map's most valuable column.
Map your own project too. It identifies counterparts if new to BD and priorities if already practicing.
Complete the Capstone Project's research section. A independently verified number and source make the strongest proposal opening.
Compatible tracks:
| Combination | Why it fits |
|---|---|
| N3 · Crypto Growth & Operations | Integrations create lasting steps; both use Chapter 28's funnel |
| N1 · Crypto Research & Investment | Research supplies proposal evidence and realistic announcement discounts |
| N5 · Crypto Founder | Early founders perform BD, often with reachable roles requiring no token |
To improve access costs personally—documentation, examples, and interface stability—read T13 and T15, even without writing code yourself.
N3 · Crypto Growth & Operations
Replace successful-campaign claims with reproducible retention curves. Explain what your spending bought after incentives stop.
N5 · Crypto Founder
Resolve demand, mechanisms, business, safety, and treasury before deciding on tokens. Produce two documents others can challenge.