KOTVA

§0 Abstract

kotva is Slavic for anchor. The key is the anchor: identity is a keypair its owner holds, and every name, address, alias, or operator that sits above it is a swappable pointer. KOTVA is not a product. It is a family of protocols sharing one narrow waist — six capabilities small enough to read in an afternoon — plus a keystone document, the coordinator contract, that turns "some centralization, done safely" into a checkable property instead of a marketing promise. Above the waist sit thin profiles: DMTAP (mail, the reference profile), TRACT (commerce), WRAP (work), and a set of further drafts — media, social, real-time calling, search, reachability. Below the waist, KOTVA adopts rather than reinvents: Ed25519, HPKE, deterministic CBOR, MLS, libp2p, SFrame, WebRTC, and a slate of external bindings for recovery, reputation, payments, storage, and dispute. 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 centralization 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 has 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 did the opposite: the core is almost nothing, and everything else is a profile layered on top. Nostr reduced a social network to "a signed JSON event, relayed by dumb relays"; AT Protocol to "a signed content-addressed repo with pluggable identity." Both won by being small enough that a new client, or a new application kind, did not have to 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 must use the Sync op algebra, not a parallel CRDT it calls the same name. Two independently built profiles interoperate on any capability they both adopt — 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. 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.

2.2 Sync — the one new normative capability

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, generalized 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 amortized 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 that was 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

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

Decentralize 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.

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, generalized 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 Authorize, 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 centralizes and never finishes — which is exactly how anti-abuse would otherwise regrow a second centralized 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

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.

§4 Bindings — adopt, don't reinvent

KOTVA specifies new bytes only where nothing proven exists, and binds everywhere else. 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

Every real-world service reduces to the same small primitive set — OFFER · MATCH/RESERVE · REPUTATION · ESCROW · ORACLE · DISPUTE · PAY — differing mainly in MATCH's assignment rule (nearest, best-fit, highest-bid) or dropping MATCH entirely for a single-owner RESERVE. Because services reduce to the same primitives, "different products" are thin profiles standing on one substrate, not separate systems.

§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) 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 authorize rather than classify, priced rather than centrally-filtered abuse, inert replay, and metadata minimized-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 is being quarantined to non-normative status rather than perfected on the critical path.

• Spec license: 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) 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).