The Chronimy Architecture

Crypto Scam Protection Guide

USD 9.3B — Lost to Crypto Fraud in 2024 · Source: FBI Internet Crime Report (IC3), 2024

The 4 Scams That Steal the Most

Chronimy Will NEVER:

Important Legal Disclosures

This Architecture Paper forms Part 2 of the Chronimy Whitepaper Suite. It is a technical design document prepared for developers, integrators, smart contract auditors, and CEX technical due diligence reviewers. It does not constitute financial advice, an investment recommendation, or a prospectus of any kind. CNMY tokens are designed as utility tokens providing access to platform features and governance rights. Nothing in this document constitutes, or should be construed as, an offer or solicitation to purchase securities in any jurisdiction.

KYC / AML — All participation in Chronimy fundraising phases requires KYC and AML verification through Didit.me (primary) or iDenfy (fallback) — both selected for zero US jurisdictional footprint. Records retained for a minimum of five years.

Persons in jurisdictions where participation is restricted by applicable law must not act on any information contained herein. CNMY tokens are designed as utility tokens providing access to platform features and governance rights. Nothing in this document constitutes, or should be construed as, an offer or solicitation to purchase securities in any jurisdiction. Chronimy Holdings AG reserves the right to refuse participation from any individual or entity without explanation and without liability. Switzerland FINMA · AMLA / European Union MiCA · GDPR / United Kingdom FCA · FSMA.

Structured Orientation for Technical Readers

8 — Independent trust layers — each reinforcing the others. Anti-fragile by design: failure of any one layer does not compromise the system as a whole.

Relationship to Paper 1 — Part 2 of 5-Paper Suite

The Executive Whitepaper (Paper 1, 91 pages) covers the business model, economic model, tokenomics, fundraising strategy, and growth mechanics. This paper does not repeat that material. For context on the CHF 65.5M community fundraising ceiling, CNMY economics, and the Aurora-to-Supernova phase model, refer to Paper 1. Section numbers here (6.x–9.x) map directly to Paper 1's Part 2 Technical reference on pages 88–91.

Six Key Technical Claims — Verifiable Against This Document

The 8-Layer System — Overview & Anti-Fragile Design Principle

The Independent Trust Architecture is Chronimy's core technical framework — an eight-layer system that transforms trust from a subjective judgment into an objective, verifiable, and enforceable property. Each layer operates independently while communicating via standardised interfaces, creating an anti-fragile design where the failure of any single layer does not compromise the system as a whole.

This section documents layers 1 through 8 as technical design specifications, followed by the Polygon infrastructure and cryptographic primitives on which the entire stack is built.

The Independent Trust Architecture (ITA) is Chronimy's technical framework that transforms trust from a subjective judgment into an objective, verifiable, and enforceable property. The system comprises eight layers, each serving a distinct purpose while communicating with adjacent layers via standardised interfaces.

The architecture is designed to be anti-fragile — a property that distinguishes it from merely resilient systems. Where a resilient system resists failure, an anti-fragile system actively improves when subjected to stress, attack, or partial failure.

8 — Mutually reinforcing layers — no single point of failure by architectural design, not by policy

Eight-Layer Architecture — Complete Reference

Layer 1 — Identity

The Identity Layer establishes three properties for every Chronimy user: they are a real human being, not a bot; they are a unique individual with no duplicate accounts; and they are financially committed via Proof-of-Bank. This three-pronged design makes fake account creation economically unviable at scale.

KYC Verification Flow

Layer 2 — Behavioural

The Behavioural Layer monitors transaction history over time, building a dynamic trust score that reflects real-world reliability and gates users through the badge progression system. Unlike static reputation systems, the score is earned through demonstrated behaviour on the platform, not purchased or assigned. Exact scoring parameters — thresholds, decay windows, weighting formulas — will be defined during SotaTek technical workshops as part of the production specification process.

Behavioural Scoring Algorithm — Design Specification Notice. The specific behavioural metrics, trust score ranges, scoring weights, anomaly detection thresholds, and score decay parameters are implementation details to be defined during SotaTek technical workshops. This paper specifies the architectural intent — that a continuous, on-chain-referenced behavioural score drives badge progression — without prescribing parameter values that have not yet been validated through technical design. A scoring specification document will be produced during the Nebula phase technical engagement.

Badge Progression — Confirmed Requirements

Score Earned,Not Purchased — Badge progression requires demonstrated transaction behaviour on the Chronimy platform. There is no mechanism to buy a higher badge tier. CNMY holdings do not affect badge level. Trust is built through action, not through assets.

Architectural Principles — Confirmed

• Score is Earned, Not Purchased. Badge progression requires demonstrated transaction behaviour. No mechanism to buy a higher tier.
• Dynamic, Not Static. The score reflects current reliability — recent behaviour is weighted more than historical behaviour, with a decay window for inactivity.
• On-Chain Referenced. Badge state and transaction count are stored on-chain. The scoring engine reads from the blockchain — tamper-proof inputs.
• Anomaly Detection Active. Velocity anomaly detection flags unusual patterns — sudden transaction spikes, coordinated rating activity, or atypical dispute rates.

Layer 3 — Escrow

The Escrow Layer holds transaction funds in a Polygon-deployed smart contract until verified release conditions are met. No intermediary. No geographic restriction. Settlement occurs on-chain in seconds rather than days. The fee structure is gated by badge tier — verified users with proven track records pay less, creating a direct financial incentive for trust-building behaviour on the platform.

Escrow Contract — Five-State Machine

Design Specification — Full interface specification in Part 2, Section 7.4. Implementation by SotaTek.

Escrow Fee Structure — Badge-Tiered (Confirmed)

Layer 4 — PRU Vault

0 — Founder access to the PRU Vault — enforced at the contract level, not by policy commitment

The Protocol Reserve Unit (PRU) Vault is the financial backstop of the Chronimy ecosystem. Funded by Green Badge activation events, the PRU holds CNMY in a smart contract governed exclusively by the Guardian Council. Zero founder access, zero foundation access — enforced at the contract level, not by policy. The PRU exists to compensate verified users who suffer platform-attributable losses that survive the dispute resolution process.

Green Badge Activation — CNMY Distribution (10,000 CNMY total, subsidised from the Burn Reserve — the badge is free to the member)

Layer 5 — AI Trust

The AI Trust Layer augments human-level verification with automated pattern recognition and fraud detection. AI outputs are advisory inputs to governance — never final decisions. No user account is suspended, no badge is revoked, and no escrow is frozen solely on the basis of an AI output.

Three-Phase AI Development Roadmap

AI GovernanceCommitment — AI outputs are advisory inputs to governance, never final decisions. No user account is suspended, no badge is revoked, and no escrow is frozen solely on the basis of an AI output. Every AI-triggered action requires either a human Guardian review or an on-chain appeal path. This constraint is architectural — it will be enforced in the contract and governance specifications produced during SotaTek workshops, not left to operational policy.

Layer 6 — Beacon

The Beacon Layer makes Chronimy auditable by anyone, at any time, without asking permission. Every significant platform event is emitted as an on-chain Polygon event log and archived to IPFS for permanent, content-addressed storage. Beacon is the foundation of Chronimy's trust claim — not a marketing statement but a verifiable technical property.

The Beacon Layer makes Chronimy auditable by anyone, at any time, without asking permission. Every significant platform event is emitted as an on-chain Polygon event log and archived to IPFS for permanent, content-addressed storage.

Beacon Access by Audience

Event Categories — Beacon Monitoring Scope

Zero PermissionRequired — Beacon data is publicly available on Polygon and IPFS. No API key, no Chronimy account, no permission request needed. Auditors, researchers, and regulators access the same data as the Guardian Council — blockchain-native transparency is not a feature, it is the architecture.

Layer 7 — Governance

The Governance Layer is the human accountability layer of Chronimy. It provides two distinct governance functions: protocol governance through the Guardian Council, which manages custody, treasury parameters, and critical protocol decisions; and dispute adjudication through Quorum Guardians, a rotating panel of verified users who resolve individual transaction disputes. Both bodies operate on-chain, with all decisions recorded via the Beacon Layer. Protocol Governance Guardian Council 7 Seats. Dispute Adjudication Quorum Guardians 21 – 49. DAO Voting — 1 Badge = 1 Vote. Community governance uses badge-based voting, not token-weighted voting. Every verified Green Badge or higher holder has exactly one vote on protocol proposals — voting weight does not increase with CNMY holdings, badge tier, or account age. This prevents plutocratic concentration. Enforced in the governance contract specification.

Governance Responsibilities — Confirmed Division

Layer 8 — Development

SotaTek Delivery Scope by Phase

Funding model: each phase’s build is funded by that phase’s community raise via the Rédeas vault — community-controlled, milestone-gated, with clawback if a milestone fails. A separate backstop would cover any shortfall, so completion does not hinge on any single raise hitting target.

External Layer — Trust Verification (Chronimy Verify)

The Five Architectural Primitives

Verify combines five primitives that, individually, exist in production elsewhere — but no system has combined all five into a single trust layer. The combination is the patent claim.

Verify — Verification Flow & Heartbeat

The Verification Flow (8 Steps)

The Three States

Heartbeat Behaviour

The heartbeat is the visible reinforcement that the badge is live, not static. It is risk-context-aware — visual emphasis intensifies on pages where attention matters most.

Anti-Circumvention

Some site owners may try to install the badge for SEO benefit but hide it visually with CSS. The backend detects this:

• Periodic headless-browser checks render the page as a real visitor would see it
• If the badge is not visible, status flips to amber within 48 hours
• Site owner gets one warning and a remediation window
• If still hidden, status flips to red and badge is revoked

One-Time Verification Codes (B2C Companion)

An extension of the Trust Code™ primitive, designed to kill email phishing:

• Verified site generates a one-time verification code for any user-facing communication (email, call, transaction)
• User checks the code at chronimy.org/verify
• Code expires in 60 seconds
• Real emails carry a verifiable code; scams cannot generate one without server-side access to the verified site's signing key

Polygon Infrastructure

Single Chainby Design — Multi-chain deployment has been permanently retired from the Chronimy specification. Operating across multiple chains multiplies the attack surface, fragments liquidity, and creates cross-chain bridge risk — one of the largest sources of losses in Web3.

Chronimy requires a blockchain that is fast enough for real-world transaction escrow, cheap enough that fees never become a barrier to participation, and mature enough that smart contract security is well-understood. Polygon PoS satisfies all three requirements. It also provides EVM compatibility — meaning the entire Solidity development ecosystem, tooling, and auditing infrastructure available for Ethereum is directly applicable. CNMY is Polygon-native by deliberate design decision, not by default.

Chain Selection Criteria — How Polygon Was Evaluated

Scalability Architecture

Smart contract state — badge ownership, escrow balances, PRU holdings, and governance votes — lives on-chain permanently. Application logic, API serving, and user-facing computation run off-chain and write results to the chain only when a permanent record is required.

Four Scalability Design Principles

• On-Chain Minimisation. Only data that requires permanent, tamper-proof record is written to Polygon. User session data, notification preferences, and UI state are never on-chain. Every on-chain write is a deliberate, justified action — not a default.
• Horizontal Off-Chain Scaling. API infrastructure, KYC processing queues, and Beacon event indexing scale horizontally as user volume grows. The on-chain layer does not change — only the off-chain systems serving it expand. Platform capacity scales independently of smart contract design.
• Batch Operations Where Possible. Badge state updates, Beacon event archiving, and scoring computations that do not require immediate on-chain confirmation are batched and written in periodic settlement transactions. This reduces gas costs and chain congestion without compromising data integrity.
• Phase-Matched Capacity Planning. Infrastructure provisioning follows the fundraising phase model — Aurora capacity requirements are a fraction of Supernova requirements. Over-provisioning at launch is avoided; capacity is scaled in advance of each phase milestone based on verified user growth data.

Cryptographic Primitives

ZERO — Complete private keys held — no human holds a full private key. The key does not exist as a whole. It exists only in the act of threshold agreement across 8 minimum participants.

Every blockchain project that holds user funds faces the same problem: how do you prevent a single compromised person, a single stolen device, or a single bad actor from draining the treasury? Traditional multi-sig partially solves this but creates a discoverable key set. Chronimy's answer is a dual-group MPC (Multi-Party Computation) ceremony — a cryptographic protocol where 14 independent participants jointly control treasury access, but no single participant ever holds a complete private key. The key does not exist as a whole. It exists only in the act of threshold agreement.

MPC Architecture — Confirmed Parameters: 14 Total Council Participants (7 public + 7 private). 4-of-7 threshold per group required to authorise any custody operation. 48–72h Ceremony Timelock. ZERO Complete Keys Held — no human holds a full private key. Ever.

Trust Code — 15-Minute Rotating Member-to-Member Authentication Code

Design Goals

• Rotating credential: Trust Codes change every 15 minutes (UTC-aligned windows). Capture of a single Trust Code does not enable impersonation beyond the current window.
• Forward secrecy: Compromise of current-window key material does not retroactively reveal prior Trust Codes.
• Compromise recovery: If HSM key material is compromised, all-member force-rotation occurs via authenticated channel within minutes.
• Member-only secret: No party other than the verifier and the member can reproduce a valid Trust Code.
• Constant-time implementation: Implementation is constant-time per Common Criteria EAL4+ guidance to resist timing side-channel attacks.
• Standards-based: Every primitive is a published international standard.

Cryptographic Primitives — Specification

Trust Code Generation — Algorithm

For each 15-minute UTC-aligned window, a verifier requesting authentication of a member computes:

The 8-digit display code is what the user sees and shares with a verifier in a member-to-member interaction. The full 256-bit Trust_Code is used for cryptographic verification at the protocol level. Window alignment ensures that both the requesting member and the verifying member compute the same Trust_Code for the same window, regardless of network latency.

Forward Secrecy — Merkle Commitment Chain

Each window's Trust_Code is computed independently, and the chain of windows forms a Merkle commitment chain — each window's Trust_Code is a hash-derived child of prior epoch state, but knowing window N's Trust_Code does not reveal prior windows' Trust_Codes due to the one-way nature of HKDF combined with HSM-protected master_key. This satisfies the forward secrecy property: if a Trust_Code is captured during window N, it cannot be used to derive Trust_Codes for windows 1 through N-1.

Compromise Recovery

If the HSM master_key is suspected of compromise, the recovery procedure is:

1. Guardian Council 4-of-7 multisig signs an emergency rotation directive (this is one of the AMBER-tier emergency activation triggers per Section 2.7).
2. The HSM rotation procedure provisions a new master_key in a cryptographically-isolated successor HSM unit.
3. An authenticated channel broadcast (X25519 ECDH key exchange + Ed25519 signature) sends the rotation acknowledgement to all member devices via TLS 1.3 + DTLS-SRTP for real-time messaging.
4. All member devices update their member_secret derivation to use the new master_key starting from the next 15-minute window.
5. The compromised master_key is permanently retired; all Trust_Codes derived from it become invalid.

The full rotation completes within minutes — bounded by the 15-minute window cycle plus broadcast propagation time. Members on the platform during rotation receive an authenticated message indicating the rotation event.

Transmission Patterns

• Verifier → Member request: Trust_Code request flows over TLS 1.3 with mandatory perfect forward secrecy (RFC 8446) between the verifier's client and the Chronimy backend.
• Member-to-member interaction: When two members interact directly, X25519 ECDH (RFC 7748) establishes a shared secret between them without disclosure to Chronimy backend. ChaCha20-Poly1305 AEAD (RFC 8439) protects the actual message content.
• HSM access: Backend access to HSM occurs via mutual TLS (mTLS) with hardware-backed certificate pinning. No backdoor authentication exists.
• Real-time channels: For real-time messaging contexts, DTLS-SRTP (RFC 5764) protects authenticated channels with optional Signal Protocol patterns for end-to-end encryption.

Rate Limiting & Anti-Abuse

• Trust Code request rate: 5 requests per minute per requesting member (HSM-enforced)
• Daily request cap: 50 requests per day per member (HSM-enforced)
• Window-bound replay protection: Each Trust_Code is valid only within its 15-minute window. After window expiry, replay returns a verification failure.
• Side-channel resistance: Verification operations are implemented in constant time. Comparison of submitted Trust_Code against expected Trust_Code uses constant-time comparison (e.g., hmac.compare_digest) to prevent timing-based extraction.

Implementation Security Posture

• FIPS 140-3 Level 3+ HSM: Master key material held in FIPS-validated HSM with tamper-evident hardware envelope, role-based access control, and physical-attack response (zeroisation on tamper detection)
• EU-regulated tier-1 datacentre: HSM hosted in datacentre with compliance to GDPR, NIS2 Directive, and EU regulatory framework for critical infrastructure
• 90-day key rotation cycle: HSM master keys rotate every 90 days as standard practice, plus immediate emergency rotation if compromise is suspected
• Cryptographic implementation by audited library: Use of audited cryptographic libraries (libsodium, NaCl-equivalent) for Curve25519 / X25519 / Ed25519 / ChaCha20-Poly1305 operations
• Open implementation: The Trust Code protocol specification is documented openly. Implementation details remain operationally confidential where disclosure could enable attack — the specification itself is not security-by-obscurity

External Review Intent (Forward-Looking Commitment)

Standards & RFCs Cited

• FIPS 180-4 — Secure Hash Standard. National Institute of Standards and Technology (NIST). SHA-256 specification.
• RFC 5869 — HMAC-based Extract-and-Expand Key Derivation Function (HKDF). IETF Internet Engineering Task Force. Key derivation methodology.
• RFC 7748 — Elliptic Curves for Security. IETF. X25519 elliptic curve specification.
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA). IETF. Ed25519 digital signature specification.
• RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols. IETF. Authenticated encryption specification.
• RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3. IETF. Transport encryption specification.
• RFC 9180 — Hybrid Public Key Encryption (HPKE). IETF. Reference for end-to-end encryption patterns.
• NIST SP 800-57 — Recommendation for Key Management. Key management lifecycle guidance.
• NIST SP 800-90A/B — Random Number Generation Standards. Entropy sources and DRBG specifications.
• FIPS 140-3 — Security Requirements for Cryptographic Modules. NIST. HSM validation requirements.
• Common Criteria for Information Technology Security Evaluation — EAL4+. ISO/IEC 15408. Evaluation Assurance Level guidance for side-channel resistance.
• TCG TPM 2.0 Library Specification. Trusted Computing Group. Trusted Platform Module 2.0 specification.
• RFC 5764 — Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP). IETF. Real-time channel authenticated encryption.

Smart Contract Security

Honest Risk Disclosure

No smart contract system carries zero risk. Chronimy publishes its residual risk profile openly — a practice that distinguishes credible projects from those that make unverifiable safety claims. The MPC custody architecture and dual audit requirement are designed to drive these risks as low as technically achievable, but honest documentation of residual risk is itself a trust signal. Investors, users, and regulators should understand what the design mitigates and what remains.

Dual Independent Audit Requirement

Mandatory Security Requirements — All Contracts

The Anti-Fragile Property — Confirmed. The nine layers of the ITA are not independent features — they are mutually reinforcing defences. Identity verification makes behavioural scoring meaningful. Behavioural scoring makes escrow fee tiers justified. Escrow tiers fund the PRU vault. The PRU vault backstops the trust claim and backs Verify coverage. AI Trust augments behavioural scoring. Beacon makes all of it auditable. Governance ensures no single actor controls any of it. Development ensures it is built to specification. Verify extends the trust architecture beyond the platform's own users to any website on the open web. Remove any one layer and the others are weakened. Strengthen any one layer and all others benefit. This is anti-fragility by design. All nine layers — cross-reference below.

All Nine Layers — Cross-Reference

Contract Architecture Overview

The Chronimy smart contract suite is designed as a set of single-responsibility contracts that communicate through defined interfaces. No contract handles more than one domain. The escrow contract does not know about badge levels — it calls the badge registry. The burn contract does not know about PRU vault distribution — it calls the vault contract. This separation means each contract can be audited, tested, and upgraded independently. A vulnerability in one contract cannot cascade uncontrolled into another.

Contract Suite — All Contracts and Their ITA Layer

MPC Custody Ceremony

Why TwoIndependent Groups — A single group of 14 could be compromised by corrupting just 4 members from the same network. The dual-group structure ensures Group A and Group B have no overlap in identity, jurisdiction, or accountability. Compromising one group entirely still yields nothing.

The MPC ceremony is the foundational custody event for the Chronimy protocol. It distributes cryptographic key material across 14 independent participants such that no complete private key is ever held by any single person or device. Treasury transactions can only be authorised when at least 4 participants from Group A and 4 participants from Group B simultaneously participate in a signing ceremony — a requirement that makes collusion, coercion, or compromise of any single group insufficient to move funds.

Confirmed MPC Parameters: 7 + 7 Participants — Group A: public. Group B: known only to regulators and FINMA. 4 + 4 Threshold — 4 of 7 from each group required. Minimum 8 signers across both groups. 48–72h Timelock — every ceremony has a publicly verifiable timelock before execution.

Confirmed MPC Parameters

Signing Ceremony — Process Flow

CNMY Token Contract

Confirmed Token Properties

Token Allocation — Confirmed Vesting Schedule

Escrow Contract Interface

Contract Events — Beacon Layer Audit Trail

Vesting Contract

Section 7.5 Vesting Contract · On-Chain Vesting — Six Variants · Exchange Listing Trigger · Designated Wallet Destination. Design Principle: The vesting system is fully autonomous. No human holds keys to any vesting contract. No founder, Guardian, or SotaTek engineer can manually release, accelerate, or modify any vesting schedule after deployment. Vesting triggers, release rates, and destination addresses are locked at the one-time deployment ceremony and cannot subsequently be altered. This is a constitutional guarantee, not a policy. Vesting trigger all schedules activate on one event: first confirmed CEX listing via oracle feed. CNMY is generated at Nebula deployment but vesting does not begin until listing. "first listing" does not apply to Chronimy.

Vesting Variants — Six Parameterised Contracts

Vesting trigger: All schedules activate on one event: first confirmed CEX listing via oracle feed. CNMY is generated at Nebula deployment but vesting does not begin until listing. "first listing" does not apply to Chronimy. This is a constitutional guarantee, not a policy. Vesting triggers, release rates, and destination addresses are locked at the one-time deployment ceremony and cannot subsequently be altered.

Vesting Variants — Six Parameterised Contracts

Immutability Table — Post-Deployment Properties

Burn Contract

The Second Deflationary Hammer

4,200 — CNMY burned per Green Badge activation — permanently sent to 0x000…dEaD. Cannot be recovered, unwrapped, or redirected. Canonical figure.

Every Green Badge activation burns 4,200 CNMY permanently. This is not a fee. The tokens are sent to the zero address (0x000…dEaD) and destroyed forever — they cannot be recovered, unwrapped, or redirected. The burn contract executes automatically on badge issuance with no human trigger required. At projected scale, Green Badge activations create a structural deflationary pressure that compounds with the Buyback profit allocation (13% of all platform profit, 80% burn / 20% IPDF Strategic Reserve top-up).

Green Badge Activation — Token Flow. 10,000 Total CNMY Required per Green Badge activation — the full 10,000 CNMY is the activation unit. 5,000 PRU Vault — locked in PRU vault — provides CHF 1,000 protection coverage for the badge holder. 4,200 Burned Forever — sent to zero address — permanent removal from circulating supply. 800 Rewards — 500 member airdrop + 300 verifier rewards (3 × 100 CNMY each).

Burn contract · badge-triggered permanent deflation · 4,200 CNMY burned per Green Badge · self-executing & immutable · the second deflationary hammer. Badge registry contract. It contains no admin functions, no pause mechanism, and no override capability. SotaTek note: Burn contract specification requires confirmation of zero-address standard for Polygon PoS. Recommended: use a standard ERC-20 burn function, verified to remove from totalSupply.

Green Badge Activation — Full Token Flow (10,000 CNMY)

PRU Compensation Review Contract

PRU Coverage by Badge Tier

Claims Process — 5-Stage Guardian Approval Flow

Claim Lifecycle — From Dispute to Payout

Claims require 4-of-7 Guardian Council approval. No claim can be processed without reaching this quorum. No founder, SotaTek engineer, or individual Guardian can approve a claim unilaterally.

Autonomous Treasury

The CentralGuarantee — No human holds keys to the Chronimy treasury. No founder, Guardian, or SotaTek engineer can initiate a disbursement. All revenue flowing into the treasury is split and distributed by smart contract logic that executes automatically on receipt.

Ten-Way Profit Split — All Post-Launch Platform Profit

Every CHF and CNMY of profit routes through ten sub-accounts under three distinct authorisation regimes — (A) on-chain autonomous contracts (Collateral Provision Fee · Burn · PRU Replenish · all market-buy via TWAP), (B) multisig/DAO authorisation (Development Escrow 4-of-7 Guardian Council · DAO Governance >66% supermajority), and (C) AG nominated director fiat administration (Licensing · Member Growth · Core Team \& Ops · Security \& Compliance) under Swiss CO Art. 716+. Vision Guardian and AI Oversight observe all three regimes. This is the architectural embodiment of Chronimy's constitutional 10-way profit split — operated by Chronimy Holdings AG with separately-constituted Chronimy Stiftung for charitable layer — not a policy statement, but a cryptographic and corporate-governance fact.

Trust-Locked Token Architecture

In every other token system, possession of a private key is sufficient to transfer funds. In Chronimy, it is not. Both the sending and receiving wallet must hold a valid verified badge for any transfer to execute. A stolen private key cannot move CNMY to an unverified wallet. This bilateral verification is implemented at the ERC-20 transfer function level — it is not a UI restriction or a policy — it is enforced cryptographically by the smart contract on every transfer attempt.

5-Stage Transfer Validation — Wallet Level

5-Stage Transfer Validation — Wallet Level: Failure at any single checkpoint aborts the transfer entirely.

Failure at any single checkpoint aborts the transfer entirely. No administrator or Guardian can override a checkpoint failure.

The contract emits a specific error code identifying which checkpoint failed, enabling targeted corrective action. No administrator or Guardian can override a checkpoint failure — resolution requires the relevant party to meet the credential requirement directly.

Trust-Locked Token Architecture ⊕ IP

The Core Security Guarantee

In every other token system, possession of a private key is sufficient to transfer funds. In Chronimy, it is not. Both the sending and receiving wallet must hold a valid verified badge for any transfer to execute. A stolen private key cannot move CNMY to an unverified wallet. This bilateral verification is implemented at the ERC-20 transfer function level — it is not a UI restriction or a policy — it is enforced cryptographically by the smart contract on every transfer attempt.

5-Stage Transfer Validation — Wallet Level

Failure at any single checkpoint aborts the transfer entirely. The contract emits a specific error code identifying which checkpoint failed, enabling wallets to surface precise user feedback. All five checkpoints are enforced on every transfer — including transfers initiated by smart contract interactions, not just user-originated calls. This prevents malicious contract-to-contract drains.

Glass Treasury API

Design Philosophy — Radical Transparency

The Glass Treasury is not a reporting tool. It is a constitutional commitment. Every CNMY token movement, every profit split disbursement, every compensation review request, every burn event, and every Guardian vote is permanently visible to any person, institution, or regulator — in real-time, without login, without permission. Chronimy has no private treasury. There is nothing to hide. The Glass Treasury API makes this technically enforceable.

Core API Endpoints — Design Intent (SotaTek Implementation)

The Glass Treasury API is a read-only public interface — no authentication required, no rate limiting on public queries. It is deliberately designed to be scraped by regulators, journalists, and researchers without any friction. Chronimy's position is that any system that requires a login to verify financial transparency is not transparent.

STRIDE Threat Model

Threat Modelling Methodology

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is the industry-standard framework for systematic threat analysis of distributed systems. Applied to Chronimy's smart contract suite, each category maps to specific attack vectors and the architectural controls that mitigate them. This model forms part of the audit brief for both independent security firms.

Security Audit Framework

The Dual Audit Requirement

No Chronimy contract deploys to mainnet without passing audit by two independent top-tier security firms. This is a constitutional requirement, not a recommendation. The two firms must be selected independently, must not share personnel on the engagement, and must produce separate reports. All audit findings are published publicly — including findings that are disputed or accepted as residual risk. Budget: CHF 150–200K (SotaTek Deliverable 13, within Nebula phase).

Audit Phases — Pre-Mainnet Sequence

Audit Scope — Minimum Required

• CNMY Token contract — transfer gate, bilateral badge check, supply mechanics
• All six Vesting contracts — cliff accuracy, linear distribution, listing trigger
• Burn contract — irreversibility, per-badge trigger, no recovery path
• Compensation Review Requests contract — Guardian approval requirement, coverage cap enforcement
• Escrow Factory and individual escrow instances — five-state lifecycle, dispute handling
• Autonomous Treasury — ten-way split accuracy, zero-founder-access enforcement
• MPC custody architecture — threshold logic, resharing protocol, timelock

Audit reports are published on-chain (IPFS hash anchored) and in the Glass Treasury public API within 14 days of receipt. Any critical or high-severity finding must be remediated and re-audited before deployment proceeds.

Smart Contracts & Custody — Section Review

Part 2 in One Paragraph

Part 2 specified the complete smart contract suite that SotaTek will build in the Nebula phase: an ERC-20 token on Polygon PoS, six vesting variants triggered by exchange listing, a badge-triggered burn contract destroying 4,200 CNMY per Green Badge, a PRU Compensation Review Contract governed by 4-of-7 Guardian Council approval, an autonomous treasury splitting all revenue ten ways with zero founder access, a Trust-Locked bilateral badge transfer gate, a read-only Glass Treasury API, a STRIDE threat model across six attack categories, and a dual independent audit mandate budgeted at CHF 150–200K. Every contract is immutable post-deployment. No human holds keys. No override exists.

KYC & Liveness Pipeline

Identity Layer Purpose

The KYC & Liveness Pipeline is Layer 1 of the ITA — the entry gate for every participant in the Chronimy trust system. It establishes that a real, unique human is behind each verified identity. Without passing Layer 1, no badge can be issued, no escrow contract can be initiated, and no PRU coverage is available. The pipeline uses Didit.me as the canonical KYC provider — EU-resident, GDPR-compliant, and carrying zero US jurisdictional footprint, which is a constitutional requirement of the Chronimy architecture.

KYC Flow — Step by Step

Proof-of-Bank

What Proof-of-Bank Solves

Deepfake-proof liveness and government-document KYC are strong — but an adversary with resources can fabricate multiple verified identities. Proof-of-Bank adds an economic anchor: a CHF 3 micro-payment from a verified bank account. The cost per fake identity becomes CHF 3 × number of accounts — scaling linearly with attack scale. For a legitimate user, CHF 3 is negligible. For a Sybil attacker creating thousands of fake identities, the cost becomes prohibitive while the cryptographic bank-identity link defeats the attack independently of cost.

Refer-3 Anti-Sybil Mechanism

The Third Layer of Sybil Resistance

KYC proves a document. Proof-of-Bank proves a bank account. Refer-3 proves a social network. To earn a Green Badge, a user must be vouched for by three independent, already-verified users. This social attestation layer means fake identities — even with real documents and bank accounts — cannot self-certify. They need real humans who are already inside the system to vouch for them. Sybil attacks require not just fake identities, but fake relationships with real people — a fundamentally different and much harder attack surface.

K-Factor Mechanics

The Refer-3 mechanism is the primary viral coefficient engine in the Chronimy growth model. K driven by 3 witnesses × verifier progression rate. If 20% of verifiers eventually complete their own Green Badge journey (conservative given they have already been asked), K = 0.6. Combined with other growth vectors (Trading Arena, content distribution programme), this delivers the documented viral coefficient that underpins the Monte Carlo growth simulation.

The warm pool — users who were invited as verifiers but have not yet completed their own badge — represents 6–18 month deferred conversion. These users are the highest-probability organic growth source in the system: they have a personal relationship with a verified member, they have already been introduced to Chronimy, and the barrier to re-engagement is lower than cold acquisition.

Badge Progression System

The Badge is the Trust Score

In Chronimy, a badge is not a reward — it is a cryptographic proof of earned trust. Each tier represents a verifiable threshold of demonstrated trustworthiness: KYC identity (Red), socially-witnessed identity (Green), transaction track record (Silver), and community-recognised governance participation (Gold). Badge tier directly determines escrow fee rates and PRU protection coverage — making trust commercially tangible for every transaction.

Trust Code

What the Trust Code Is

The Trust Code is a short alphanumeric credential — unique to each holder — that serves as a portable trust signal across any platform, marketplace, or communication channel. It is called Rotating because the live code regenerates every 15 minutes: a code captured by a phishing page is useless within minutes, because only the holder can see and present the current code from their Chronimy app. The Trust Code is available to Green Badge holders and above — Red Badge holders do not receive one. When verified, the code resolves to the holder's current badge tier and protection coverage.

Verification Workflow

A counterparty shares their Trust Code before any transaction. The verifying party enters the code at chronimy.com or calls the Verification API endpoint. The system returns: badge tier, PRU coverage level, issue date, and validity status — in under 200ms. No account required to verify. No login. The code resolves to publicly readable on-chain state.

The Trust Code is designed to be shared verbally, by text, by QR code, or embedded in a platform profile. It functions as a portable credential that travels with the user across every platform — regardless of whether that platform has a Chronimy integration. Even a platform with no API integration can use the chronimy.com lookup page to verify a counterparty in seconds.

Contextual Trust Score Framework

Why Trust Needs a Score, Not Just a Badge

A badge proves a threshold — binary. A trust score is continuous: it rises and falls with behaviour and detects warning signals before they become disputes. The CTS operates beneath the badge layer — it determines whether a holder performs at their tier's standard and feeds anomaly detection protecting the PRU vault from sophisticated fraud.

Three-Phase AI Development

Phase 1 (Nebula): Rule-based CTS scoring using on-chain data only. Simple weighted formula. No ML component. Sufficient for launch and early platform operation.

Phase 2 (Pulsar): Hybrid model. Rule-based scoring plus third-party AI API anomaly signals. Transaction pattern analysis. Domain-specific fraud pattern detection begins as platform data volume grows.

Phase 3 (Supernova): Proprietary fine-tuned model trained on anonymised Chronimy transaction data. Full contextual scoring. Predictive anomaly detection feeding PRU vault risk management.

Verification API

The API Makes Trust Portable

The Verification API is how Chronimy trust travels beyond the Chronimy platform. Any marketplace, B2B platform, or payment provider can integrate a single endpoint call to instantly verify a counterparty's badge tier, PRU coverage level, and Trust Code validity — before any transaction commits. No user account required. No login. The API reads from on-chain state in real time, making it designed to read live on-chain state, with stale-result risk constrained to network availability.

Verification System — Section Review

Part 3 in One Paragraph

Part 3 specified the complete verification stack. KYC + liveness (Didit.me, zero US footprint) · CHF 3 Proof-of-Bank Sybil anchor · 3-witness social verification for Green Badge. Badge tiers (Red → Gold) encode escalating trust with fee reductions and PRU coverage increases. The Trust Code makes trust portable. The CTS monitors behaviour continuously. The Verification API exposes all of this to any platform via a single endpoint. Result: real-world identity + bank account + social network required to participate fully.

Oracle Engine Architecture ⊘

What the Oracle Engine Does

The Oracle Engine is Chronimy's perpetual governance intelligence layer. It runs three independent AI models simultaneously — the independent AI screen, Claude, and GPT — on the same governance questions, policy proposals, dispute edge cases, and platform anomalies. Where all three reach the same conclusion, that consensus is surfaced to the Guardian Council as a high-confidence recommendation. Where they diverge, the divergence itself is flagged as a signal requiring human deliberation. The engine does not make decisions — it identifies where AI consensus exists and where human judgement is essential.

The specific prompting architecture, consensus aggregation methodology, and divergence scoring algorithm are classified as trade secrets and are not disclosed in this document. The capability described above is accurate; the implementation detail is retained internally.

Quorum Guardian System

Two Distinct Bodies — Critical Distinction

The Chronimy governance architecture has two separate bodies that are frequently confused. The Guardian Council is the 7-seat executive authority — elected domain specialists who hold conditional power over platform-level decisions. The Quorum Guardians are a separate body of 21–49 Gold Badge adjudicators whose role is dispute resolution and compensation review requests review. They are elected independently, operate on a rotating basis, and report findings to the Guardian Council — they do not hold platform authority themselves. One is strategy; the other is adjudication.

Dispute Resolution Flow

When an escrow dispute is raised that cannot be resolved by the two-party smart contract mechanism, it escalates to a randomly-selected Quorum Guardian panel of three. The panel reviews evidence submitted by both parties, evaluates conduct against platform standards, and issues a finding. Findings are published on-chain (anonymised). The Guardian Council reviews panel findings for compensation review request approval where coverage is triggered. A pattern of Guardian panel findings against a user may trigger a badge review.

External Conduct Review

What the ECR System Does

The External Conduct Review (ECR) is the mechanism by which verified users report conduct by other platform participants that falls outside normal dispute resolution — fraud allegations, impersonation, off-platform coercion, or systemic bad-faith behaviour. Unlike a standard escrow dispute (transaction-specific), an ECR report concerns a pattern of conduct that affects or could affect multiple participants. ECR reports trigger a Quorum Guardian panel review, with findings escalated to the Guardian Council for badge action where warranted.

ECR Report Data Schema

Each ECR submission carries: evidence package IPFS hash, subject and reporter identity, allegation category, and linked transaction IDs. Evidence is stored off-chain — only its hash is anchored on-chain.

ECR Outcomes

Dismissed: Insufficient evidence or allegation not substantiated. Reporter's record unaffected. Repeated bad-faith ECR filings are themselves a conduct flag.

Warning Issued: Conduct found to breach platform standards. Formal warning attached to subject's on-chain record. CTS score impacted.

Badge Suspended: Pattern of conduct or severe single incident. Guardian Council activates suspension. All open transactions paused. Subject notified of appeal process.

Badge Revoked: Confirmed fraud or systematic bad-faith behaviour. Irreversible at Quorum Guardian level — requires Guardian Council supermajority (5-of-7) to execute.

API Architecture & Authentication

Design Principles

The Chronimy API is designed for maximum portability — a marketplace, B2B platform, or payment provider should be able to integrate trust verification in under an hour. It follows REST conventions for synchronous operations and WebSocket for real-time badge state subscriptions. All API specifications represent design intent — implementation detail and confirmed endpoints are SotaTek Deliverable 12, produced during the Nebula phase technical engagement.

Authentication

API keys are prefixed: ck_live_ for production, ck_test_ for sandbox. Keys are issued through the developer portal, available from Nebula launch. OAuth 2.0 follows the standard PKCE flow for user-facing integrations.

Core Endpoints — Trust & Badge

// 200 OK — verified response
{ "status": "success", "data": {
  "trust_code": "CHR-A7K2P9",
  "badge_tier": "GREEN",
  "issued_at": "2025-11-14T09:22:00Z",
  "pru_coverage": "CHF 1000",
  "valid": true
}}

// 404 — no badge found
{ "status": "error", "error": { "code": "BADGE_NOT_FOUND",
  "message": "No active badge for wallet address" }}

Core Endpoints — Escrow & Governance

Escrow Endpoints

// 201 Created
{ "data": { "escrow_id": "0x1a2b...", "state": "AWAITING",
  "fee_rate": "7%", "tx_hash": "0xabc..." }}

Glass Treasury Endpoints

Webhooks — Full Event Catalogue

Webhook Architecture

Integrating platforms register a HTTPS endpoint to receive real-time event notifications. When a subscribed event fires, Chronimy delivers a signed POST to the registered URL within 5 seconds of the on-chain event confirmation. At-least-once delivery with exponential back-off retry (1s, 5s, 30s, 5min, 30min). Events not acknowledged within 24 hours are marked failed and logged to the integration dashboard.

Badge Events

Escrow Events

Signature Verification

Each webhook delivery includes an X-Chronimy-Signature header — HMAC-SHA256 of the raw request body using your webhook secret. Always verify this signature before processing. Reject any delivery where the signature does not match.

Rate Limiting, Errors & SLAs

Standardised Error Codes

SLA Targets

SLA targets are aspirational design targets. Formal commitments will be established in the Nebula phase developer programme agreement with SotaTek confirmation of achievable parameters.

SDKs

SDK Design Philosophy

Official Chronimy SDKs wrap the REST API with idiomatic interfaces for each language. They handle authentication, request signing, error parsing, and retry logic so integrations can call verify(trustCode) in a single line. SDKs are open-source under MIT licence, maintained by SotaTek under the Nebula engagement, and published to standard package registries.

Integration Examples

Example 1 — Marketplace: Verify Seller Before Checkout (JavaScript)

Example 2 — Escrow Creation (Python)

Example 3 — Webhook Handler (Node.js / Express)

Example 4 — Embeddable Badge Widget (HTML)

The badge widget resolves the Trust Code client-side, displays the appropriate tier badge with PRU coverage, and updates automatically if the badge tier changes. No API key required for the widget — it uses the public verification endpoint.

Sandbox & Testnet Environment

Why Sandbox Matters

Integrations should never be built against production. The Chronimy sandbox environment mirrors all production API behaviour on the Polygon Amoy testnet — the standard EVM testnet that replaced Mumbai. Sandbox API keys are scoped separately and carry no real-world financial consequences. Badge upgrades, escrow flows, dispute submissions, and webhook delivery are all fully simulated.

Sandbox Tooling

• Test Token Faucet: Request test CNMY via developer portal. 10,000 test CNMY per request. No rate limit on faucet requests.
• Badge Simulation: Instantly elevate a test wallet to any badge tier without completing real KYC or Refer-3. For testing badge-tier-dependent features.
• Webhook Replay: Replay any historical webhook event to a new endpoint URL. For testing webhook handler implementations.
• Escrow Simulation: Complete escrow lifecycle in seconds rather than waiting for counterparty confirmation. Supports all state transitions.

API & Integration — Summary

What Part 4 Establishes

Part 4 defines the complete public interface layer of the Chronimy protocol. The API architecture makes trust portable — any marketplace, fintech, or B2B platform can integrate Chronimy verification in hours, not weeks. The webhook system ensures real-time badge state propagation across all integrations the moment anything changes on-chain. The SDK layer makes integration accessible regardless of developer background.

AI Trust Layer Architecture

Honest Framing — No Proprietary AI at Launch

Chronimy does not claim to have built proprietary AI. The AI Trust Layer follows a three-phase architecture that is honest about what exists today versus what will be built. At launch (Nebula phase), the layer uses established third-party AI APIs for anomaly detection. The path to hybrid and eventually proprietary models is defined — but not overstated. All materials reflect only what has been committed to build, not speculative capability.

Polygon Technical Reference

Why Polygon PoS — The Reasoning

Chronimy chose Polygon PoS as its single deployment chain after evaluating Ethereum mainnet, Arbitrum, Optimism, and Polygon zkEVM. The decision is architectural, not speculative: Polygon PoS is battle-tested (5+ years in production), has predictable and extremely low transaction costs, supports full EVM compatibility with no Solidity modifications, and has institutional-grade tooling including Hardhat, Foundry, and Chainlink. The multi-chain approach was explicitly retired — a single chain is a security and compliance advantage, not a limitation.

Glossary