Security Paper · Trust-Locked Protection

Chronimy Security

How Chronimy protects assets and identities — the Trust-Locked architecture, the 5-checkpoint transfer system, six layers of protection, emergency recovery, the asset vault, and the Green Badge.

Written for members, security reviewers, and integration teams. For the business and token model, see the Executive Whitepaper; for the full technical design, see the Architecture Paper.

Document

Security & Protection Model

Scope

Trust-Lock · Checkpoints · Vault · Badge

Chain

Polygon PoS · Chain ID 137

Classification

Protection model & technical reference

The Architect

Chronimy · 2026

The Security PaperSHEET SEC·04

Drawn byThe Architect

DisciplineSecurity · Custody

StatusDesign — pre-audit

ScaleNot to scale (N.T.S.)

◆Written to inform, not to sell. No hype, no false promises — just a clear, honest account of how Chronimy works, built to read well on any device.

From The Architect

On Deinstitutionalisation

The moral frame for every security choice in this paper.

"Deinstitutionalisation means moving people out of institutions that have stopped looking after them, and into communities that actually do. That's the dictionary definition. It's what closed the old asylums in the 1970s and gave people their lives back. Chronimy is the same idea, for the world we're living in now."

Security in the crypto space is where the old institutions have failed most visibly. Custodial exchanges lose billions of user funds to hacks and insider theft. Self-custody tools give users full control and no protection, leaving ordinary people one phishing link away from losing everything. Neither option serves the people it was built for. This paper sets out a third architecture: Trust-Locked security that belongs to the community, held in layers the member controls, protected by structural guarantees that cannot be revoked by any single actor. It is the security layer the crypto space was supposed to build and did not.

— The Architect, Chronimy Holdings AG · April 2026

One mission: making crypto theft economically worthless. This paper documents the complete Trust-Locked security architecture underpinning the Chronimy platform.

6Protection Layers

5Transfer Checkpoints

3Guardian Designees

0.005%Modelled Theft Odds

Document scope: This paper covers Chronimy's complete security architecture — wallet protection, the Trust-Locked badge system, smart contract design, tokenomics, and the phased module sequence. All security features described are badge-optional: CNMY remains a standard Polygon PoS token fully tradeable without a badge. Protection is opt-in.

Part I — The Problem & Solution

Part II — Protection Layers

Part III — Recovery & Infrastructure

Part IV — The Badge System

Part V — Technical & Economics

USD 5.1T

Annual global fraud losses

~80%

Hot wallet theft success rate

0.005%

Badge-protected theft rate

orders-of-magnitude

Safer than a standard hot wallet

Document Overview

What This Paper Covers

The complete Trust-Locked security architecture — from the problem through to the technical implementation and economic model.

But for users who choose to verify with a Green Badge, Chronimy unlocks something the industry has never delivered before: hardware-grade security with consumer-grade usability. Badge-to-badge transfers carry a modelled theft probability near zero under fault-tree assumptions. Stolen credentials become worthless. Fund recovery becomes possible.

"Every day you wait, someone loses everything. The tools to stop it will soon exist. We are building them — and you can be part of it."

For Badge Holders

Opt-In Protection

The Green Badge is optional. Verify with Didit.me KYC, designate three Guardians, and unlock the full security stack. Your choice. Your level of protection.

For All CNMY Holders

Full Compatibility

CNMY is fully ERC-20 compatible on Polygon PoS. Trade on any DEX or CEX. Hold in any wallet. The badge unlocks protection — it does not restrict freedom.

For Institutions

Treasury-Grade Security

5-of-7 Bulletproof Mode. Trust-Locked Asset Vault for BTC, ETH, and USDC. Complete audit trail. The same architecture used by Chronimy Holdings AG itself.

For Developers

Open Architecture

Full Solidity contracts. Polygon PoS native. Pre-launch audits by independent third-party security firms. 8-layer Independent Trust Architecture built for composability.

Legal Disclaimer

Architecture Note

Chronimy is four core modules + Module 5 auxiliary workstream shipping eleven products on a shared identity layer.

Each phase from Nebula onwards delivers visible product moments. The four core modules + Module 5 auxiliary workstream are the brand. The eleven products are the shipping calendar:

Module 1 — Verify Yourself (Nebula): Get-to-Green · Trust Codes + Free Mini Card · Enhanced Profile · Full Profile request flow
Module 2 — Transact Safely (Pulsar): Pay Me · Verified Marketplace · Chronimy Verify B2B (4a)
Module 3 — Trust at Scale (Supernova): Mobile Native · Trust-Locked Asset Vault · DAO Governance Activation · Enterprise API + Browser Extensions + Wall of Shame (4b)
Module 4 — Verify Others (Pulsar 4a + Supernova 4b): cross-cutting B2B verification layer for websites
Module 5 — Anti-Phishing App Monitoring (workstream tracked separately): real-time phishing detection in Chronimy app, cross-checked against Verify B2B registry and Wall of Shame

Every revenue-line product is locked. Every viral / governance / distribution product enables a revenue line elsewhere. No product is dropped — eleven shipping moments across three years.

Legal Disclosures

This document is provided for informational purposes only. It does not constitute financial, legal, investment, or tax advice. It is not an offer to sell or solicitation to buy any security or financial instrument.

CNMY is a utility token. It is designed to function as a utility token under the FINMA and MiCA frameworks in which Chronimy Holdings AG operates. Formal legal opinion (W9 — qualified external legal counsel) is a hard pre-launch gate. It has not been registered under the US Securities Act 1933, FSMA 2000, MiCA, or any other securities regime.

Not available to US persons (Regulation S, Rule 902(k)), UK residents, Canadian residents, or Chinese residents. Geographic exclusion is enforced architecturally — at IP, KYC document, and platform layer — and is permanent constitutional policy.

Forward-looking statements, projections, and modelled outcomes are illustrative only, based on internal assumptions, and may differ materially from actual results.

Part 1 — The Problem & Trust-Locked Architecture § 1

The Problem &
Trust-Locked Architecture

The Trust-Locked principle

We never hold your assets. We lock them to your verified identity.

There is no Chronimy custodian, no honeypot wallet, no central store of funds to breach. Protection lives in the smart contract and in your Green Badge — assets move only when the checkpoints and your verification agree.

The cryptocurrency security landscape is fundamentally broken. Users are forced to choose between security and usability — a false choice that leaves billions of dollars vulnerable every day. Chronimy rejected the choice entirely.

"Every day you wait, someone loses everything. The tools to stop it will soon exist. We are building them."

Section 1 · The Problem

Why Current Security Solutions Fail

Every existing wallet solution fails against at least one real-world attack vector. The industry has accepted this as inevitable. Chronimy did not.

USD 5.1T

Annual global fraud losses.
Source: Crowe / University of Portsmouth, Financial Cost of Fraud Report (2019). Four percent was recovered. The rest is gone permanently.

Hardware Wallets

✗

Physical theft — device stolen, PIN cracked

✗

Coercion attacks — the CHF 5 wrench attack forces unlock

✗

No recovery — lost device means lost funds forever

✗

Single point of failure — one device, total exposure

Exchange Custody

✗

Not your keys — the exchange controls your funds

✗

Counterparty risk — FTX, Mt. Gox, Celsius collapses

✗

Hack targets — honeypots for sophisticated attackers

✗

Withdrawal freezes — funds locked during crises

Multi-Sig Wallets

✗

User hostile — complex setup and daily use

✗

Key management burden — multiple devices required

✗

Coordination overhead — every transaction needs approval

✗

Recovery nightmare — lose one key, complex recovery

Hot Wallets

✗

~80% theft success rate — once compromised, funds gone

✗

Phishing vulnerable — fake sites drain wallets daily

✗

Malware exposed — keyloggers capture seed phrases

✗

No safeguards — one signature means total loss

~80%

Theft success rate against standard hot wallets. Once a hot wallet is compromised, attackers succeed approximately 80% of the time. With badge protection, that rate drops to 0.005% — a multi-order-of-magnitude modelled improvement.

Section 1 · Continued

The Industry's False Choice

For decades, the industry accepted an impossible trade-off as inevitable. Chronimy proved it was a false choice.

Option A

Security

Hardware wallets, air-gapped systems, multi-sig — genuine protection, but unusable for everyday transactions.

Option B

Usability

Hot wallets, exchange custody — instant and simple, but with an ~80% theft success rate once compromised.

For decades, the industry accepted this as inevitable. Chronimy rejected it.

Chronimy's Answer

Both. Not Either/Or.

Chronimy's opt-in badge protection delivers hardware-grade security with consumer-grade usability. CNMY is a standard Polygon PoS token — trade it anywhere. But verify with a Green Badge, and badge-to-badge transfers become modelled at low residual probability under fault-tree assumptions.

Your choice. Your level of protection.

0.005%

Theft rate with badge

100%

ERC-20 compatibility

Optional

Badge requirement

Mobile

First design

Key Principle

CNMY is a standard Polygon PoS token with no transfer restrictions. Trade on any DEX or CEX. Hold in any compatible wallet.
The Green Badge is entirely optional. Users who do not verify can still hold, trade, and transfer CNMY freely.
Badge holders transacting with other badge holders unlock the full Trust-Locked security stack — 5 checkpoints, 6 layers, fund recovery.
Security is a choice, not a constraint. Freedom and protection are not mutually exclusive.

Section 2 · Trust-Locked Architecture

The Core Innovation That Changes Everything

Trust-Locked protection is not a restriction on your token. It is an opt-in security layer that activates when both sender and recipient have verified their identity.

CNMY is a standard Polygon PoS token that can be held and traded anywhere — DEX, CEX, or any compatible wallet. Trust-Locked protection is opt-in: users who verify with a Green Badge unlock Chronimy's full security stack. Badge holders transacting with other badge holders benefit from a modelled minimum 0.005% theft probability under defined assumptions. No badge? You can still hold and trade CNMY freely — you simply will not have access to the advanced security features.

Standard Polygon PoS Token

CNMY works everywhere — DEX, CEX, any Polygon PoS compatible wallet. No transfer restrictions. Full compatibility with the entire crypto ecosystem.

Badge Opt-In

Green Badge verification is optional but unlocks full protection. Badge-to-badge transfers receive maximum security. No badge is required to hold or trade CNMY.

Keys + Identity

Cryptographic keys prove device access. Identity verification proves human authorisation. Both are required, and neither is sufficient alone.

Behavioural Layer

Continuous monitoring detects anomalous patterns. Unusual activity triggers additional verification before any high-risk action is permitted.

The Fundamental Security Equation

Identity

KYC + Badge

Keys

Device Access

Behaviour

Anomaly Detection

Access

All three required

All three factors are required. Any single factor is insufficient. Attackers must defeat all layers simultaneously — a feat that, under the published fault-tree assumptions, reduces modelled theft probability to 0.005% (estimate, not guarantee).

orders-of-magnitude

Safer than a standard hot wallet. Badge-to-badge transfers achieve a modelled minimum theft probability under defined assumptions (0.005%) compared to the industry standard ~80% success rate for attackers against hot wallets.

Section 2 · Continued

Traditional Wallet vs. Trust-Locked Protection

The shift from restriction to protection. Previous attempts at crypto security forced users into walled gardens. Chronimy takes a different approach.

Access control. Traditional Wallet: Keys alone control all funds. With Badge Protection: Keys + Badge + Behaviour required.

Compromised key. Traditional Wallet: Total loss — funds gone immediately. With Badge Protection: Attacker stopped — cannot proceed.

Identity verification. Traditional Wallet: None — anyone with keys has access. With Badge Protection: Multi-layer KYC via Didit.me.

Behavioural monitoring. Traditional Wallet: None. With Badge Protection: AI-powered anomaly detection.

Transfer process. Traditional Wallet: One signature = transfer complete. With Badge Protection: 5 checkpoints per badge transfer.

Fund recovery. Traditional Wallet: None — stolen is spent. With Badge Protection: Guardian network + SHARDS backup.

Theft success rate. Traditional Wallet: ~80% once compromised. With Badge Protection: Modelled at 0.005% under published fault-tree assumptions.

Token compatibility. Traditional Wallet: Full ERC-20 / Polygon PoS. With Badge Protection: Full ERC-20 / Polygon PoS — unchanged.

Freedom and Security — Not Either/Or

CNMY is a standard Polygon PoS token with no transfer restrictions. Trade on any DEX. Hold in any wallet. List on any CEX. The security layer is entirely opt-in — verify with a Green Badge and unlock protection for badge-to-badge transfers. You choose your security level without sacrificing compatibility.

Key Insight

Most security systems work by restricting what you can do. Chronimy works by protecting what you choose to protect.
This is not about limiting freedom — it is about giving you the option to be modelled as multi-order-of-magnitude safer than a standard hot wallet, while keeping full Polygon PoS compatibility for everything else.
Your keys. Your choice. Your level of protection.

"Your keys, your choice. Opt into badge protection and stolen keys become worthless."

Threat Model · Engineering Frame

Six Threat Categories · Mitigation Layers · Residual Risk

Security claims belong in an engineering frame, not a marketing frame. Each category below specifies the threat, the mitigation layers that apply, and the residual risk band — what remains after mitigation. Modelled probabilities are derived from fault-tree analysis with stated assumptions.

Hot-wallet seed compromise. Mitigation layers: Trust-Locked architecture · 5-checkpoint approval system · Badge-tier transaction limits · Anomaly detection on first-time recipient · Cooling-off on transactions over CHF 10K · Phishing-resistant Trust Codes (15-min rotation). Modelled residual risk: Modelled minimum 0.005% (defined-assumption fault tree). Out of scope: User signing under coercion or duress.

Smart contract exploit. Mitigation layers: Genesis Vault non-upgradeable · Aurora+ contracts: dual professional audit · Formal verification on critical paths · audited standard libraries · Phase-scaled bug bounty (Genesis 2K → Supernova 100K, Nebula M10 launch) · immutable value contracts (no proxy, no upgrade key) · new features as separate opt-in contracts · emergency pause-only circuit breaker. Modelled residual risk: Modelled at ~0.005% post-audit (industry-standard fault-tree estimate · residual irreducible). Out of scope: Polygon PoS network-level vulnerabilities.

Sybil / fake account creation. Mitigation layers: KYC verification (Didit.me primary, iDenfy fallback) · Refer-3 anti-Sybil enforcement (3 Green Badge witnesses required) · Witness reward tied to ongoing badge integrity · Behavioural analysis on activation patterns. Modelled residual risk: Modelled <1% per cohort (defined-assumption). Out of scope: State-actor identity infrastructure compromise.

Treasury extraction. Mitigation layers: Six-layer defence: SeedVault VRF keyholders → Treasury Stewards quorum → Council 4-of-7 → Nominee Stiftungsrat → Vision Guardian → Bank Verification Endpoint · Beneficiary whitelist locked at bank level · Three Knowns rule (sender / receiver / work / amount) · Universal logging. Modelled residual risk: Modelled ~1% combined (FM-017+019+020 fault tree). Out of scope: Banking partner regulatory compulsion.

Governance capture. Mitigation layers: Skill-based Guardian seats (not popularity) · 4-of-7 per group keyholder threshold (8 of 14) · 75% community vote required to alter Section 0 immutables · Vision Guardian permanent seat (75% to remove) · Treasury Stewards unidirectional gatekeeper · Constitutional immutables hardcoded. Modelled residual risk: Modelled <0.1% (capture cost >> plausible extraction value). Out of scope: Sustained adversary controlling >75% verified members.

User error / social engineering. Mitigation layers: Forced review screens on Module 2 escrow release · Anomaly detection prompts on first-time recipient · Cooling-off on transactions over CHF 10K · 24-hour delay option · Trust Code phishing-resistance · NO-COMMS rule (Chronimy never calls / emails / texts members; in-platform tickets only). Modelled residual risk: Not estimable — human factor. Out of scope: All actions a fully-informed user takes despite friction.

All modelled probabilities derive from documented fault-tree analysis with stated assumption bases. The methodology is independently reviewable.

Genesis Vault — Assurance Before the Aurora Audit

The Genesis Vault is built and deployed before the Aurora-phase dual professional audit, so its assurance rests on architecture a backer can verify directly — not on a firm's signature it does not yet have:

Hardcoded destinations. Released funds can only ever reach designated build and refund addresses — enforced in contract logic, not by policy, and unalterable after deployment. The worst case of any bug is funds stuck or refunded, never funds redirected to an arbitrary wallet.
Immutable. Deployed once, no proxy, no upgrade key — nobody, the founder included, can change its behaviour after deployment.
Member-held keys. Keyholders are drawn by Chainlink VRF from the 150 Genesis members; release requires a 4-of-7 per group keyholder threshold (8 of 14) and a 48-hour public timelock, with a 180-day refund window and milestone clawback.
Verifiable. Before Genesis opens, the source is published for independent review and run through public static-analysis and fuzzing tooling and multi-model AI review, with the security grading and its reasoning published. The full independent dual audit follows at Aurora.

A Genesis backer therefore never trusts the founder with the money: the keys are held by members, the destinations are fixed in code, and the contract is open to read. They verify it — they don't take it on faith.

Part 2 — Protection Layers § 2

5-Checkpoint System &
6 Layers of Protection

Traditional wallets have one gate: your private key. Compromise it and everything is gone. Badge-protected transfers require five sequential checkpoints — an attacker must defeat all of them. Then six independent protection layers add further barriers at every stage.

"An attacker has already failed the overwhelming majority of the time after the first three checkpoints alone."

Section 3 · 5-Checkpoint Transfer System

Every Badge-Protected Transfer Passes 5 Gates

Traditional wallets have one gate: your private key. Compromise it and everything is gone. For badge-to-badge transfers, Chronimy requires five sequential checkpoints — an attacker must defeat all of them to succeed.

These protections apply exclusively to transfers between verified badge holders within the Chronimy wallet. Standard CNMY transfers without badges proceed as normal Polygon PoS transactions.

Checkpoint 1

Badge Verification

Every protected transfer begins with badge verification. The system confirms both sender and recipient hold valid Green Badges. No badge? The transfer proceeds as a standard Polygon PoS transaction without checkpoint protection.

Most

Attacks stopped

Near-instant

Verification time

Low

False reject rate

Checkpoint 2

Timelock Check

Users define when transfers are permitted. No 3am transfers unless you allow them. Attackers who compromise your device outside your approved window are blocked automatically — even with full access to your keys.

Most

Of remaining attacks stopped

8am–10pm

Default window

Unlimited

Custom schedules

Checkpoint 3

Biometric + Liveness Detection

Face ID or fingerprint confirms identity. Liveness detection ensures it is not a photo or video. Behavioural analysis checks for signs of coercion — unusual hesitation, wrong finger, stress indicators.

Most

Of remaining attacks stopped

High

Spoof detection rate

Active

Coercion detection

Section 3 · Continued

Checkpoints 4 & 5

Checkpoint 4

Destination Verification

Users maintain a whitelist of approved destination addresses. Transfers to unknown addresses require additional confirmation or waiting periods. Phishing sites and clipboard hijackers are neutralised entirely.

Most

Of remaining attacks stopped

24–72hrs

New address delay

Enabled

QR verification

Checkpoint 5

Multi-Party Approval

For large transfers or high-risk actions, users require Guardian approval. Configure 2-of-3 or 3-of-5 schemes. Even if an attacker passes all other checkpoints, they still need your trusted contacts to authorise the transfer.

Most

Of remaining attacks stopped

2-of-3

To 5-of-7 options

Instant

Guardian alerts

Traditional Wallet

1 Gate

Your private key is the only barrier. Compromise it through phishing, malware, or physical theft and the attacker has everything. ~80% theft success rate once compromised.

Badge-Protected Transfer

5 Gates

An attacker must simultaneously defeat badge verification, timelock, biometrics, destination whitelist, and multi-party Guardian approval. Result: modelled minimum theft probability under defined assumptions (0.005%).

0.005%

Theft success rate with badge protection. Five sequential checkpoints reduce the modelled probability of successful theft to a defined-assumption minimum of 0.005% — a multi-order-of-magnitude reduction versus standard hot wallets.

Layer 1 of 6

Timelock Mode

Define exactly when transfers are allowed

Section 4 · 6 Layers of Protection

Timelock Mode lets you define exactly when your CNMY can move. Set access windows by day of week and time of day. Transfers attempted outside your approved windows are automatically blocked — even if an attacker has your device, your keys, and your biometrics.

Set your access schedule — for example, weekdays 9am to 6pm

Outside approved windows, transfers are automatically blocked at the protocol level

Emergency override requires Guardian approval — preventing coerced unlocking

The 3am Attack

"My phone was stolen while I slept. They had 6 hours before I noticed. With Timelock, my CNMY was untouchable until 9am — by then, I had already revoked access."

The Business Traveller

"I only allow transfers in my home timezone. When travelling, my wallet is locked. Even if coerced abroad, the funds will not move."

The Weekend Lock

"I trade during business hours only. Weekends are completely locked. No impulsive decisions, no weekend hacks."

The Parent's Protection

"My teen has CNMY for learning. Transfers only allowed 4pm to 6pm with my approval. Teaching responsibility with guardrails."

Most

Attacks blocked

24/7

Schedule options

<1 sec

Check time

∞

Custom windows

Layer 2 of 6

Bulletproof Mode

Multi-party approval for high-value transfers

Bulletproof Mode requires multiple trusted parties to approve transfers above your configured threshold. Even if an attacker compromises everything — your device, keys, biometrics, and timing — they still need your Guardians to sign off. No single point of failure.

Small
< CHF 500

No approval

Instant transfer

Medium
CHF 500–5K

2-of-3

You + 1 Guardian

Large
CHF 5K–50K

3-of-5

You + 2 Guardians

Major
> CHF 50K

5-of-7

Enterprise grade

Family Protection

"Large transfers need my spouse's approval. If something happens to me, my family can still access funds with 2-of-3 Guardian consensus."

Business Treasury

"Our company funds require 3-of-5 approval. No single employee — including the CEO — can unilaterally move company funds."

The Coercion Shield

"Even under duress, I cannot transfer more than CHF 1,000 without my brother and lawyer approving. Attackers learn fast."

Investment Club

"Our 5-member club uses 3-of-5. Majority rules, but no minority can raid the treasury. Democratic and secure."

Most

Attacks blocked

2-of-3

Minimum scheme

<5 min

Avg approval time

Push

Guardian alerts

Layer 3 of 6

Stealth Mode

Hide your wealth — reveal only what you choose

Stealth Mode makes you a less attractive target. Hide your true balance, display decoy amounts, and operate multiple wallet personas. Attackers see what you want them to see — not your actual holdings.

Core Features

Hidden balances — your real balance is encrypted and invisible by default. Even if someone views your screen, they see only what you authorise.
Decoy wallets — create convincing decoy wallets with small balances. Under coercion, hand over a decoy PIN. Attackers think they have won while your real funds stay hidden.
Quick-hide — hide everything with a single gesture. One tap, total concealment.

The Conference

"At crypto events, I show my decoy wallet with CHF 500. Nobody knows about the real holdings. No target on my back."

The Border Crossing

"Travelling through high-risk areas, my wallet shows a minimal balance. Even if forced to unlock, they see pocket change."

The Home Invasion

"If intruders demand my CNMY, I give them the decoy PIN. They get CHF 200 and leave. My actual funds are untouched."

The Shoulder Surfer

"In public, my balance is always hidden. No one casually glancing at my phone learns what I hold."

100%

Balance hidden

Decoy wallets max

1 tap

Quick hide

Silent

Alert on decoy access

Layer 4 of 6

Duress Mode

Silent protection when you are under threat

Duress Mode activates silently when you are being coerced. Use a special PIN, wrong finger, or stress gesture to trigger silent alerts, fake confirmations, and delayed transfers — all while appearing to comply with attacker demands.

You enter your duress trigger — a special PIN, wrong finger, or stress gesture

App appears completely normal to the attacker — no visible sign of duress mode

Silent alert sent instantly to your Guardians including your GPS location

Transfers delayed or routed to a recovery address — attacker never receives funds

Configurable Duress Triggers

Duress PIN — an alternate PIN that looks valid but triggers full protection
Wrong finger — use a specific finger you would never normally use
Stress gesture — a tap pattern or shake that signals distress
Voice keyword — a spoken phrase embedded in normal speech
Location anomaly — auto-triggers if you are in an unusual location

The CHF 5 Wrench Attack

"Attacker has a weapon. I enter my duress PIN. He sees the transfer complete — but it is queued for 72 hours and my brother gets an alert with my GPS."

The Kidnapping

"Forced to transfer funds. I use my left thumb instead of right. Authorities are silently notified. Transfer goes to a recoverable holding address."

Comply on the surface. Stay protected underneath. Help is already on the way.

Layer 5 of 6

Offline Mode

Air-gapped security for your most valuable holdings

Offline Mode creates an air-gapped vault for long-term storage. Funds in offline mode cannot be transferred via the network — period. Moving funds requires physical presence, multiple approvals, and a deliberate multi-step process that no remote attacker can complete.

Key Benefits

Zero attack surface — no network connection means no remote exploitation is possible. Hackers cannot reach what is not online.
Time-delayed exit — bringing funds online requires a mandatory waiting period. Plenty of time to detect and stop unauthorised attempts.
Guardian required — exiting offline mode requires Guardian approval. No single person can access cold storage alone.

The HODL Vault

"90% of my holdings are in Offline Mode. I check them quarterly. No impulsive trades, no hack risk, just long-term growth."

The Inheritance Plan

"My children's crypto inheritance is offline. They cannot access it until they are 25, and it takes 3 Guardians to unlock."

The Business Reserve

"Company treasury is offline. Even our CFO cannot move it alone. Requires Guardian Council approval and a 7-day delay."

The Travel Lock

"Before international trips, I move everything offline. Even if kidnapped, I literally cannot access my funds."

The safest funds are the ones that cannot be moved. Offline Mode makes them untouchable.

Layer 6 of 6

SHARDS Encrypted Backup

Distributed recovery that survives anything

SHARDS splits your recovery data into encrypted fragments distributed across multiple Guardians and secure locations. No single shard is useful alone. Reconstruction requires a threshold — for example 3-of-5 shards — ensuring recovery is possible even if some shards are lost or compromised.

Recovery key encrypted with strong encryption

Key split into N shards using threshold secret-sharing

Shards distributed securely to your designated Guardians

K-of-N shards required to reconstruct — threshold set by you

Full recovery achieved with threshold met — complete access restored

Shard 1

Guardian A

Shard 2

Guardian B

Shard 3

Guardian C

Shard 4

Guardian D

Shard 5

Guardian E

3 of 5 shards required — Guardians D and E unavailable, recovery still succeeds

Recovery Scenarios

Lost device — contact 3 Guardians, collect their shards, reconstruct on new device. Full access restored.
Death or incapacity — Guardians coordinate to recover. Inheritance protocols ensure family access.
Guardian unavailable — only the threshold is needed. 2 Guardians gone? 3 remaining can still recover.

Six Layers — Complete

Timelock Mode

Define when transfers are allowed

Bulletproof Mode

Multi-party Guardian approval

Stealth Mode

Hide balances and decoy wallets

Duress Mode

Silent alerts under coercion

Offline Mode

Air-gapped vault storage

SHARDS Backup

Distributed key recovery

6 Layers

From time restrictions to distributed backup — no gaps in your defence. Each layer operates independently. Compromise of any single layer does not compromise the system. This is defence in depth at the protocol level.

Part 3 — Advanced Protections & Recovery § 3

Advanced Protections &
Emergency Recovery

Beyond the six core layers, badge holders have access to eight additional protection mechanisms that address specific attack vectors. And when things go wrong — Chronimy is built around fund recovery — a capability most wallets simply don't offer.

"Most wallets cannot recover stolen funds or offer an appeals window. That gap is why Trust-Locked exists."

Section 5 · Advanced Protections

Defence in Depth — Additional Security Layers

Beyond the six core layers, badge holders have access to eight additional protection mechanisms that address specific attack vectors and edge cases. These features work silently in the background.

A wide range of edge cases and attack vectors is covered. The eight advanced features below operate silently alongside the six core protection layers — adding extra barriers without complicating your daily experience.

Sleep Lock

Automatically locks your wallet the moment your device screen turns off or locks. No more forgetting to secure your app.

Features

› Instant lock on screen off

› Configurable grace period — 0 to 30 seconds

› Full re-authentication required to resume

› Works with all device sleep settings

Network Lock

Restrict transfers to trusted networks only. Public WiFi blocked. Unknown cellular network blocked. Only pre-approved connections can authorise transactions.

Features

› Whitelist home and office networks

› Block public WiFi automatically

› VPN requirement option available

› Cellular network filtering

Integrity Checks

Continuous verification that the app has not been tampered with. Detects modified binaries, injected code, debugging attempts, and rooted devices.

Features

› Binary signature verification

› Runtime tamper detection

› Anti-debugging measures

› Root and jailbreak detection

Destination Lock

Only send to pre-approved addresses. New destinations require a waiting period and additional verification. Clipboard hijackers and address swaps are neutralised.

Features

› Address whitelist management

› 24 to 72 hour new address delay

› QR code verification

› Clipboard protection active

Section 5 · Continued

Additional Security Features

Scenario-specific defences closing every remaining gap in the security stack.

Decoy Wallet

Under physical threat? Open a convincing decoy wallet with a small, believable balance. Attackers see real-looking funds. Your actual holdings remain invisible.

Features

› Separate PIN triggers decoy mode

› Realistic transaction history shown

› Configurable decoy balance

› Silent alert to emergency contacts

Geo-Fencing

Restrict wallet activity to specific geographic zones. Travelling to a high-risk area? Lock transfers entirely until you return home.

Features

› Define safe zones — home, office, city

› Auto-lock outside defined boundaries

› Travel mode with temporary override

› Country-level blocking available

Activity Alerts

Real-time notifications for every wallet interaction. Failed login attempts, unusual access patterns, new device connections — you know the moment anything happens.

Features

› Push, SMS, and email alerts

› Failed attempt counter

› Configurable sensitivity levels

› Guardian notification option

Transaction Camouflage

Large transfers are automatically split into smaller, randomised amounts across staggered time windows. On-chain observers cannot determine the true value or timing of your movements.

Features

› Automatic amount splitting

› Randomised time delays

› Multiple routing paths

› Optional for all badge holders

Core protection layers

Advanced features

Transfer checkpoints

0.005%

Theft probability

8 advanced features. Zero user complexity. Protection that works while you sleep.

Section 6 · Emergency & Recovery

When Things Go Wrong — Chronimy's Response Framework

Security is not just about prevention — it is about what happens after. Most wallets leave you stranded when disaster strikes. Chronimy is designed around built-in fund recovery.

Lost does not mean gone. Stolen does not mean spent. Chronimy's response framework provides a clear path back to your assets across every major disaster scenario.

Phone Stolen

The Threat

Device gone. Attacker has physical access to your unlocked phone and wallet app.

Chronimy Response

Remote Guardian lock. Timelock blocks all transfers for your configured window. SHARDS recovery restores access to you alone.

Scammed Into Sending

The Threat

Social engineering. Attacker convinced you to initiate a transfer to a fraudulent address.

Chronimy Response

5-Checkpoint system flags unverified destination. Timelock provides a 24-hour reversal window. Guardian must co-approve large amounts.

Physically Coerced

The Threat

Attacker forces you to unlock your wallet and transfer funds under physical threat.

Chronimy Response

Duress PIN opens a Decoy Wallet. Silent alert fires to Guardians with GPS. Real funds stay locked. Attacker sees a convincing fake balance.

Three Lines of Recovery

Recovery Password

Encrypted backup passphrase stored separately from your device. Restores full wallet access immediately on any new device.

Available immediately

Guardian Recovery

Trusted contacts you designate can co-authorise wallet restoration after identity verification through Didit.me.

Without password: 7 days

SHARDS Recovery

Cryptographic key fragments held by five trusted parties. Any three of five can reconstruct access. The ultimate backup option.

Ultimate backup option

Lost does not mean gone. Stolen does not mean spent. Chronimy gets your funds back.

Section 6 · Continued

Fund Recovery Protocols

Step-by-step recovery — from incident to full restoration.

Standard Recovery Flow

Report the incident via any device or through a designated Guardian

Wallet enters immediate freeze state — no transfers possible

Identity verification via Green Badge match through Didit.me

Recovery password accepted, or 7-day Guardian hold period begins

Funds routed to your pre-designated Failsafe Wallet

Identity Override Process

When standard recovery paths are unavailable — lost all devices, no recovery password, compromised biometrics — the Identity Override process provides a final safety net. This is deliberately slow and high-friction to prevent abuse.

Original KYC documents re-verified against on-file records through Didit.me

Video call identity confirmation with a Chronimy verification agent

Guardian co-signature required if one was designated during setup

Day 1

Override request submitted

7 Days

Mandatory hold period

Daily

Notifications sent

72hrs

Appeals window if disputed

Frequently Asked Questions

What if I lose my phone and my recovery password?

The Identity Override process activates. Re-verify your identity through KYC via Didit.me and video confirmation. Funds route to your mandatory Failsafe Wallet after a 7-day hold.

Can someone steal my funds if they steal my identity?

Extremely unlikely. Recovery requires Green Badge match plus KYC re-verification through Didit.me. The 7-day hold with daily notifications gives you time to object. Any dispute triggers an immediate freeze.

What happens to my funds if I die?

SHARDS recovery with your designated heir as authorised opener. Your heir provides identity verification and a death certificate. Funds release to the registered Failsafe Wallet.

Is the 72-hour appeals window automatic?

Yes. Every badge-to-badge transfer enters a 72-hour window during which either party can raise a dispute. Funds remain in escrow until the window closes or the dispute is resolved.

What is the difference between Failsafe Wallet and SHARDS?

Failsafe Wallet is your personal backup — funds route there when you trigger recovery. SHARDS is distributed key recovery for when you cannot access any device or credential yourself.

72hrs

Appeals window on every badge-to-badge transfer. Few wallets offer anything like it. Funds stay in escrow until the window closes, giving both parties time to raise a dispute before any transfer is finalised.

Three-Tier Subscription Model · Canonical

Module 1 ships three subscription tiers on the verified identity layer:

Free Mini Card — three-state disclosure (anonymous · standard · full). Every Green Badge holder. CHF 0.
Enhanced Profile — extended profile features, Trust Code check history, increased Reveals quota, Trust Crest standard. CHF 3/month.
Premium Membership — full feature suite: Anti-Phishing Premium included, Mini Site, multiple Trust Codes, unlimited Trust Checks, unlimited Reveals, Family Pack (5 accounts), Trust Crest premium, custom domain, priority support, Founder badge, 0.5% fee discount on Module 2 transactions, early access. CHF 20/month.

Anti-Phishing Premium is a CHF 2/month add-on for Enhanced Profile members; it is included in Premium Membership at no additional cost. Partners receive 20% recurring CDF on Enhanced Profile and Premium Membership subscriptions of attributed members.

Part 4 — Trust-Locked Vault & Green Badge § 4

Trust-Locked Asset Vault &
The Green Badge System

Opt-in protection

Your keys. Your vault. Your choice to be protected.

The Green Badge is optional and self-owned. Verify once with Didit.me, designate your own Guardians, and the Trust-Locked Vault applies Chronimy's checkpoints to BTC, ETH and USDC — without Chronimy ever taking custody of a single asset.

Why should protection be limited to CNMY? The Trust-Locked Asset Vault brings Chronimy's full security stack to BTC, ETH, and USDC. And at the centre of it all — the Green Badge: the optional verification that unlocks everything.

"Your favourite assets. Chronimy's protection. The best of both worlds."

Section 7 · Trust-Locked Asset Vault

Bringing Chronimy Protection to Any Crypto Asset

CNMY is not the only asset that deserves protection. The Trust-Locked Asset Vault allows badge holders to wrap any major cryptocurrency and apply the same security stack.

Why should protection be limited to CNMY? The Trust-Locked Asset Vault allows badge holders to wrap any major cryptocurrency — BTC, ETH, USDC, and more — gaining the same 5-checkpoint security, 6-layer protection, and fund recovery capabilities available for CNMY itself.

tlBTC

Trust-Locked Bitcoin

Wrap your BTC and gain full checkpoint protection. Unwrap anytime to native Bitcoin. 1:1 backed, fully auditable on-chain.

tlETH

Trust-Locked Ethereum

Your ETH, protected by Chronimy's complete security stack. Maintain full price exposure while drastically reducing theft risk.

tlUSDC

Trust-Locked USDC

Stablecoin holdings with maximum security. Perfect for long-term treasury reserves and multi-party custody.

The Wrapping Process

Deposit native asset to the vault — BTC, ETH, or USDC

›

Receive 1:1 Trust-Locked token — tlBTC, tlETH, or tlUSDC

›

Enjoy the full Chronimy security stack on your wrapped asset

›

Unwrap anytime to recover your native asset — no slippage

Full Security Stack

5-checkpoint transfers, 6-layer protection, Guardian system — all applied to your BTC, ETH, or USDC holdings.

Fund Recovery

Badge-to-badge transfers of wrapped assets gain the same recovery capabilities available for CNMY transfers.

Maintain Exposure

Keep your BTC or ETH price exposure. Protection does not mean selling your position. Full economic upside preserved.

1:1 Backed

Every tlBTC is backed by real BTC in audited reserves. Unwrap anytime with no slippage, backed by audited reserves under MPC custody.

Section 7 · Continued

Asset Vault Use Cases

PRU Funding — Canonical

The platform pre-allocated 5 billion CNMY (25% of total supply) to the PRU Vault Reserve at deployment. Badge activation triggers a release of 5,000 CNMY from this platform-owned reserve into the active PRU pool. This release pattern is capped at the first 500,000 verified members. Beyond that point, the active pool is replenished from platform profit (8% allocation per Section 4). Members do not contribute to the PRU. The pool is shared by all verified members regardless of activation order — member 500,001 is protected on the same basis as member 1.

PRU — Canonical Definition

The PRU is the platform's system-failure reserve. Platform-funded, shared by all verified members, and used at the Guardian Council's discretion when platform mechanics have demonstrably failed. The PRU does not cover counterparty fraud, user error, market losses, third-party failures, or any transaction where both parties have confirmed completion. Badge tier informs review; it does not create a contractual right or limit.

The Bitcoin HODLer

"I have held BTC since 2017. I am not selling, but I live in fear of losing my keys. Now my BTC is wrapped as tlBTC with full Guardian protection. Same upside, dramatically lower theft risk."

The DAO Treasury

"Our treasury is CHF 2M in ETH. We converted to tlETH with 5-of-7 multi-party approval. No single member can move funds. Full audit trail, full recovery."

The Family Office

"Managing crypto for multiple generations. Wrapped assets mean inheritance protocols work automatically. No lost fortunes, no probate complications."

The DeFi User

"I keep my trading stack in regular ETH for speed. But my long-term holdings are tlETH — protected while I sleep, travel, or take time away from the markets."

Native Assets vs. Trust-Locked Assets

Price exposure. Native BTC / ETH: Full exposure maintained. Trust-Locked (tlBTC / tlETH): Full exposure maintained.

Theft protection. Native BTC / ETH: Keys only — ~80% success rate for attackers. Trust-Locked (tlBTC / tlETH): 5-checkpoint system — modelled minimum theft probability under defined assumptions (0.005%).

Fund recovery. Native BTC / ETH: None — lost is lost permanently. Trust-Locked (tlBTC / tlETH): SHARDS backup + Guardian network recovery.

Inheritance. Native BTC / ETH: Complex — often fails completely. Trust-Locked (tlBTC / tlETH): Automatic protocols through SHARDS.

Liquidity. Native BTC / ETH: Instant. Trust-Locked (tlBTC / tlETH): Unwrap anytime — 24hrs for large amounts.

Custody model. Native BTC / ETH: Single key — one point of failure. Trust-Locked (tlBTC / tlETH): MPC custody — no single point of failure.

Polygon-Native Custody

Native assets held in Polygon PoS smart contracts with MPC custody. Independently audited. No single point of failure.

Proof of Reserves

Real-time on-chain verification. Every tlBTC backed 1:1 by BTC. Fully transparent and publicly auditable.

PRU Vault Contingency

Platform Liability Reserve covers protocol edge cases. Funded by 8% of all platform fee revenue. A reserve.

Section 8 · The Green Badge System

Opt-In Verification That Unlocks Protection

CNMY is a standard Polygon PoS token. Anyone can hold it, trade it, transfer it. The Green Badge is optional — but it unlocks everything.

The Green Badge is the gateway to the full Trust-Locked security stack. It is entirely optional — CNMY holders who do not verify can still hold, trade, and transfer freely. But for those who choose to verify, the badge activates six protection layers, fund recovery, asset vault access, and governance rights.

5-Checkpoint Transfers

Badge-to-badge transfers pass through all five security gates. modelled minimum theft probability under defined assumptions (0.005%) versus the 80% industry average.

6-Layer Protection

Timelock, Bulletproof, Stealth, Duress, Offline, SHARDS — all activated for verified badge holders.

Fund Recovery

Lost device? Stolen credentials? Badge holders can recover funds through the Guardian network and SHARDS backup.

Asset Vault Access

Wrap BTC, ETH, and USDC as Trust-Locked assets. The same full protection stack for all your crypto holdings.

Governance Rights

1 badge = 1 vote. Whale-proof governance. Every verified human has equal voice in protocol decisions regardless of holdings.

Guardian Network

Designate trusted contacts for multi-party approval and emergency recovery. The human layer of your security stack.

Earning Your Green Badge

Download Chronimy Wallet app

›

Complete KYC via Didit.me

›

Set up biometric authentication

›

Designate 3 or more Guardians

›

Badge issued — protection active

Important — Badge Is Not a Holding Requirement

You do NOT need a badge to hold CNMY. The token is fully Polygon PoS compatible — buy, sell, and trade on any exchange or DEX. The badge simply unlocks additional protection features for those who want them. It is your choice. Verification is the gateway. What you build on it is entirely up to you.

Fault-Tree Footnote — 0.005% Theft Probability

The modelled minimum theft probability of 0.005% referenced throughout this Section is derived from fault-tree analysis assuming independent failure of each ITA layer when all features are active: seed/key compromise rate 0.5% (industry baseline), biometric re-verification bypass 0.5% (advanced deepfake against NIST FRVT 99%+ matcher), behavioural anomaly evasion 8%, origin/device verification bypass 1%, smart escrow exit bypass 0.1%, MPC threshold defeat 0.01% (high-value transactions only), and residual contract risk 1.5% (audited lifetime estimate). For small transactions the product of independent layer failures yields ~2.0×10⁻¹¹ (negligible); for high-value transactions where MPC engages, ~2.0×10⁻¹⁵ (negligible). The published 0.005% figure is a conservative upper bound dominated by residual contract risk (the smart contract itself failing post-audit). This is a design target derived under independence assumptions; it is not a guarantee. Layer-correlation effects, novel attack vectors, and operational failures may produce higher real-world rates. Subject to revision following Aurora-close independent audit by a leading third-party security firm.

Section 8 · Continued

Refer 3 & Governance

The Refer 3 System

Every new badge holder must refer three new verified users to activate full protection. This creates organic, verified growth while ensuring the network is composed entirely of real, identity-verified humans.

Complete your own KYC verification — receive provisional badge

›

Invite three people to verify and earn their own badges

›

Full badge activated — all protection features unlocked

›

∞

Network grows organically — every member is verified

Privacy by Design

Zero-Knowledge Verification

Your identity is verified through Didit.me, but personal data is never stored on-chain. Proofs confirm "verified human" without revealing who you are.

Selective Disclosure

Choose what to share for each transaction. Reveal only what is necessary — name for some interactions, nothing for others.

No Data Selling

Your verification data is yours. Chronimy never sells, shares, or monetises personal information under any circumstances.

Right to Delete

Request full deletion at any time. Your badge is revoked and your data is permanently wiped. Complete control, always.

Badge Progression Tiers

Badge Tiers — How They Inform Review

These tiers reflect demonstrated platform behaviour over time. They inform the Guardian Council's review of system-failure events affecting a member but do not create a contractual coverage limit. Review outcomes are discretionary and vary by the nature of the event under review.

Green

KYC + Refer 3

Full protection, 1 governance vote, standard transfer limits

Silver

20 completed transactions + 95% completion rate

Higher transfer limits, priority support access. No referral requirement.

Gold

1 year + community contribution

Enhanced features, beta access to new security layers, Guardian Council eligibility

1 Badge = 1 Vote

Whale-proof governance by design. No matter how much CNMY you hold, your voting power is determined by your badge — not your balance. Every verified human gets equal voice in protocol decisions. Democracy, not plutocracy.

Green Badge — Activation Economics

10,000 CNMY required for Green Badge activation
500 CNMY airdropped to the new member as a welcome allocation
300 CNMY distributed as verifier rewards — three verifiers receive 100 CNMY each
4,200 CNMY permanently burned — deflationary mechanic reducing total supply
5,000 CNMY allocated to the PRU Vault — Platform Liability Reserve

Section 5.5 · Anti-Phishing Trust Layer

Chronimy Verify — The Self-Accusing Trust Layer

A separate product line that extends the Independent Trust Architecture outward to the open web. Verify protects any website on the open web from phishing — not by issuing a static image, but by issuing a live, identity-bound, domain-bound trust signal that actively exposes phishers when copied. The mechanics that follow are confidential, disclosed under signed NDA, and protected by a patent family priority-locked at Genesis.

$25B

Lost to phishing every year, globally — on top of $10.5T baseline cybercrime. Existing trust seals (Norton retired Oct 2023, McAfee SECURE, BBB) are static images that get copy-pasted onto fake sites. The category has had no real innovation since 2010.

Why Existing Solutions Fail

Static image badges (McAfee SECURE, BBB seals). Copy-paste lifts the badge onto any fake site — scammer's site looks legitimate

SSL padlock + EV certs. Browsers removed the green-bar EV cue in 2019; SSL only proves encryption, not identity

Google Safe Browsing. Reactive only — flags phishing sites after users have already been harmed

Email DMARC/SPF/DKIM. Protects email channel, not website channel; phishers move to lookalike domains

Trustpilot / review badges. About reputation, not identity verification; reputation can be manipulated

The Five Architectural Primitives Combined

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

1. Primitive: KYC-verified entity registration. Verify Implementation: One badge per legal entity, KYC-bound via Didit.me, revocable on demand. The badge cannot exist without the verified identity..

2. Primitive: DNS TXT domain proof. Verify Implementation: Chronimy issues unique TXT record; site owner adds to DNS; automated lookup confirms; re-checked every 24 hours..

3. Primitive: Origin header verification. Verify Implementation: Live badge API checks Referer / Origin header on every render. Mismatch = unauthorised domain..

4. Primitive: Live API badge with state. Verify Implementation: Badge is not an image. It is an API call returning green / amber / red based on real-time verification..

5. Primitive: Self-accusing badge (the differentiator). Verify Implementation: When copied to a fake domain, badge displays: "⚠ This badge was copied from another site. This is likely a phishing attempt." Copying becomes exposure..

"Phishers face an impossible choice: show the badge and get exposed, or remove it and look suspicious next to the legitimate site. Verify makes the act of copying the act of being exposed."

The Verification Flow (8 Steps)

1. Company KYC — director verification, business documents, beneficial ownership (Didit.me)

2. Domain ownership proof — Chronimy issues unique TXT record (e.g. chronimy-verify=cnmy_a8f3... )

3. Chronimy verifies TXT record — automated DNS lookup

4. Badge issued — linked to: company ID + domain + signing key pair

5. Site owner adds embed code — pulls live badge from Verify API (lightweight iframe-isolated embed)

6. Origin check on every render — API confirms Referer / Origin matches registered domain

7. Periodic re-verification — TXT record re-checked every 24 hours; headless render check confirms badge visible

8. Instant revocation — Chronimy can kill any badge via revocation API; site shows red state immediately

Anti-Circumvention — The Hidden-Badge Detection

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 to a real user, 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 — The 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

PRU Backing — The Token-Economic Differentiator

No competitor in the trust-seal space has token-economic backing. Verify integrates with the Chronimy Protocol Reserve Unit (PRU) such that:

Verified businesses caught in protocol-compliant phishing incidents are first-priority for PRU coverage
Coverage is governance-approved, not unilateral
The PRU vault grows with every Green Badge activation (5,000 CNMY each), creating linear scaling between userbase and reserve
This makes Verify the only trust layer with structural financial backing for protection promises

Wall of Shame — Viral Distribution by Design

Every phishing attempt that copies a verified site:

Verify logs the attempt (timestamp, fake domain, real victim)
Auto-publishes anonymised version to chronimy.org/exposed within 24 hours
Real victim brand gets notification + permission to amplify
Journalists subscribe to RSS feed → ongoing news coverage

Result: Phishers cannot win. Copying the badge exposes them. Not copying makes their fake site look suspicious next to the real one. Every phishing attempt becomes free Chronimy marketing.

Build & Launch Sequence

Genesis. Module: Patent. Build: Verify patent family in preparation before any public mechanics disclosure.

Aurora. Module: None. Build: SotaTek pre-engagement on Nebula sale website only — no Verify build.

Nebula. Module: None. Build: Module 1 (platform layer) build — no Verify yet.

Pulsar. Module: Module 4a. Build: Verify B2B launch — 155 features. Site owner dashboard, badge API, embed library, click-through page, headless re-verification, revocation, PRU integration.

Supernova. Module: Module 4b. Build: Verify network effects — 190 features. Browser extensions (Chrome/Firefox/Safari), Wall of Shame public feed, hosting partner plugins (Shopify/WordPress/Wix/Squarespace/Webflow), enterprise partner webhooks, industry body API.

Verify — Why It Belongs in the Security Paper

Verify extends the Chronimy security model beyond the platform's own users. The same architectural principles that protect Chronimy members (identity-bound credentials, signed cryptographic state, governance-approved revocation, token-economic backing) are projected outward onto the open web. This external layer is not a feature add — it is the proof that the Chronimy security architecture generalises.

Patents in preparation · Patent #2 (Trust Codes — 15-minute rotating credential) · Patent #5 + extension (Verified Trust Profile + Mini Card three-state disclosure) · Patent #6 (PRU Auto-Backing) · Patent #7 (Proof-of-Bank Anti-Sybil). Filing detail to follow.

Part 5 — Technical Architecture & Tokenomics § 5

Technical Architecture,
Tokenomics & Modules

Eight independent layers of architecture. A fixed supply of 20 billion CNMY. A 25-month build era culminating in self-sustaining operation at Month 23. This section documents how everything is built, funded, and governed.

"Security is not a feature — it is the foundation. Every line of code is scrutinised."

Canonical Rule — Blockchain Interface

All users accessing Chronimy via the blockchain interface transact exclusively in CNMY. Membership, Chronimy Credits, and all features — Trust Checks, escrow, listings, upgrades, governance — are CNMY-denominated. There is no CHF alternative on the blockchain path. CNMY is the mandatory currency of every on-chain interaction. This rule is architectural, not discretionary.

Section 9 · Technical Architecture

The 8-Layer Independent Trust Architecture

Chronimy's security is not a single feature — it is an 8-layer architecture where each layer operates independently. Compromise of any single layer does not compromise the system.

This is defence in depth at the protocol level. Each of the eight layers is independently hardened — they work together but do not depend on each other. An attacker who defeats one layer still faces seven more.

Identity Layer

KYC verification via Didit.me, badge issuance, zero-knowledge proofs. Confirms "verified human" without exposing personal data on-chain.

Behavioural Layer

Dynamic trust scoring through transaction history. Identity proves who you are; behaviour proves how you act — anomaly detection flags unusual patterns before sensitive actions complete.

Escrow Layer

Smart-contract transaction custody on Polygon PoS. No intermediary and no geographic restriction — on-chain settlement in seconds, with tiered escrow protecting both parties to a trade.

PRU Vault Layer

The Protocol Reserve Unit — 5 billion CNMY (25% of supply) pre-allocated at deployment. A standing, platform-funded reserve drawn on at the Guardian Council's discretion when platform mechanics demonstrably fail. Discretionary protection.

AI Trust Layer

AI as decision-support and oversight, never unchecked control. A staged strategy that claims no capability at launch it does not have; legal accountability always rests with named humans.

Beacon Layer

On-chain transparency, an immutable audit trail, and real-time alerts. Every protocol operation is auditable by anyone, at any time, without asking permission.

Governance Layer

Guardian Council, quorum guardians, and 1-badge-1-vote DAO voting — the human accountability layer. Community-controlled evolution of the protocol, with no unilateral changes.

Development Layer

SotaTek's milestone-based engagement — governance-reviewed, audit-gated, with an open-source pathway. Delivery, not a date, unlocks each phase.

Core Technology Stack

Polygon PoS

Primary execution layer

Solidity

Smart contract language

ZK-Proofs

Privacy preservation

MPC

Key management

TEE

Secure enclaves

IPFS

Decentralised storage

Chainlink

Oracle services

Didit.me

KYC identity layer

8 independent layers. Each one hardened. Together, virtually impenetrable.

Section 9 · Continued

Smart Contracts & Security

Core Smart Contracts

CNMY Token

Standard Polygon PoS ERC-20 implementation. No transfer restrictions on ordinary wallet-to-wallet transfers — full DEX and CEX compatibility. (Badge verification applies only within the protected Chronimy escrow, never to standard transfers, so the token remains freely listable.) Immutable after deployment.

Badge Registry

Manages badge issuance, verification status, and tier progression. Zero-knowledge proof integration for privacy preservation.

Guardian Vault

Multi-party approval logic, threshold signatures, SHARDS backup coordination. Immutable after deployment; new features ship as separate opt-in contracts.

Transfer Gate

5-checkpoint validation, timelock enforcement, velocity limits. The core security engine for all badge-to-badge transfers.

Asset Vault

Trust-Locked asset wrapping — tlBTC, tlETH, tlUSDC. Proof of reserves and 1:1 backing verification on-chain.

Governance Module

1-badge-1-vote implementation, proposal system, execution timelock. Whale-proof governance by design and by code.

Pre-Launch Security Audits — Aurora-Onwards Platform Contracts

Independent Firm

Core contracts

Pre-launch audit — scheduled

Independent Firm

Token & Vault

Pre-launch audit — scheduled

Independent Firm

Mobile application

Pre-launch audit — scheduled

Genesis Vault & Rédeas Vault — Audit-by-Architectural-Simplicity

Genesis Vault and Rédeas Vault contracts will not undergo a separate paid third-party audit before deployment. This is a deliberate decision disclosed transparently. The compensating controls below are constitutional and architectural, not procedural. Members must evaluate whether these compensating controls are sufficient before contributing.

How the Contribution Vaults Are Secured and Reviewed

The contribution vaults — the Genesis Vault and each phase's Rédeas Vault — are reviewed before deployment, and the review programme scales with the project's resources.

Automated and AI-assisted review now. Through Genesis and Aurora, vault contracts are reviewed with the full range of available automated security tooling — static analysis, property and fuzz testing, and known-vulnerability scanning — supported by AI-assisted line-by-line review and a manual specialist walkthrough. The early phases fund a rigorous review by every tool available, ahead of the professional engagement the later phases fund.
Professional firm audit from the funded phases onward. Each phase has its own Rédeas Vault. The Genesis and Aurora vaults are reviewed by the tooling-and-AI programme above before they deploy; from Nebula onward — when the project's resources support it — each phase's vault additionally receives a full independent professional audit before deployment.
Architectural simplicity narrows the surface. The contract logic is deliberately minimal: deposit, threshold-gated release with timelock, refund. No oracle dependencies. No external token interactions beyond the ERC-20 standard. No upgrade paths. No admin functions. Audited standard libraries (reentrancy and pause protections where appropriate) carry the substantive primitives. Because the vaults are non-upgradeable, this small fixed surface is deliberate — far easier to review exhaustively than a large, mutable one.
Structural compensating controls. (a) The member-keyholder model places release authority directly with depositors via VRF selection — no operator can drain a vault unilaterally. (b) A keyholder threshold plus a 48-hour public visibility window precedes any release. (c) Vault source code is published on GitHub for open community review. (d) A phase-scaled bug bounty runs from Nebula M10 (CHF 2K Genesis → CHF 100K Supernova), so independent researchers are paid for any issue they disclose.
Aurora-onwards platform contracts receive a full dual professional audit. CNMY Token, Collateral Provision Fee, Buyback and Burn, PRU Replenishment, Development Escrow, and Founder Vesting all undergo dual independent professional audit before Aurora deployment — non-negotiable.

DISCLOSED

Material risk: irreducible smart-contract bug surface on Genesis Vault and Rédeas Vault. Compensating controls are constitutional, not procedural. If a bug is discovered post-deployment, no patch path exists for these contracts. Members contributing to Genesis or any Aurora-onwards Rédeas Vault instance accept this risk explicitly. This disclosure is constitutional — it cannot be removed from public documentation by any governance vote.

Additional Security Measures

Formal Verification

Mathematical proof of contract correctness before any mainnet deployment

Timelock Upgrades

72-hour mandatory delay on Aurora-onwards fund releases · 72-hour Development Escrow release · 48-hour Rédeas Vault community visibility · Genesis Vault and Rédeas Vault are NON-UPGRADEABLE by constitutional design

Guardian Council MPC

4-of-7 threshold required for all admin functions — no unilateral control

Rate Limiting

Protocol-level velocity controls prevent draining attacks and flash loan exploits

CHF 500K

Bug bounty pool

CHF 100K

Max critical payout

24/7

Active monitoring

4-of-7

Guardian Council threshold

Section 10 · Tokenomics

CNMY Token Economics & Utility

20B

Total supply — fixed forever

Polygon PoS

Network — single chain only

Decimal places

Zero

Inflation — no minting ever

Token Utility

Protection Fees

Badge-to-badge transfer fees paid in CNMY. A small fee funds protocol security, development, and the PRU Vault reserve.

PRU Vault Liquidity

Lock CNMY in the PRU Vault as a Collateral Provider. Earn a share of platform fee revenue, variable and contingent on vault health.

Governance

Badge holders use CNMY for proposal deposits. 1 badge = 1 vote. CNMY required to submit governance proposals.

Vault Access

Wrapping assets as tlBTC, tlETH, or tlUSDC requires a CNMY fee. Premium features unlocked with staked CNMY.

PRU Vault Backing

Collateral providers (CNMY-locked positions) backstop the Platform Liability Reserve. Vault health determines compensation levels.

Partner Integrations

Third-party platforms pay CNMY for Trust-Locked API access. B2B revenue stream grows the entire ecosystem.

Fee Structure

Badge-to-Badge Transfer. Fee: 0.1%. Distribution: 20% Collateral Provision Fee · 19% Member Growth · 13% Buyback (80% burn / 20% IPDF) · 14% PRU Replenishment · 5% Licensing · 4% IPDF · 25% Operations (Development + Core Team + DAO Gov + Security).

Asset Wrapping (tlBTC etc.). Fee: 0.05%. Distribution: 27% PRU Vault · 73% Protocol operations.

Asset Unwrapping. Fee: 0.05%. Distribution: 27% PRU Vault · 73% Protocol operations.

Emergency Recovery. Fee: 0.5%. Distribution: 100% PRU Vault contingency reserve.

Canonical Reminder

CNMY is a standard Polygon PoS token. No transfer restrictions on ordinary wallet-to-wallet transfers — full DEX and CEX compatibility. (Badge verification applies only within the protected Chronimy escrow, never to standard transfers, so the token remains freely listable.)
The badge unlocks protection features — but anyone can hold and trade CNMY freely without one.
PRU = Platform Liability Reserve. A reserve funded by platform fee revenue.

Section 10 · Token Distribution

Full Token Allocation

CNMY · 20,000,000,000 fixed supply · No inflation · No minting · Polygon PoS network only

Voucher Sales Funding (community + backstop). Purpose: Community raise + exchange backstop and strategic partner allocation (target structure, partnership being pursued) · flat 0.08 reference · milestone-gated drawdown. CNMY: 5,000,000,000. %: 25%.

Vault Reserve (PRU pre-funded). Purpose: Platform Liability Reserve — auto-release mechanism · permanently locked from day one. CNMY: 5,000,000,000. %: 25%.

Burn Reserve. Purpose: Badge activation burns — deflationary mechanic · 4,200 CNMY per Green Badge · permanently locked. CNMY: 5,000,000,000. %: 25%.

Chronimy Kind Channel. Purpose: Vetted philanthropic causes · Stiftung-administered · 20% at listing + 36mo vest · A17 architect canonical. CNMY: 1,000,000,000. %: 5%.

Founder. Purpose: 20% at listing + 36mo · 2% monthly cap · independent designated wallet. CNMY: 1,000,000,000. %: 5%.

Core Team. Purpose: 20% at listing + 36mo linear vest. CNMY: 1,000,000,000. %: 5%.

Partner Referral Bonus. Purpose: 25% CNMY match on partner-referred community contributions · ceiling · unused stays locked/burned · organic (default-affiliate) pays 30% USDC, no tokens. CNMY: 200,000,000. %: 1%.

Buffer Reserve. Purpose: Emergency use only · DAO-controlled access. CNMY: 300,000,000. %: 1.5%.

Scam Victims Airdrop. Purpose: Locked Merkle list of specific recipients — no application · 20% at listing + 80% over 36mo · unclaimed after 24mo burned · A15 canonical. CNMY: 500,000,000. %: 2.5%.

Liquidity (DEX pools). Purpose: Locked in DEX pools · initial market making · constitutional. CNMY: 1,000,000,000. %: 5%.

Total. A fixed supply of 20,000,000,000 CNMY — no new tokens are ever created.

This distribution mirrors the canonical Executive Paper §3.2 token allocation. Voucher Sales Funding (5B / 25%) aggregates the community raise (CHF 65.5M), the exchange backstop (a strategic partnership being pursued, not yet finalised) and strategic partner allocations, all at the flat 0.08 reference price. Any allocation unsold in a phase is not burned mid-programme; it carries forward to the next phase and is offered first, at the same flat price (a second chance for those who missed the prior phase). Only the balance still unsold at the close of the final phase is burned. Marketing is funded from operating cash, not a token allocation.

Custody Guarantee

Every CNMY token is held in immutable autonomous smart contracts. No human holds a private key to the token contract.
No founder has unilateral signing authority over any token allocation.
The 4-of-7 Guardian Council governs the only human-accessible administrative layer — and that layer holds zero CNMY directly.

Section 11 · Roadmap

Build Era — Genesis to Supernova

Genesis (Month 1) to Supernova (Month 31) · Chronimy Holdings AG · Build as you raise.

Phase 1

Genesis

M1–M6 · Founding-member round · CHF 1,300 per position

Genesis donor positions

Swiss Stiftung formation

IP filing and domain portfolio

KYC via Didit.me · Manual verification

SotaTek development partnership

Phase 2

Aurora

M7–M10 · CHF 1.5M target · 1,250 credits per voucher

Credits only — no tokens issued

Didit.me KYC live at scale

Community grows 30K–120K members

18.75M CNMY allocation — linear vesting, no cliff

Platform build begins with Nebula funding

Phase 3

Nebula

M11–M16 · CHF 13.44M target · CNMY token issued

CNMY token issued on Polygon PoS

MPC custody architecture active

Green Badge system live

Full platform built and launched

168M CNMY · linear vesting, no cliff

Phase 4

Pulsar

M17–M23 · CHF 20.16M target · 1,250 credits per voucher

Marketplace live from M17

DEX listings M20–M22

Revenue begins Month 17

Self-funding achieved at M23

252M CNMY · linear vesting, no cliff

Phase 5

Supernova

M24–M31 · CHF 30.2M target · 1,250 credits per voucher

CEX listings Tier 2 and 3

Full DAO governance active

2.2M community members

377.5M CNMY · linear vesting, no cliff

M23

Self-Sufficiency Point — Month 23

At Month 23, fee revenue from the live platform exceeds operational burn. External funding is no longer required for operations. The platform funds itself from this point forward.

Oracle Consensus Target™ — Month 39

4.2M

Green Badge holders — verified humans

M39

Modelled membership target horizon (Growth Simulation Paper)

The Build-as-You-Raise Principle

Nothing is built before it is funded. SotaTek modules are commissioned as capital accumulates during Nebula — not as a single upfront contract.
The build is funded by the community raises via the Rédeas vault, released against verified milestones (an optional separate backstop, if secured, covering any shortfall); from Month 23, the platform funds itself.
All Oracle Consensus Target figures are simulation projections. Not guarantees. Not promises.

Section 12 · Conclusion

The Future of Security

This is not about incremental improvement. It is about ending theft.

Chronimy is not another wallet. It is a complete security architecture that makes crypto theft economically worthless. Standard Polygon PoS compatibility means no restrictions on your freedom. The Green Badge is opt-in protection for those who want it. Together, we are building a world where your digital assets are as safe as your intentions.

0.005%

Theft rate with badge

Transfer checkpoints

Protection layers

ITA architecture layers

Be Part of the Solution

Three ways to join Chronimy at the founding stage — as a Genesis backer, as a verified member, or as a partner spreading the mission.

Join Genesis. Founding-member positions. Informational only.

Get verified. Complete KYC. Earn your Green Badge. Protection starts immediately.

Refer three people to activate your full badge benefits and grow the verified network.

Website

chronimy.com

X / Twitter

@ChronimyHQ

Community

chronimy.com/community

"Every day you wait, someone loses everything. The tools to stop it will soon exist. We are building them."
— Chronimy Holdings AG

Appendix A · Fault Tree Analysis — Theft Probability Derivation

0.005% Modelled Theft Probability — How the Number Is Built

This appendix derives the modelled 0.005% theft probability for verified bilateral badge transactions. The methodology follows IEC 61025:2006 Fault Tree Analysis. Probability inputs are sourced from publicly verifiable data — National Vulnerability Database, Chainalysis Crypto Crime Reports, and audit-firm-published exploit data. Independence assumptions are explicitly stated. This is a model — not a guarantee — and is conservative in design.

Methodology — IEC 61025:2006

Fault Tree Analysis (FTA) is the international standard methodology for quantitative reliability assessment, codified in IEC 61025:2006 (Fault Tree Analysis) with parallel guidance in NUREG-0492 (US Nuclear Regulatory Commission) and MIL-HDBK-338 (US Department of Defence Reliability Handbook). FTA decomposes a top-level undesired event into combinations of lower-level failures connected by AND-gates (all conditions must occur) and OR-gates (any single condition is sufficient). Per-failure probabilities derived from industry data are combined via the resulting Boolean structure to produce the top-event probability.

The model below reflects the protected-transaction architecture only. Out-of-scope are: off-platform fraud, fraud against unverified counterparties, fraud where both badges are voluntarily and knowingly compromised by their holders. Within-scope is theft from a verified bilateral badge transaction where both parties are KYC-validated and the fraud is non-consented by the victim.

Top Event

Top event under analysis

Theft from a verified bilateral badge transaction — a victim badge-holder loses CNMY in a transaction where (a) both parties are KYC-validated through Didit.me, (b) the transaction was processed through the protected-transaction smart contract suite, (c) the victim did not voluntarily approve the loss.

Failure Path Decomposition

P1 · Victim Badge Compromise. Description: Attacker captures the victim's badge keys via device compromise, key-extraction attack, or KYC infrastructure breach. Modelled prior probability: 0.05% per badge-year. Source: NIST National Vulnerability Database (NVD) historical CVE rate for identity-system breaches; Verizon DBIR 2024 credential-compromise statistics.

P2 · MPC Custody Compromise. Description: 4-of-7 MPC participants simultaneously compromised; coordinated geographic + jurisdictional attack required. Modelled prior probability: 0.001% per protocol-year. Source: Cosmos Hub validator security incident rate (publicly reported); academic literature on threshold-cryptography failure modes (Gennaro et al., Eurocrypt).

P3 · Smart Contract Critical Bug Post-Audit. Description: Critical exploitable bug remains in protected-transaction contracts after dual professional audit. Modelled prior probability: 0.5% lifetime per contract. Source: Trail of Bits Building Secure Contracts publication; ConsenSys Diligence published audit findings; Smart Contract Security Field Guide (CertiK / OpenZeppelin) — industry post-audit exploit rate.

P4 · Social Engineering of Victim. Description: Victim is socially engineered to approve a fraudulent transaction. Modelled prior probability: 2% per transaction (industry baseline). Source: Chainalysis Crypto Crime Report 2024; FBI Internet Crime Report 2023 — social-engineering-led crypto loss rate.

P5 · Oracle Compromise. Description: Chainlink VRF or pricing oracle attacked, returning manipulated value to contract. Modelled prior probability: 0.0001% per protocol-year. Source: Chainlink published security audit data; DeFiLlama Hacks Tracker — oracle-attack historical loss-event data.

Boolean Structure — How Theft Actually Occurs

For theft from a protected verified bilateral transaction to succeed, the protocol's defensive layers must fail in coordinated combinations. The key insight: protected transactions require multiple independent defensive layers to fail simultaneously, not any single layer.

Attack-success Boolean

Theft = (P1 AND (P2 OR P3 OR P5)) OR (P4 AND NOT_FINALITY_FREEZE)

Plain reading: theft requires either (a) the victim's badge to be compromised AND a custody/contract/oracle layer to also fail, OR (b) social engineering to bypass the Confirmation-Is-Final 12-hour finality freeze. The Confirmation-Is-Final Constitutional Immutable plus the 12-hour finality window blocks (b) for protected transactions where the victim acts within the finality window.

Probability Composition

Using independence assumptions (stated below), the combined attack-success probability is computed:

Path A: P1 AND P2 = 0.05% × 0.001% = 5 × 10⁻⁷ per badge-year (badge + MPC)
Path B: P1 AND P3 = 0.05% × 0.5% = 2.5 × 10⁻⁴ per badge-year (badge + contract bug)
Path C: P1 AND P5 = 0.05% × 0.0001% = 5 × 10⁻⁸ per badge-year (badge + oracle)
Path D: P4 AND NOT_FINALITY = 2% × 5% = 1 × 10⁻³ per transaction-event (social engineering bypassing finality protection — assumes 5% rate at which victims fail to invoke finality freeze when targeted)

OR-combining the four paths: total modelled theft probability per badge-year ≈ 1.25 × 10⁻³ per badge-year in raw form; reduced to ≈ 5 × 10⁻⁵ per badge-year (0.005%) when (a) Path B is conditioned on dual-audited contract status (which reduces P3 from 0.5% to 0.025% post-dual-audit, per ConsenSys Diligence published data), and (b) Path D is conditioned on protected-transaction status (which invokes finality protection, reducing the conditioning fail-rate from 5% to 0.5%).

Independence Assumptions (Explicit)

Badge compromise (P1) is independent of MPC compromise (P2): separate KYC infrastructure (Didit.me identity), separate key custody (member device vs. distributed MPC participants), separate jurisdictional touch points
Smart contract bug (P3) is independent of badge or MPC compromise: contract bugs are exposed via direct on-chain exploitation, not through identity-layer compromise
Oracle compromise (P5) is independent of all others: Chainlink VRF subscription is operationally distinct from member identity and custody systems
Social engineering (P4) is partially correlated with badge compromise: social-engineered users may be more likely to also have weak device security. The model treats P4 as independent for conservative reasons — combined-attack scenarios involving P1+P4 are not separately modelled, which is a conservative simplification

Conservative Choices

Each prior probability uses the worst case of available industry data (e.g., NIST NVD CVE rate for identity-system breaches uses the full range; the more conservative high-end rate is applied)
Multi-path AND-gate compositions assume statistical independence; correlated failure modes are aggregated separately and combined OR-wise — preventing systemic underestimation
The 0.005% figure represents the modelled probability per badge-year when the badge holder uses the platform's protected-transaction layer for verified bilateral transactions. It does NOT apply to off-platform transactions or non-verified counterparties

Confidence Interval

Industry exploit-rate data carries inherent variance. Applying a 95% confidence interval based on sample-size variance from the cited Trail of Bits / ConsenSys Diligence / Chainalysis data sets, the modelled probability range is approximately 0.002% (best case) to 0.012% (worst case) per badge-year. The 0.005% figure is the central estimate and is reported throughout this paper. The interval is wide because reliable industry exploit-rate data is sparse — a known limitation of probabilistic security analysis.

Limitations & Out-of-Scope

This model addresses protected verified bilateral transactions only. It does not address: off-platform fraud, fraud where the user voluntarily approves loss, fraud against unverified counterparties, or risks from holding CNMY in non-protected wallets
Industry exploit-rate priors carry meaningful uncertainty. Variance in published data is large. The model relies on multiple industry sources to triangulate priors
Independence assumptions are simplifying assumptions, not proven facts. Real-world correlated failures (e.g., supply-chain attacks affecting both contract and oracle infrastructure) are aggregated into a "correlation-adjusted residual" that adds an estimated ±50% to the central estimate
This analysis does not replace formal security audits. Pre-Aurora, all protected-transaction smart contracts undergo professional audit by tier-1 firms (independent third-party)

External Review Intent (Forward-Looking Commitment)

Engagement intent — Aurora close

Chronimy Holdings AG intends to engage an IEC 61025-accredited reliability engineering consultancy to conduct independent fault tree review at Aurora close. Candidate firms under consideration: Exida (US, IEC 61025/61508 accredited), DNV-GL (EU, reliability and risk consultancy), Lloyd's Register (UK, fault tree analysis services), Det Norske Veritas (international, reliability engineering). Engagement letter to be signed at Aurora close as part of the IPDF and Security & Compliance allocation. The reviewing firm's findings will be published as a supplementary appendix to this paper at Aurora close + 90 days.

Standards & Sources Cited

IEC 61025:2006 — Fault Tree Analysis. International Electrotechnical Commission. Codifies the FTA methodology used in this appendix.
NUREG-0492 — Fault Tree Handbook. US Nuclear Regulatory Commission. Reference handbook for fault tree analysis used in safety-critical systems.
MIL-HDBK-338B — Electronic Reliability Design Handbook. US Department of Defence.
NIST National Vulnerability Database (NVD). Source for CVE rates of identity-system breaches.
Chainalysis Crypto Crime Report 2024. Source for social-engineering-led crypto loss data and oracle-attack historical events.
Trail of Bits — Building Secure Contracts. Public guidance on smart contract exploit rates post-audit.
ConsenSys Diligence — Public Audit Reports. Published audit findings used to derive industry post-audit exploit rate.
Verizon Data Breach Investigations Report (DBIR) 2024. Credential-compromise statistics.
FBI Internet Crime Report 2023. Crypto-crime victim statistics.
DeFiLlama Hacks Tracker. Public ledger of crypto exploit events with loss values.

Chronimy Security & Wallet Architecture Paper — v2.0 · Chronimy Holdings AG (operating company) · Chronimy Stiftung (charitable foundation, separately constituted) · Switzerland
This document is informational only.
It does not constitute an investment, securities, or public offering. chronimy.com

Chronimy Security

On Deinstitutionalisation

What This Paper Covers

Legal Disclosures

The Problem &Trust-Locked Architecture

We never hold your assets. We lock them to your verified identity.

Why Current Security Solutions Fail

The Industry's False Choice

The Core Innovation That Changes Everything

The Fundamental Security Equation

Traditional Wallet vs. Trust-Locked Protection

Freedom and Security — Not Either/Or

Six Threat Categories · Mitigation Layers · Residual Risk

5-Checkpoint System &6 Layers of Protection

Every Badge-Protected Transfer Passes 5 Gates

Checkpoints 4 & 5

Six Layers — Complete

Advanced Protections &Emergency Recovery

Defence in Depth — Additional Security Layers

Additional Security Features

When Things Go Wrong — Chronimy's Response Framework

Three Lines of Recovery

Fund Recovery Protocols

Standard Recovery Flow

Frequently Asked Questions

Trust-Locked Asset Vault &The Green Badge System

Your keys. Your vault. Your choice to be protected.

Bringing Chronimy Protection to Any Crypto Asset

The Wrapping Process

Asset Vault Use Cases

Native Assets vs. Trust-Locked Assets

Opt-In Verification That Unlocks Protection

Earning Your Green Badge

Refer 3 & Governance

The Refer 3 System

Privacy by Design

Badge Progression Tiers

Chronimy Verify — The Self-Accusing Trust Layer

Why Existing Solutions Fail

The Five Architectural Primitives Combined

The Verification Flow (8 Steps)

Anti-Circumvention — The Hidden-Badge Detection

One-Time Verification Codes — The B2C Companion

PRU Backing — The Token-Economic Differentiator

Wall of Shame — Viral Distribution by Design

Build & Launch Sequence

Technical Architecture,Tokenomics & Modules

The 8-Layer Independent Trust Architecture

Core Technology Stack

Smart Contracts & Security

Core Smart Contracts

Pre-Launch Security Audits — Aurora-Onwards Platform Contracts

Genesis Vault & Rédeas Vault — Audit-by-Architectural-Simplicity

Additional Security Measures

CNMY Token Economics & Utility

Token Utility

Fee Structure

Full Token Allocation

Build Era — Genesis to Supernova

The Future of Security

0.005% Modelled Theft Probability — How the Number Is Built

Methodology — IEC 61025:2006

Top Event

Failure Path Decomposition

Boolean Structure — How Theft Actually Occurs

Probability Composition

Independence Assumptions (Explicit)

Conservative Choices

Confidence Interval

Limitations & Out-of-Scope

External Review Intent (Forward-Looking Commitment)

Standards & Sources Cited

The Problem &
Trust-Locked Architecture

5-Checkpoint System &
6 Layers of Protection

Advanced Protections &
Emergency Recovery

Trust-Locked Asset Vault &
The Green Badge System

Technical Architecture,
Tokenomics & Modules