Kentrin Logo

Kentrin

A Constitutional Base-Layer Monetary Standard


Overview

Kentrin is a deterministic, rule-based monetary issuance and clearing standard.

It is not a cryptocurrency, not a token, and not a speculative asset.

Kentrin defines a mathematically governed issuance protocol and a federated clearing architecture designed to function as a constitutional monetary base layer.

Unlike typical digital assets, Kentrin focuses on structural monetary rules rather than economic incentives.


Core Idea

Most modern digital monetary systems rely on incentives, competition, and governance votes.

Kentrin relies on structure.

Issuance follows a predefined mathematical schedule.
Time governs expansion.
Rules are fixed and transparent.

There are:

Money expands because time advances.


Deterministic Issuance

Kentrin supply increases at a predictable rate over fixed time epochs.

Properties of the emission model:

Total supply at any moment can be calculated directly from time alone.


System Architecture

Kentrin is composed of three primary layers.

+------------------------------+
|         Wallet Layer         |
|  (Key generation & signing)  |
+--------------+---------------+
               |
               v
+------------------------------+
|       Clearing Layer         |
|  Serverless verification API |
|  - Signature validation      |
|  - Ownership checks          |
|  - Ledger insertion          |
+--------------+---------------+
               |
               v
+------------------------------+
|        Ledger Layer          |
|    kentrin_events database   |
|  Immutable historical record |
+------------------------------+

The wallet signs messages.
The clearing layer verifies them.
The ledger records them.


Wallet Protocol Specification

Kentrin wallets generate Ed25519 keypairs.

Addresses are deterministically derived from the public key.

address = "KU1" + sha256(public_key)[0..40]

Example address:

KU1a17e3b4d9e8c3c4aef98b9e4a9e12f81c4d8c

Wallet responsibilities:

Wallets never directly modify the ledger.


Canonical Message Format

All ledger actions must follow a canonical message structure.

Transfer Message

KU|v1|TRANSFER|{note_id}|{from}|{to}|{ts}|{nonce}

Fields:

Field Description


note_id unique note identifier from current owner to new owner ts unix timestamp nonce replay protection value

The canonical message is signed with the sender's private key.


Ledger Event Model

The Kentrin ledger records state transitions, not balances.

Each entry represents a signed constitutional action.

Event types:

ISSUE
TRANSFER
SPEND

Ledger records are immutable.

Ownership is determined by the most recent valid event for a note.


Database Schema

The ledger is stored in MySQL.

Primary table:

kentrin_events

Key columns:

Column Description


event_index sequential ledger index event_type ISSUE / TRANSFER / SPEND note_id unique note identifier parent_note_id lineage reference denom note denomination from_address previous owner to_address new owner nonce replay protection txid deterministic transaction id signature_b64 cryptographic signature canonical_message signed message created_at ledger timestamp


Event Validation Rules

Before a ledger event is accepted, the clearing layer enforces several rules.

Signature Verification

The system verifies:

verify(signature, canonical_message, public_key)

If verification fails, the event is rejected.


Ownership Check

Only the current owner may transfer a note.

latest_event.to_address == from_address

Replay Protection

Each event must contain a unique nonce.

Duplicate nonce usage invalidates the transaction.


Canonical Message Integrity

The signed message must exactly match the submitted transaction data.

If any field differs, the transaction fails.


Note Lifecycle

A Kentrin note follows a simple lifecycle.

ISSUE → TRANSFER → TRANSFER → ... → SPEND

Example:

Treasury issues note
      ↓
Wallet A receives note
      ↓
Wallet A transfers to Wallet B
      ↓
Wallet B transfers to Wallet C
      ↓
Wallet C spends note

Each step creates a new immutable ledger event.


Clearing Layer

Clearing nodes validate and record transactions.

Responsibilities:

Clearing nodes do not mint currency.

They only validate and record state transitions.


API Functions

The reference implementation uses Netlify serverless functions.

ledger-submit

Handles incoming ledger events.

Responsibilities:


note-read

Returns the latest state for a note.

Example response:

{
  "note_id": "...",
  "denom": 10,
  "current_owner": "KU1...",
  "event_count": 5
}

Wallets use this endpoint to determine the latest state before submitting transfers.


Environment Variables

Clearing functions require the following variables.

DB_HOST
DB_NAME
DB_USERNAME
DB_PASSWORD
TREASURY_MINT_SECRET

PlanetScale requires TLS-enabled connections.


Time Attestation Framework

Because issuance is time-based, Kentrin relies on a federated network of Time Attestors.

There is no global blockchain ledger.
There is no chain of blocks.

Only signed, proof-backed time validation.


Design Principles

Kentrin is built on the following foundations:


What Kentrin Is Not

Kentrin is not:

It does not depend on inflationary reward cycles.
It does not require continuous network competition to function.


Vision

Kentrin is an attempt to define money as law-bound mathematics.

Not mined.
Not voted.
Not gamified.

Structured.
Deterministic.
Constitutional.