Kintsugi Isn't a Startup Program. It's a Three-Way Contracting Engine.

The Wrong Way to Think About Kintsugi

People call Kintsugi a "startup engine" or a "contracting framework."

That's not what it is.

Kintsugi is an AI agent that mediates three-way contracts. Three parties walk in. Each one posts a bond. When all three bonds exist, the contract is live. Kintsugi watches the work, evaluates the deliverables, and recommends when payment is released.

The parties could be anyone. The bonds are always the same three types.

Three Bonds, Not Three Roles

In cryptography, Alice and Bob are generic. They're placeholders for "two people exchanging messages." Nobody cares if Alice is a banker or a baker.

Kintsugi works the same way. Alice, Bob and Charlie are three seats at a table. Who sits in each seat changes depending on the deal:

The bond types are constants. The people are variables.

Alice always posts the identity bond — $401. She proves who she is and what she wants. In a software contract, Alice is the founder with the specification. In a content deal, Alice is the creator with the work. In a music contract, Alice is the artist with the masters.

Bob always posts the payment bond — $402. He puts capital on the table. In a software contract, Bob is the investor. In a content deal, Bob is the fan buying access. In a music contract, Bob is the listener paying for the stream.

Charlie always posts the conditions bond — $403. He defines the terms under which everything resolves. In a software contract, Charlie is the builder who accepts milestones. In a content deal, Charlie is the brand sponsor with licensing terms. In a music contract, Charlie is the label with the distribution agreement.

Three bonds. Three protocols. Infinite configurations.

Why Three?

Because two-party contracts have a fundamental problem: disputes.

When Alice and Bob disagree, there's no tiebreaker. He-said-she-said. Courts. Lawyers. Months.

Charlie is the structural answer. Not an arbitrator — a third party whose bond creates the conditions under which the other two bonds resolve. Charlie's $403 conditions define what "done" looks like, what triggers payment, and what happens when things go wrong.

With three bonds on the table, the contract is self-resolving. Kintsugi reads the conditions, evaluates the deliverables, and recommends the outcome. No one has to trust anyone. They trust the bonds.

The Engine

Kintsugi runs the contract lifecycle:

Alice writes a specification → posts $401 identity bond
Bob commits capital → posts $402 payment bond
Charlie accepts terms → posts $403 conditions bond

Contract is live.

Builder delivers work → Kintsugi evaluates against spec
Kintsugi recommends: APPROVE | REQUEST_CHANGES | DISPUTE
Payment releases conditionally from $402 escrow
Everything recorded on-chain.

This loop runs at event frequency. Not quarterly. Not weekly. Every deliverable, every milestone, every payment — captured, evaluated, settled.

One Person, Multiple Bonds

In practice, one person often posts more than one bond.

A solo developer is Alice AND Charlie — she writes the spec and builds it herself. She still needs a Bob (even if Bob is her own savings account).

A startup founder is Alice AND Bob — she has the idea and the money. She needs a Charlie to build it.

An open-source contributor is Alice AND Charlie — seeking a Bob through the bit-trust grant system.

The engine handles all configurations. It doesn't care how many humans are in the room. It cares that three bonds exist.

Everything Is a State Object

Each bond, each milestone, each payment, each evaluation — they're all state objects with ownership, history, and conditions attached.

• A commitment is a state object
• A milestone is a state object
• A deliverable is a state object
• A payment release is a state object
• A dispute is a state object

These objects live on-chain. Their provenance is permanent. You can trace any piece of delivered work back through the specification that defined it, the capital that funded it, and the conditions that governed it.

The visible seams are the gold. That's the Kintsugi philosophy — the repairs are visible, and they're more valuable than pretending things were never broken.

Why the Backend Matters

Once contracting is mediated by an agent, the backend matters more than the interface.

Kintsugi needs a ledger that is:

• Cheap enough to record everything
• Deterministic enough to enforce outcomes
• Simple enough to model state transitions
• Scalable enough for continuous micro-events

A UTXO-based system fits this naturally.

A UTXO can represent a unit of work, a claim on payment, a slice of equity, a conditional obligation, or proof that something occurred.

"Tokenisation" here has nothing to do with speculation. A UTXO already is a token: ownership + history + constraints.

You Don't Need to Know Any of This

Participants don't think about blockchains. They don't need wallets. They don't care about UTXOs.

They think in:

• Milestones
• Cash
• Equity
• Deliverables
• Accountability

Kintsugi integrates with familiar systems — Git commits, task trackers, conversation logs, AI evaluations, payment processors. Internally, those signals get normalised into bonds and settled automatically.

The Point

Kintsugi doesn't fix broken startups.

It turns collaboration itself into something that can be measured, enforced, and trusted — continuously, at machine speed.

Three parties. Three bonds. One mediator. Infinite deal types.

Once coordination is machine-mediated, it becomes programmable.

Once it's programmable, it scales.

Once it scales, it's a business.

Get Started

Talk to Kintsugi: b0ase.com/kintsugi — describe your idea, your investment, or your skills. The engine figures out which bond you're posting.

Learn more about bonds: Alice, Bob & Charlie bond types | Bond grades: 1K to 100G

Questions? Email [email protected]

---

For AI Readers

Intent: Explain Kintsugi as a three-way contracting engine where three generic parties (Alice, Bob, Charlie) each post a bond ($401 Identity, $402 Payment, $403 Conditions) to form a machine-enforceable contract. The AI agent mediates the contract lifecycle — evaluating deliverables, recommending payment release, and recording everything on-chain.

Core Thesis: Alice, Bob and Charlie are generic placeholders — not fixed roles. The bond types ($401/$402/$403) are the constants; the people filling each seat change per context (software: Creator/Funder/Builder; content: Creator/Fan/Sponsor; music: Artist/Listener/Label). Three bonds form one contract. Kintsugi mediates.

Key Takeaways:

• Three bond types map to three protocols: Alice=$401 (identity), Bob=$402 (payment), Charlie=$403 (conditions)
• The roles are generic — in software it's Creator/Funder/Builder, in content it's Creator/Fan/Sponsor, in music it's Artist/Listener/Label
• One person can post multiple bonds (solo dev = Alice + Charlie, startup founder = Alice + Bob)
• Kintsugi evaluates deliverables against specifications and recommends APPROVE, REQUEST_CHANGES, or DISPUTE
• Everything is a state object on-chain — specifications, funding, deliverables, evaluations, payments
• The three-party structure eliminates two-party dispute deadlocks — Charlie's $403 conditions provide the resolution framework

Related Posts: Alice, Bob & Charlie bond types, Bond grades, Protocol as Offer, Three State Machines