Kwantor · from participation agreements to funding rounds
lead developer, technical and UI decisions @ Kwantor Landing page
I led development of Kwantor’s participation platform from 2022. Now it runs funding rounds, and my part is the money: held until a round is funded, then released or refunded.
Kwantor began with Wouter’s experience on the legal side of employee participation. Agreements, spreadsheets and records of work could drift apart whenever an arrangement changed. His concept was to connect them through one system. He handled the concept and legal research; I built the platform from 2022, it grew out from me doing all of the development into Wouter and me writing the code together.
The first product was for contributors. A contributor received an invitation, completed a questionnaire and signed the agreements. They could then record hours or milestones for approval, with payment in cash or tokens under the arrangement. I was responsible for the technical and interface decisions that joined those steps together.
In 2026 Kwantor changed direction to one main thing: a European company raising up to €12M from investors it found itself, with the onboarding, the KYC, the payments and the register in one place.
Elaborate legal structure setup with matching interface
For the participation platform I built a document editor for clauses, definitions, variables and references. These rendered the legal documents with templates. Changes to the templates are versioned, with a review process familiar to the lawyers using it.
Each agreement keeps the template and rule versions it was created with. Editing the system’s rules only affect future documents and not affect an agreement already in the signing process.
PARTNER CONTROL PANEL (per realm)
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Template version v2.3.0 │ │ Config version #7 │
│ ────────────────────────── │ │ ────────────────────────── │
│ documents as JSON trees │ │ decision tree (questions) │
│ {{vars}} {{def:}} {{link:}} │ │ mutation rules (on signing) │
│ {% if %} {% for %} │ │ │
│ commits ─► production │ │ draft ─► published │
└──────────────┬───────────────┘ └──────────────┬───────────────┘
│ pinned │ snapshotted
└───────────────┬────────────────────┘
▼
┌───────────────────┐
│ CONTRACT #4812 │ template v2.3.0
│ assignment │ config #7
└─────────┬─────────┘ (frozen at creation)
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 1. QUESTIONNAIRE│ │ 2. RENDER │ │ 3. SIGN │
│ decision tree │ │ same pipeline │ │ SignHost │
│ ─► form values │ │ preview = PDF │ │ SES / AES / QES │
│ │ │ │ │ or external │
└─────────────────┘ └─────────────────┘ └────────┬────────┘
│ all parties signed
▼
┌─────────────────────┐
│ 4. MUTATION EXECUTOR│
│ runs rules of #7 │
└──────────┬──────────┘
┌────────────────┬───────────────┼───────────────┐
▼ ▼ ▼ ▼
┌────────────┐ ┌──────────────┐ ┌─────────────┐ ┌────────────┐
│ permission │ │ create │ │ vesting │ │ allocate │
│ grant │ │ assignment │ │ schedule │ │ tokens │
└─────┬──────┘ └──────┬───────┘ └────┬────────┘ └─────┬──────┘
│ │ │ │
═════════════════╪════════════════╪══════════════╪════════════════╪════════
WORKSPACE ▼ ▼ │ │
┌──────────────────────────────┐ │ │
│ contributor sees the org, │ │ │
│ logs hours, reports │ │ │
│ milestones ─► admin approves │ │ │
└──────────────┬───────────────┘ │ │
│ payout │ │
══════════════════════════╪══════════════════════╪════════════════╪════════
HEDERA LEDGER ▼ ▼ ▼
┌────────────┐ ┌──────────────┐ ┌──────────────┐
│ treasury │─────►│ reserve │───────►│ unvested │
│ token keys │ mint │ pre-minted │ alloc │ wallet │
└────────────┘ └──────────────┘ └──────┬───────┘
scheduled │
tranche │
▼
┌──────────────┐
│ vested │
│ wallet │
└──────────────┘Self-service (crowd)funding
The structure behind a round is Dutch and fairly specific. The founders set up an SPV, a separate bv that takes a stake in the operating company, usually at least 5%. The SPV issues a winstbewijs, a right to a share of the profit, as a token on Hedera, and that is what investors buy. The founders keep the votes and the investors get the economics, so a later investor or a buyer deals with one shareholder instead of every investor in the round.
One element shapes the product the most: the round relies on exemptions from the prospectus rules, and those only hold while the company markets and places its own offer. So nobody can find a round on Kwantor: no listing, no search, no matching investors to companies. An investor arrives because the company sent them, already decided. Every feature idea gets the same test, could an investor reach this offering without the company having told them about it? If yes, it does not get built.
A Dutch SPV can raise at most €12M this way, so the platform counts what has actually been paid in, across every round the SPV ever runs, and refuses a subscription that would go over. There is no reset, which is why the company’s dashboard shows how much room is left.
For the investor it is short. An invitation from the company, an account, their details for the KYC, a signature, and a payment through Mollie. The tokens land in their wallet, and the cap table both sides look at is computed from the register every time it is read, never stored, so it has nothing to fall out of step with.
Money is held until round is completed
A round can have a minimum. Below it the company does not want the money and the investors should not lose theirs, so nothing may reach the company until enough has come in. Once a round has reached its minimum the company can no longer withdraw it. Below the minimum a withdrawal fails the round and refunds everyone. Above it the money has gone out and the tokens have been delivered, so there is nothing left for a withdrawal to give back. It can still close early and keep what it raised.
INVESTOR pays through Mollie
│
▼
┌───────────────────────────────────┐
│ does the round have a minimum, a │
│ soft maximum or a commission? │
└────────┬─────────────────┬────────┘
yes │ │ no
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ HELD │ │ paid straight into │
│ on Kwantor's Mollie │ │ the client's own │
│ balance, no route │ │ Mollie account │
└──────────┬───────────┘ └──────────┬───────────┘
│ outcome job, │
│ every 15 minutes │
┌──────────┴──────────┐ │
paid ≥ minimum closed below minimum │
▼ ▼ │
┌─────────────────┐ ┌─────────────────┐ │
│ FUNDED │ │ FAILED │ │
│ route created │ │ whole payment │ │
│ now: payment │ │ refunded from │ │
│ less commission │ │ Kwantor's │ │
│ to the client │ │ balance │ │
└────────┬────────┘ └─────────────────┘ │
│ │
└──────────────────┬─────────────────┘
▼
┌───────────────────────────┐
│ CONFIRMED │
│ webhook answers Mollie, │
│ then delivery starts; │
│ the cron is the guarantee │
└─────────────┬─────────────┘
▼
┌───────────────────────────┐
│ HEDERA │
│ tokens move from the │
│ treasury to the investor, │
│ once their KYC is granted │
└───────────────────────────┘Payment routing flow
Kopula
Next to it, in Kwantor, Wouter started Kopula, for a problem of our own: at networking events we kept missing the people we came for. Guests are scanned in by their LinkedIn QR code, and afterwards everyone has the list. Read about it here.