Somewhere right now, five people at an asset manager are discussing a DeFi protocol whose builders will never hear the verdict. The risk lead read the docs. Compliance found a blog post from last year. Legal skimmed an audit of a version that is no longer deployed, the portfolio manager remembers a founder's thread, and finance pulled numbers off a dashboard. Twenty minutes in, they realize they do not agree on what the protocol actually is, so the item gets parked and nobody sends the team a reason. That quiet failure sits at the center of a recent interview with the TechWaves PR founder on why institutional DeFi has a communication problem on DefiLlama Research, where Sofia Bobrik argues that institutional deals rarely stall because nobody understood the product. They stall because several people understood it differently. If you write code for a protocol that wants institutional capital, that is an engineering problem wearing a business suit, and you already know its name.
Even Lamport Needed a Story
The name is consensus failure, and computer scientists have been studying it for more than forty years. In 1982, Leslie Lamport, Robert Shostak and Marshall Pease described a group of generals surrounding a city who must agree on a single plan while communicating only through messengers, knowing that some of their own may be traitors. The headline result is famous: with ordinary messages, agreement is possible only if more than two-thirds of the generals are loyal, a threshold that still echoes in the supermajority Ethereum validators need to finalize a checkpoint.
The backstory is less famous and more useful. In Lamport's notes on the Byzantine Generals Problem, he explains that the story was a deliberate choice. He had watched Dijkstra's dining philosophers collect far more attention than he felt it merited, simply because it was framed as a story, so he dressed his own result in one. He even changed the title after a colleague objected that the original version cast the generals as Albanian. One of the foundational results of distributed computing spread because its author treated packaging as part of the work. Correct ideas do not distribute themselves, not even Lamport's.
A Buying Committee Is a Network Without a Consensus Protocol
Now map the paper onto an institutional deal. Every stakeholder is a node. Your docs, website, deck, audit reports, dashboard listings and the founder's public posts are the messages. Each node processes whichever messages happened to reach it, forms a view, and then the group tries to agree. Gartner's survey on why B2B buying teams struggle to reach consensus found that buying groups now span five to 16 people across as many as four functions, and that 74% of them show unhealthy conflict during the decision. Groups that did reach consensus were two and a half times as likely to describe the resulting deal as high quality.
Those figures cover B2B purchasing in general, where buyers usually know which category they are shopping in. DeFi starts from a harder position. As the interview notes, a finance team often cannot tell whether it is looking at an infrastructure layer or a trading venue, a settlement rail or a liquidity protocol, a yield strategy or a tokenized asset platform. When each node returns a different answer to that question, there is no quorum. Nobody votes no. The proposal simply times out, and a timeout sends no error message back to the caller.
You Might Be the Byzantine General
Here is the uncomfortable part. In Lamport's model, one of the most damaging faults is a commander who sends different orders to different lieutenants, which leaves perfectly honest lieutenants unable to agree. Plenty of protocol teams play that role without meaning to. The deck says institutional lending infrastructure. The docs say permissionless money market. A podcast clip mentions a 24-hour timelock while the contract enforces 48. The audit everyone forwards covers v2, and v3 has been live for months. Each message was true when someone wrote it. Together they are conflicting orders.
Sales instinct then makes things worse. The obvious move is to tailor the story for each reader: yield for the portfolio manager, controls for compliance, architecture for the CTO. Gartner's data points the other way. Content tuned to individual stakeholders had a 59% negative impact on buying-group consensus, which the firm attributes to confirmation bias, while content built around the group's shared goals improved consensus by 20%. In protocol terms, you were sending every node a different value and hoping they would converge. The interview proposes a better target metric, "consistency of interpretation": every reader ends up with the same model of what you are, even when they arrived through different documents.
Visibility Is Just a Star Count
The same interview calls visibility a vanity metric in deep tech, and developers already own the perfect analogy. Stars tell you how many people noticed a repository. They say nothing about how many understood it well enough to run it in production or describe it accurately to a colleague. A viral thread about your protocol is a star count. What moves an institutional allocation is how many people inside one organization can restate what you do, correctly and in compatible terms, while you are not in the room.
Run a Differential Reading Test
Compiler engineers rely on a technique called differential testing: run the same input through several implementations and treat any disagreement in their output as a bug. Your public materials can be tested the same way. Hand your docs, site and deck to three or four people who think like the committee, such as a risk analyst, a lawyer, a finance generalist and an engineer from outside crypto. Ask each of them to answer the same questions in writing and in their own words, then diff the answers. These are the questions every committee ends up asking, and they closely track the risk questions raised in the interview:
- What is it? One sentence, using a category the reader's firm already has a box for.
- Who can change the rules, and how fast? Admin roles, multisig thresholds, timelock delays and upgrade paths.
- What happens on the worst day? Liquidations, oracle failures, withdrawal queues and the exact conditions for pausing.
- What lives off-chain? Keepers, oracle operators, custodians, KYC providers, legal wrappers and anything else a contract cannot guarantee.
- What is still unsolved? The honest limits of your protocol and of the category as a whole.
For a cheap first pass, prompt an LLM to play each role with nothing but your public materials as context and compare the summaries. It will never replace a real compliance officer, but it is good at finding the paragraph that can be read two ways. Pay the most attention to divergence on the last question, because that is where risk communication either holds a group together or splits it.
Hidden Risk Is a Fork Waiting to Happen
Teams often downplay risk to look stronger. In consensus terms, that is exactly backwards. Institutional reviewers already know DeFi carries contract, oracle, liquidity, governance, custody and regulatory risk, and the interview is blunt that pretending otherwise costs a founder credibility on the spot. If you do not describe your risks, someone on the committee will discover one alone, and at that moment one node holds information the others lack. That is a fork, and forks are expensive to reconcile. Publishing your risks in one canonical place gives every reviewer the same starting state, and it signals the kind of literacy institutions look for: the assumptions you make, what you have done to mitigate them, and what remains open.
Make Narrative Drift Fail the Build
Most conflicting orders are not lies. They are stale replicas. Phil Karlton's old joke holds that the two hard things in computer science are cache invalidation and naming things, and institutional communication breaks on precisely those two: naming, when nobody can agree which category you belong in, and cache invalidation, when last year's deck keeps circulating long after the protocol changed. Treat the facts reviewers check the way you already treat config. Keep timelock delays, signer thresholds, oracle sources and caps in one versioned file, render your docs from it, and let CI compare it against the chain. If governance runs through OpenZeppelin's TimelockController, the check takes a few lines of viem:
import { readFileSync } from "node:fs";
import { createPublicClient, http, parseAbi } from "viem";
import { mainnet } from "viem/chains";
// docs/facts.json is the single source of truth the docs are rendered from
const facts = JSON.parse(readFileSync("docs/facts.json", "utf8"));
const client = createPublicClient({ chain: mainnet, transport: http(process.env.RPC_URL) });
const onchainDelay = await client.readContract({
address: facts.timelock.address,
abi: parseAbi(["function getMinDelay() view returns (uint256)"]),
functionName: "getMinDelay",
});
if (onchainDelay !== BigInt(facts.timelock.minDelaySeconds)) {
console.error(`Narrative drift: docs say ${facts.timelock.minDelaySeconds}s, chain says ${onchainDelay}s`);
process.exit(1);
}
The same pattern covers a Safe's getThreshold(), oracle feed addresses and supply caps. Then deal with the cache: share decks as links to one hosted copy instead of attachments, so a forwarded link always resolves to the current version, and stamp every public document with the date its facts were last verified.
Instrument the Silence
A deal that dies in committee leaves no stack trace, so add your own instrumentation. Open every first institutional call with one question: before we begin, how would you describe what we do to your risk team? The answer is a free readout of the state your materials left behind. Write it down. When answers from unrelated firms start to converge, your messages are consistent, and the interview describes the payoff in practical terms: the first serious conversation stops being a tutorial on the basics and starts from an informed position. Engineers would call that a warm cache.
Ship Agreement, Not Just Code
Your protocol already solves a harder agreement problem than any committee will ever face, with adversarial validators and real money at stake. The off-chain version deserves the same rigor: one source of truth, identical messages to every node, honest disclosure of known faults, and tests that catch divergence before a reviewer does. Lamport understood that a correct result still needs a vehicle that carries it intact from one mind to the next. For a DeFi protocol, that vehicle is everything you publish. Every inconsistency in it is a bug, and unlike a bug in your contracts, you can patch this one without a governance vote.
Top comments (0)