Case study

How Aventus runs diligence when the decision belongs to a DAO

Aventus funds enterprise blockchain deployments rather than billing for them, and vets the teams building on its network. Both are investment decisions, and both have to hold up in front of people who were never in the room.

31 August 2026 · 6 min read

Most diligence ends in a room. Four people who have worked together for years read a file, ask each other the questions that are not written down anywhere, and decide. The paper trail matters, but it records a decision rather than carrying it — because the decision was carried by the conversation.

Aventus does not have that room.

It describes itself as "a non-profit DAO building enterprise blockchain infrastructure since 2017". It runs a decentralised compute network of roughly forty thousand nodes and builds enterprise appchains on Substrate, with production deployments in energy, retail, aviation and prediction markets. Vodafone and Heathrow are among the names on it.

What makes it an unusual diligence problem is how those deployments get paid for: mostly, they do not. Standing up an appchain for a large enterprise costs Aventus its own engineering and its own treasury, spent against a network worth more with that enterprise running on it. That makes each deployment an investment decision wearing a commercial deployment's clothes. The same holds in the other direction — teams building on Aventus are assessed on quality before the network commits anything to them.

Two pipelines. Both end in a decision a DAO has to be able to defend.

The room is the thing a DAO does not have

A private fund's investment committee is four people with twenty years of shared context. When the file is thin, somebody says "I know these people" and that sentence does real work. It is not rigour, but it is information, and it is available in the room.

A DAO's decision reaches people who were never in the room and cannot ask a follow-up question. Whatever is written down is the case. Not a summary of the case — the case itself.

That inverts the usual economics of diligence hygiene. At a fund, a tidy paper trail is insurance: effort spent now against a problem that may never arrive. At Aventus it is the deliverable. A condition that was checked but not recorded has, for governance purposes, not been checked.

Six systems, none of them wrong

Before, the work was spread across the tools you would expect a competent team to use, each of them the right tool for its own job:

  • Asana held the tasks.
  • Telegram and email held the conversation, including most of the actual commitments.
  • Shared decks and Google Drive held the documents.
  • Independent research — the checks somebody went and did — lived wherever the person doing it kept things.
  • Notes, personal and various, held everything that had not found a home in the other five.

Nothing on that list is a mistake. The problem is what is missing from it: the list of things that must be true before Aventus commits was not in any of them. It was implied by the union of all six, and turning that union back into a list was a human act performed from memory, usually under time pressure, at the point where it was most expensive to get wrong.

Three costs follow from that, none of which appear anywhere as a line item.

The list drifted from the evidence. A document lands in Drive, the expectation that it was needed lives in Asana or in somebody's head, and the two are reconciled by a person remembering to. Within a fortnight the list is not so much wrong as untrustworthy — nobody can say which parts of it are current without checking all of them.

Nobody could say whose move it was. The most common state on any diligence file is not "late", it is "unclear". An item nobody has actually asked for looks exactly like an item somebody is sitting on, which looks exactly like an item that arrived last week and has not been read.

The evidence did not survive the decision. By the time a deployment reached governance, the reasons for accepting each condition were distributed across the people who had accepted them, and across a Telegram thread. Assembling that into something a token holder could read was a separate piece of work, done last, by whoever was free.

What changed

The whole feature set was available from the start, and the parts that mattered were the unglamorous ones.

One list per deployment, with a state per item. Not a document describing what is needed, but the needed things themselves, each in exactly one state, each carrying whichever document, answer or check satisfies it.

Whose move it is, said out loud. Every condition reads as with the counterparty, with us, or not asked yet — and the third is the one that changes behaviour, because an item nobody has requested is nobody's fault yet and is indistinguishable from a late one until somebody names it.

Acceptance with a name on it. Nothing reaches accepted without a person doing it, and the record carries who, when, and against which evidence. In a DAO this is the load-bearing part: it turns "we checked" into something with an author.

Waivers that read as waivers. A condition the network decided to proceed without stays visible as exactly that, with a reason and a name, never absorbed into the complete pile. "Who decided we could skip this" is the first question asked after anything goes wrong, and the file answers it.

A pack assembled from the record. The state of the file, what was accepted and by whom, what was waived and why — built from what happened rather than written up afterwards from memory.

What it did to the decision point

The change Aventus noticed was not in the chasing. It was at the decision point: the turnaround between a deployment being substantially done and being ready to put in front of governance got materially shorter, because the pack stopped being a thing somebody had to go and write.

There is no before-and-after figure on this page, and the reason is worth stating plainly. Nobody instrumented the old process — which is the ordinary situation at almost every organisation, not a failing peculiar to this one. Reconstructing a baseline afterwards from Telegram threads and Drive timestamps would have produced a number that looked precise and was not, and an invented benchmark is the fastest way to lose a room of people who do this for a living.

What did not improve

Counterparties are still slow.

Nothing here makes an enterprise legal team reply faster, and no part of the product claims to. What moved was the half of the delay that happens inside your own building — the document that arrived and sat unread, the condition nobody had actually requested, the pack that had to be reassembled by hand. The external half behaved exactly as it always had.

That distinction is worth being clear about before anybody buys anything. If the entire problem is that a counterparty will not answer, this changes less than you would like. If some meaningful part of it is that nobody can currently say what is outstanding and whose move it is, that part is addressable.

Would this work for you

The test is not what kind of organisation you are. It is whether these are true:

  • Money, or engineering, leaves on the strength of conditions somebody checked.
  • The people who ratify that decision were not present when it was made.
  • The list of conditions is implied by several systems rather than living in one.
  • You could not currently say, for a given item, whether it has been asked for.

If the last two are true, the reconciliation work already exists at your organisation. It is simply being done from memory, at the end, by whoever is free — which is the most expensive moment and the worst possible person.