KOTVA

§0 Abstract

Kotva is Slavic for anchor. The key is the anchor: identity is a keypair its holder controls, and every name, address, alias, or operator sitting above it is a swappable pointer.

KOTVA itself is not a product — it is a family of protocols sharing one narrow waist, six capabilities small enough to read in an afternoon,^[3] plus a keystone document, the coordinator contract,^[2] that turns "some centralisation, done safely" into a checkable property instead of a marketing promise.

Above the waist sit thin profiles: DMTAP (mail, the flagship and reference profile), TRACT (commerce), WRAP (work), and a set of further drafts — media, social, real-time calling, search, reachability, cloud infrastructure. Below the waist, KOTVA adopts rather than reinvents: Ed25519, HPKE, deterministic CBOR, MLS, libp2p, SFrame, WebRTC, and a slate of external bindings for reputation, payments, storage, and dispute (Core-v1 recovery is self-contained — BIP39 + FROST/Shamir, no external vendor).^[5]

The one piece of genuinely new normative engineering is Sync — a signed, multi-author CRDT operation algebra with deterministic, coordinator-free convergence. Everything else is composition, and every unavoidable point of centralisation is fenced: accountable, swappable, self-hostable, and never load-bearing.

§1 The narrow waist

KOTVA "covers everything" the way IP or HTTP do — by being a thin waist that composes upward and downward, not by containing everything.

Federated-messaging history carries one loud lesson: monolithic protocols die of their own weight, and tiny cores win. XMPP and Matrix are technically complete and genuinely federated, yet both carry a large mandatory surface — presence, rosters, room-state resolution, a sprawl of extensions — that every server must implement to interoperate. HTTP took the opposite path: the core is almost nothing, and everything else is a profile layered on top. Nostr reduces a social network to "a signed JSON event, relayed by dumb relays"; AT Protocol reduces one to "a signed content-addressed repo with pluggable identity." Both win adoption by staying small enough that a new client, or a new application kind, need not swallow the whole thing.

KOTVA's waist is exactly six capabilities. A profile may adopt any subset — there is no ordering, no prerequisite bundle, no "core profile" a product must swallow first. But if a profile implements a capability's function, it must speak that capability's bytes: a product that syncs structured state uses the Sync op algebra, not a parallel CRDT it happens to call the same name. Two independently built profiles interoperate on any capability they both adopt — and that only holds if adopting a capability means adopting its wire format, not merely its idea.

§2 The substrate

2.1 Six capabilities, one shared floor

The substrate directory re-presents the waist as a standalone contract any non-mail product can adopt à la carte.^[3]

Five of the six capabilities profile existing sections of the core mail spec — they extract general machinery that happened to be written down as part of a mail protocol. Only one — Sync — is genuinely new normative ground.

The repository is candid about where implementation currently stands: roughly five independently hand-rolled sync/identity/feed implementations exist across the product suite today, none byte-interoperable with any other. The stated fix is not more prose but one compiled Rust core with thin per-language bindings (native, C-ABI/cgo, WASM, UniFFI) and frozen conformance vectors as the proof a binding is byte-identical to the core — a plan, not yet a finished fact. Two of those crates, kotva-core and kotva-mail, are tag-pinned dependencies today: consumers — the Envoir mesh node and the Pier broker, KOTVA's reference coordinator/gateway implementation — pin a git tag rather than tracking a moving path.

2.2 Sync — the one new normative capabilityonly new wire format in the family

Every other waist capability profiles something that already exists. Sync does not: no single deployed standard covers signed, deterministic, multi-author CRDT operations with snapshot and sparse namespace sync. Its semantics are grounded in the mail spec's existing single-owner device-cluster CRDT, generalised to any set of independent identities converging on shared state — by making the operation itself the unit of authenticity.

The SyncOp envelope

One envelope, six-plus CRDT types selected by a kind discriminator, each op individually COSE-signed (RFC 9052) or batched into a hash-chained, singly-signed SyncFrame for amortised signatures:

SyncOp = {
  1  => u8,          ; kind    CRDT/op discriminator
  2  => tstr,        ; ns      namespace ("" = default)
  3  => tstr,        ; target  object id
  ? 4 => tstr,       ; field   register / counter / edge selector
  ? 5 => ext-value,  ; value   LWW value · counter delta · RGA atom
  6  => Hlc,         ; hlc     { wall, counter, author }
  ? 7 => [+ AddTag],  ; observed OR-Set add-tags a remove cancels
  ? 8 => OpRef,       ; ref     RGA left-origin / tree parent
}

Authenticity, ordering, and abuse-resistance are treated as one problem rather than three add-ons: an op's HLC is rejected if its wall-clock is more than a bounded skew ahead of the receiver — deliberately one-sided, so a device offline for days can still push its legitimate backlog without a two-sided check discarding honest offline work. A counter's overflow spills forward into the next tick rather than wrapping, because a silent wrap would retroactively invert causal order for any op minted at the wrapped position. Reconciliation is a three-endpoint HTTP protocol — GET /sync/vector, POST /sync/pull, POST /sync/ops — the same shape proven by the flowstock reference implementation.

§3 The coordinator contract draft · normative once ratified

The keystone new specification of the family — a draft, normative once ratified — that turns "some centralisation, done safely" into a checkable property rather than a hope.

Decentralise the substrate and the exit. Every unavoidable coordinator is accountable, swappable, and self-hostable, and never load-bearing. Coordinators add reach; they never gate function.^[2]

A coordinator is any party that provides a function the peer-to-peer substrate cannot provide reciprocally: a global view (matching, ranking, search), a scarce resource (a reputable IP for legacy mail egress, a public ingress), a legal or real-world anchor (licensing, physical-event attestation), or cross-party judgement (moderation, arbitration). KOTVA does not pretend these jobs away — it fences each one behind one contract, generalised from DMTAP's legacy-mail gateway and legacy adapters into a reusable shape.

3.1 Four conformance clauses

3.2 The content-visibility property

Layered on top, an assurance level states how a blindness claim is guaranteed: structural (the role has no key at all — provable), attested (a TEE proves the code only forwards — hardware-trust), or declared (the operator promises — honest-trust, unverifiable). The contract can mandate the architecture and the declaration; it cannot cryptographically prove a declared-level operator isn't secretly logging. A client must never present a declared claim as if it were verified.

3.3 Authorise, never classify

Every gate a coordinator applies on a delivery path or an authoritative path must be answered from sender identity and rate — never from a judgement about whether content is wanted. A coordinator must not run spam scoring, ML filtering, or keyword/URL reputation on that path, and must not drop, quarantine, re-rank, or annotate on a content basis. "Wanted" is the recipient's judgement, on the recipient's device. This is structural rather than a style preference: content classification improves with corpus size, so it centralises and never finishes — which is exactly how anti-abuse would otherwise regrow a second centralised tier. A carve-out exists for a coordinator's own derived, opt-in, subscribable view — a labeler classifying into labels you subscribe to, or an indexer ranking its own corpus — because gating what reaches you by default is prohibited, but ranking your own opt-in view is not.

3.4 Coordinator kinds

The coordinator contract names eleven kinds — ten fully specified and one (infra-service) draft — as the single canonical, exhaustive list for the family.

Every kind above inherits the four clauses and the visibility property unchanged. The custodial-escrow operator is the one disclosed departure: it satisfies all four clauses like every other kind but, uniquely, does not fade once hired — holding money for strangers during a trade window is a real, licensed, structurally necessary role, bounded by staking sized to the float rather than eliminated by wishful design. The reference implementation of the gateway kind — Pier — carries the same fencing: a mail-adapter competitor can swap it out for its own gateway without asking KOTVA's permission, because the contract, not the implementation, is what conformance checks against.

§4 Bindings — adopt, don't reinvent

KOTVA specifies new bytes only where nothing proven exists, and binds everywhere else.^[5]

A binding is a thin mapping document — how substrate identity or objects map onto an external standard — never a re-derivation. When the frontier improves, the binding swaps; the substrate and profiles above it never change.

§5 The profiles

Six primitives recur across almost every real-world service: OFFER · MATCH · RESERVE · REPUTATION · ESCROW · ATTEST.^[6]

A wider service recipe — OFFER · MATCH/RESERVE · REPUTATION · ESCROW · ORACLE · DISPUTE · PAY — is a useful shorthand for describing a product, but only six of those names are primitives: ORACLE is the oracle coordinator kind (a physical-fact attestation, i.e. ORACLE ⊂ ATTEST), DISPUTE is the arbiter coordinator kind, and PAY is the stablecoin binding — composite roles built from primitives and coordinators, not a seventh and eighth primitive. Because the underlying services reduce to the same six primitives, "different products" are thin profiles standing on one substrate, not separate systems: Uber, delivery, freelance work, and auctions differ mainly in MATCH's assignment rule (nearest, best-fit, highest-bid); bookings drop MATCH entirely for a single-owner RESERVE.

§5.9 The key is the anchor

Every profile above shares one root fact: the keypair does not move. Everything that looks like an identity — a mail address, a domain, a key-name, a provider, a device — is a pointer someone can take away, and none of them are the anchor.

Recovery is adopted, not invented (§4): account abstraction, passkeys, and MPC shares heal a lost device without ever making a name, a domain, or a provider load-bearing over the key itself. A name can expire, a provider can shut down, a device can be lost or seized — the identity underneath, and everything signed under it, survives, because none of those things were ever anything more than a swappable pointer to the same IK.

§6 Honest ceilings & threat model

KOTVA covers every service's mechanism; it discloses, rather than hides, each service's trust and legal residual.

A research pass tested the substrate against roughly 35 real-world services across communication, money, the gig economy, discovery, infrastructure, civic function, media, and AI: about 29 reduce cleanly to the shared primitives (a handful with disclosed ceilings), about 3 are hard-blocked, about 2 are governance gaps, and one — a lightweight IoT profile — is simply unbuilt.

6.1 Four root ceilings

Two things are stated as genuinely unsolvable in principle, not merely unsolved: coercion-resistant public-election voting (harder than anti-Sybil) and surveillance-based advertising markets (rejected by design, not a gap to close).

6.2 The security floor (threat model)

A family-level threat model states nine invariants (SEC-1 through SEC-9)^[10] that every primitive, binding, coordinator, and profile inherits — fail-closed everywhere, intrinsic self-authenticity, end-to-end confidentiality via adopted crypto only, declared visibility with no silent downgrade, recoverable keys with no single load-bearing device, coordinators that authorise rather than classify, priced rather than centrally filtered abuse, inert replay, and metadata minimised-where-bought and disclosed-where-not. Each MUST ships with a numbered residual — the boundary it does not cross — on the stated house rule that a security section listing only strengths is marketing.

Every invariant above is required to survive with no coordinator and no connectivity at all — authenticity and confidentiality are intrinsic to the object and need no server; anti-abuse collapses to web-of-trust and local policy; replay-inertness and deterministic merge let a partitioned replica reconcile on reconnect with byte-identical convergence. The one disclosed exception is a custodial-escrow trade window, whose settlement is blocked offline by design, leaving only the trade objects themselves to reconcile once connectivity returns. A security property that only holds while a coordinator is reachable is treated as a conformance violation of this document, not a degraded mode.

§7 Status & governance

KOTVA is v0.1.0 — early and evolving.

The substrate, the DMTAP mail profile, and the TRACT (v0.1.0) and WRAP (v0.2.0) profiles are specified; the coordinator contract and the bindings index are the active consolidation work. Far-future cryptographic research stays quarantined to non-normative status rather than perfected on the critical path.

• Spec licence: Creative Commons Attribution 4.0 International (CC BY 4.0) — anyone may implement, quote, and build on it freely with attribution.
• Reference implementations (e.g. Envoir for DMTAP-mail, Pier as the reference gateway/broker, Soko for TRACT) are licensed separately under permissive open-source terms so any party — including competitors — may embed them.
• No protocol token exists, and none will be added. Money is an existing stablecoin; trust is staked existing value; free tiers and subsidies are operator policy, never a protocol requirement.
• Copyright © 2026 VulOS (github.com/vul-os).

§8 References

This whitepaper is a rendering of the specification tree in the kotva repository, not an independent source. Every numbered claim above cites one of the documents below; where this document and a cited source appear to differ, the source governs.

1. [1]README.md — the repository's front door: layout, design-in-one-breath, and status.
2. [2]DIRECTION.md and coordinator/CONTRACT.md — the one rule, the four conformance clauses, the content-visibility property, authorise-never-classify, the eleven coordinator kinds, and the economics boundary.
3. [3]substrate/README.md, substrate/IDENTITY.md, substrate/ROLES.md, substrate/FEEDS.md, substrate/SYNC.md — the six waist capabilities, re-presented as a standalone, à-la-carte contract.
4. [4]00-overview.md through 27-realtime-media.md (repository root) — DMTAP, the mail, messaging, and legacy-gateway reference profile.
5. [5]bindings/README.md — the adoption index: identity recovery, attestation, reputation, personhood, payments, storage, dispute, media transport, and TEE-verified coordination.
6. [6]primitives/OFFER.md, MATCH.md, RESERVE.md, REPUTATION.md, ESCROW.md, ATTEST.md — the six primitives every service composes from.
7. [7]profiles/tract/ — TRACT, the commerce profile (offer, cart, order, settlement, dispute).
8. [8]profiles/wrap/ — WRAP, the work profile (jobs, dispatch, delivery, milestone escrow).
9. [9]profiles/media.md, social.md, rtc.md, reachability.md, search.md, cloud.md — the MEDIA, SOCIAL, RTC, REACH, SEARCH, and DEPOT profile drafts.
10. [10]THREAT-MODEL.md — the family threat model: SEC-1 through SEC-9 and the numbered residuals (R-1 … R-9).
11. [11]docs/research/ (mixnet.md, vdf.md, PRIMITIVES.md) — far-future cryptography, deliberately quarantined as non-normative.
12. [12]GOVERNANCE.md, LICENSE.md, VERSION, Cargo.toml / crates/kotva-mail/Cargo.toml — status, licensing, versioning, and the reference crates behind Pier and the Envoir mesh node.