Platform for universal programmable equity management
Role: lead developer and technical/UI decision maker
Concept and legal research: Wouter, co-founder
Stack: Svelte 5, SvelteKit, Node/Fastify, MySQL, Hedera Hashgraph, Turborepo monorepo
The problem
Letting employees, freelancers and early contributors share in a company's success is a good idea
that almost nobody executes well. Participation plans, stock appreciation rights, option pools and
STAK structures are slow to set up, expensive to change, and mediated by lawyers at every step.
The legal documents live in one place, the cap table lives in a spreadsheet, and the actual work
that earned the equity lives in someone's memory. None of the three agree with each other.
Kwantor set out to close that gap. The contract should not describe the arrangement. It should be
the arrangement: signed once, and from then on executed by software.
What we built
Kwantor is a platform where a company adopts a participation plan, invites contributors, and
rewards their work with tokens that represent a share in future profits or an option on equity. A
contributor's journey looks like this:
1. They are invited into the company's workspace and sign the participation deed digitally.
2. They sign an assignment agreement that defines their rate, milestones and vesting terms.
3. They log hours or report milestones. An admin approves them.
4. Approval creates a payout in cash or in tokens. Tokens land in a vesting wallet and release on
schedule.
5. At every step, the legal document, the workspace permissions and the token ledger agree,
because they were all produced from the same source.
The product grew into a family of applications: the contributor workspace (Teller), a partner
control panel for law firms and accelerators who run their own white-labelled instances, an
account and billing portal, a super-admin console, a public site and a standalone contract
creator. All of it lives in one monorepo with shared packages for authentication, contracts, the
design system, PDF generation and UI.
Wouter drove the concept and the legal research: which structures hold up under Dutch law, how
vesting should be expressed, what the documents must say. I built the platform and made the
technical and interface decisions along the way.
Four ideas that shaped the architecture
1. Contracts as versioned, executable configuration
The core design decision was to treat legal documents as structured data rather than as Word
files. Each contract is stored as a lossless hierarchical JSON tree: headings, clauses,
definitions, declaratory text and signature blocks, each with a stable identifier. Clause bodies
carry a small template language for variables, defined terms, cross-document chapter references,
conditions and loops.
Authors edit these documents in a custom rich-text editor built on TipTap. The hard requirement
was that a round trip from stored JSON into the editor and back must be the identity. That sounds
obvious and is not: nested conditions, loops over remuneration rows, definition entries that
collapse in the editor but must expand on save, and inline formatting that must never corrupt a
template token. A dedicated test suite locks these invariants, and a large share of the editor
work was making them hold.
Versions behave like a small git. Documents auto-save as drafts, authors commit snapshots, any
commit can be promoted to production, and a Word-style track-changes view diffs the working draft
against any earlier commit. The same pure-function rendering pipeline produces the editor preview,
the signing PDF and the archived document, so what an author sees is what gets signed.
2. A questionnaire and a rule list, published together
A template alone is not enough. Each contract type has a config version with two halves: a
decision tree that drives a step-by-step questionnaire in the workspace, and a list of mutation
rules that run when all parties have signed. Rules are composed from a small set of code-defined
kinds: grant a permission, create an assignment, attach milestones, schedule vesting, allocate
tokens, send a notification.
A partner edits both halves in a no-code builder, publishes, and the next contract created uses
the new rules. Config versions are immutable once published, and every contract snapshots the
version it was created under. A rule edit can never change the terms under a contract that is
halfway through signing.
Signing itself goes through SignHost, with simple, advanced and qualified electronic signatures,
or an external path where a scanned paper signature is uploaded. Whichever path is taken,
completion triggers the same mutation executor.
3. Multi-tenancy through realms
Kwantor was designed so that partners could run it as their own product. Every organisation
belongs to a realm. A realm owns its templates, its config versions, its enabled modules, its
theme with self-hosted fonts, a credits ledger for signatures, and a navigation editor that lets
the partner rename, reorder, disable and add pages to the workspace, including custom HTML and
lifecycle hooks. New realms are seeded from a live copy of the reference setup, so a partner
starts with working documents and adjusts from there.
Late in the project this expanded into a read-only data API with a declarative resource manifest,
per-actor OpenAPI documentation and a browser SDK, so that realm developers could build on top of
the workspace without touching the core.
4. Settlement on a ledger
Tokens are real tokens on Hedera Hashgraph. Each organisation gets a treasury account that holds
the token keys and a reserve account holding pre-minted supply. Each contributor gets a vested
wallet and an unvested wallet. Vesting is not a database flag. Tokens sit in the unvested wallet,
and scheduled jobs move them across as tranches release. KYC is granted per account, transfers are
built as deferred operations and tracked through a pending, approved, executing, completed state
machine, and balances are topped up automatically so contributors never need to hold the network's
native currency.
The layered client model, platform operator, organisation treasury and individual contributor,
meant that every transfer runs under the correct authority and the platform never holds a
customer's keys in a position to move their tokens on its own.
Things that were hard
Editor round-tripping under nested structure. The first loop-pairing algorithm was greedy and
consumed closing tags asymmetrically. Nested loops survived one save and scrambled on the next.
The fix was a balanced stack matcher that only pairs a closer with a same-kind opener, and leaves
anything unbalanced verbatim so the author can see and repair it rather than losing work.
Making the contract snapshot authoritative. Early on, re-rendering a contract rebuilt its context
from live organisation data, so a PDF regenerated months later could drift. Freezing the full
render context at creation made regeneration reproducible and closed a category of subtle bugs.
Money bugs. A payout function was called on both submission and approval of a time entry. With
vesting enabled it created duplicate jobs and transfers. Finding and fixing that, and then adding
transaction-isolated tests that seed the database directly, was a lesson in how much ledger code
wants to be boring.
Keeping the design system honest. With eight apps and a small team, the only way to keep the
interface consistent was a strict shared component library, plain CSS with design tokens, no
TypeScript and no utility frameworks. Every app looks like the same product because it literally
reuses the same parts, including partner-themed instances.
Where it was heading
The last phase I worked on generalised the model. Rather than a fixed set of contract types, the
goal was an instrument engine: an append-only ledger of events, financial facts derived as views
over it, and the blockchain treated as asserted settlement rather than the primary record.
Alongside that, an agentic onboarding flow that reads a company's existing documents and proposes
a participation structure, so that adopting Kwantor starts from what the company already has
rather than from a blank form.
What I took from it
Kwantor is the most demanding system I have built. It required holding legal, financial and
cryptographic constraints in one head while shipping a product that non-technical founders could
use. The decisions I am most satisfied with are the structural ones: documents as data,
configuration as immutable versions, and settlement as something the system enforces rather than
records. The team continues development today.
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 │
└──────────────┘