The Executive Whitepaper sets out why Chronimy exists. This Governance Paper sets out how Chronimy is governed — because a non-extractive institution is not built on intention, it is built on structural constraint. Every rule in this document is a constraint that exists so Chronimy Holdings AG cannot drift from the people it was founded to serve. Bank drift. Regulator drift. The governance framework that follows is what prevents Chronimy from becoming the next institution its members need to be released from.
— The Architect, Chronimy Holdings AG · April 2026
Available globally including US persons. Fiat rails — regulated payment processors and Open Banking. No CNMY required. No securities implications. Trust verification, Green Badge, marketplace access.
Strictly prohibited for US Persons (Regulation S). Restricted to compliant non-US, non-retail-UK jurisdictions. CNMY governance, escrow, Network Participation Rewards, badge activation.
Paper 1. Title: Executive Whitepaper. Scope: Business model, tokenomics, fundraising, growth strategy.
Paper 2. Title: Architecture Paper. Scope: Technical specification — ITA, smart contracts, API.
Paper 3. Title: Security Paper. Scope: Threat modelling, wallet security, Trust-Locked architecture.
Paper 4 ←. Title: Governance & Compliance. Scope: Legal framework, governance architecture, regulatory compliance.
Paper 5. Title: Growth Journey Simulation. Scope: 25-month phase modelling, Oracle Consensus Target, projections.
Click Next Below to continue to Zone 2 — Legal & Regulatory Framework
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.
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:
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.
The Chronimy protocol enforces specific outcomes inside the system. It does not — and cannot — protect against every behaviour outside its scope.
The boundary between protected and not-protected is enforced by code, not policy. Members are responsible for understanding which side of that boundary their action sits on. The Protocol Reserve Unit (PRU) operates as a discretionary platform-funded reserve for system-failure events — not for user error or counterparty bad-faith.
The Chronimy Protocol Reserve Unit (PRU) Vault is a Platform Liability Reserve — a settlement finality protection mechanism. It creates no legally enforceable payment right; any payout is at the Guardian Council's discretion.
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.
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.
The PRU Vault is funded by 5,000 CNMY per Green Badge activation, sourced from the Burn Reserve allocation (5B CNMY canonical) as a bootstrapping mechanism for the first 500,000 Green Badges. After 500K members the bootstrap allocation is depleted exactly, and PRU replenishment transitions to the 14% PRU Replenishment allocation of the 10-Way Profit Split (profit → TWAP market-buy of CNMY → PRU vault when solvency <120%, until 150% restored). The PRU operates as a discretionary operational reserve governed by the Guardian Council under a 4-of-7 threshold requirement. No legally enforceable payment right exists. No policy document is issued. The PRU is the on-chain equivalent of a regulated clearing house operational reserve — funded to absorb platform-level failures, not transactional risk.
CNMY was assessed under the platform’s non-US framework and sits firmly in utility-token territory, as set out below.
CNMY is a utility token providing platform access, governance rights, and verification functions. It is offered exclusively outside the United States, to non-US persons, under Regulation S. Chronimy conducts no US securities offering, maintains no US footprint, and excludes US persons at every layer — KYC, geo-block, contractual representation, and VPN detection. Classification follows the platform's non-US framework: a MiCA "other crypto-asset" position in the EU/EEA and a FINMA utility-token position in Switzerland, set out in the sections that follow. A formal legal opinion is to be obtained pre-launch.
The United States applies extraterritorial securities law with the broadest jurisdictional reach of any regulatory regime globally. The SEC has brought enforcement actions against projects with no US incorporation, no US team, and no US office — purely on the basis that US persons purchased tokens. Chronimy's zero-US footprint is enforced at four independent layers simultaneously.
Chronimy operates at the intersection of two regulatory frameworks: the EU's Markets in Crypto-Assets Regulation (MiCA), which came into full force in December 2024, and the Swiss DLT Act, which has governed Swiss blockchain entities since February 2021. Both frameworks provide a utility token classification pathway that CNMY is designed to satisfy. Switzerland is the primary regulatory anchor — FINMA is the home regulator. EU/EEA Member-State engagement is structured around Art. 4 (utility token offering exemption, applied in Aurora) and Art. 6 (full crypto-asset white-paper regime, applied from Nebula onwards if utility-token threshold is exceeded).
Asset-Referenced Token (ART). Applies to CNMY?: No. Reasoning: CNMY is not pegged to any asset basket, currency, or commodity. Fixed supply, floating value..
E-Money Token (EMT). Applies to CNMY?: No. Reasoning: CNMY is not pegged to a single fiat currency. Not designed as a means of payment substitute..
Utility Token. Applies to CNMY?: Yes ✓. Reasoning: CNMY provides access to platform services. MiCA Art. 4 utility token offering exemption applies to Aurora phase at or near the €1M threshold; Art. 6 white-paper regime applies from Nebula onwards..
Under MiCA Art. 13, EU/EEA-resident retail backers have a 14-day cooling-off period from the moment of voucher purchase during which the contract may be unilaterally withdrawn without penalty. This applies to all voucher campaigns from Aurora onwards, regardless of whether the campaign uses Art. 4 (offering exemption) or Art. 6 (white-paper regime). The cooling-off right is constitutional and cannot be waived by terms-of-service agreement. Refunds during the cooling-off window are processed via the same on-chain Rédeas Vault refund architecture that governs phase-failure refunds — pro-rata return to backer wallet, no Chronimy Holdings AG discretionary approval required.
Under MiCA Art. 16, a crypto-asset white-paper notified to FINMA (the Swiss home regulator under the DLT Act + AMLA framework) is passportable across all EU/EEA Member States via ESMA notification. Chronimy's structural pairing — Chronimy Holdings AG operating company + Chronimy Stiftung charitable foundation, both Swiss-domiciled — establishes Switzerland as the home regulator for both MiCA passporting purposes (via the Swiss-EU equivalence framework) and Swiss DLT Act compliance. EU/EEA Member-State retail offerings will reference the FINMA-notified white-paper at each phase open from Nebula onwards.
The KYC pipeline uses Didit.me as primary provider and iDenfy as fallback — both regulated, GDPR-compliant KYC providers with global document coverage and liveness detection. Zero US jurisdictional footprint is enforced: US-issued documents are rejected at source. The Proof-of-Bank CHF 3 micro-transaction provides financial identity accountability as a secondary anti-Sybil layer — with Chronimy Credits of equivalent value returned, making the net cost to the user zero.
Tier 1 — Basic. Contribution Range: Up to CHF 1,000. Requirements: Government-issued ID · Proof of address · Email verification · Standard sanctions screening.
Tier 2 — Enhanced. Contribution Range: CHF 1,000 – CHF 25,000. Requirements: All Tier 1 requirements · Source of funds declaration · Video liveness check · Enhanced PEP/sanctions screening.
Tier 3 — Institutional. Contribution Range: CHF 25,000+. Requirements: All Tier 2 requirements · Source of funds documentation · Accredited investor verification · Manual compliance review.
Part 1 builds the complete legal and regulatory foundation for the Chronimy Protocol. It establishes the PRU Vault's discretionary-reserve classification with a
1.1. Title: PRU Vault. Key Finding: Platform Liability Reserve classification..
1.2. Title: PRU Legal Framework. Key Finding: Coverage tiers CHF 0–25,000. Five-stage claim process. Eligibility criteria to remain discretionary..
1.3. Title: Utility-Token Assessment. Key Finding: CNMY is firmly utility under four-element analysis. NPR highest-risk element. Formal legal opinion pre-launch — hard gate..
1.4. Title: Zero-US Footprint. Key Finding: Four independent exclusion layers. Regulation S compliant. CHF denomination. Permanent constitutional policy..
1.5. Title: MiCA & Swiss DLT Act. Key Finding: Utility token under MiCA Art. 4. Swiss DLT Act utility classification. FINMA filing pre-launch..
1.6. Title: KYC & AML Procedures. Key Finding: Didit.me primary · iDenfy fallback. Five-step activation. 7yr KYC / 10yr transaction retention. GDPR resolved via off-chain data architecture..
Click Next Below to continue to Zone 3 — Governance Architecture
The Architect is a constitutional role, not a permanent personal designation. The role coordinates the operational stack and holds Section 0 veto on constitutional immutables only. It carries zero treasury access — the 4-of-7 Guardian Council multisig system is independent. Vesting allocations flow to a designated wallet regardless of who holds the role.
Succession is operational: the role is transferred by transferring access credentials to the unified contributor interface. The current holder retains Founder status (IP creator, name on patents, vesting recipient) until full platform delivery. The Vision Guardian seat is permanent and constitutional from day one — it is not activated only on departure.
Guardian Council seats are skill-based, not popularity-based. Each seat carries a defined skill set Chronimy Holdings AG requires (custody, compliance, treasury verification, dispute review, technical, legal, governance). Candidates are ranked by the independent AI screen-AI scoring against the relevant skill profile before community election.
Guardian Council members may also serve in operational team roles where skills overlap. Chronimy Holdings AG explicitly recognises that the same individual may hold both a Council seat and an operational responsibility — skill is what Chronimy Holdings AG buys, not exclusivity. Conflict-of-interest is managed through universal logging (Brain Section 0.2): every Guardian action is publicly recorded.
Decision logging: every Council decision (proposals, votes, abstentions, recusals) is recorded in the universal log per Brain §0.2. The log is publicly readable, append-only, and cross-anchored to Polygon at periodic checkpoints. Members can verify any decision was made as documented.
Auto-escalation: if a release proposal does not reach the standard 4-of-7 per group keyholder threshold (8 of 14) within 14 days, the threshold TIGHTENS to 6-of-7 per group (12 of 14) (supermajority, member-protective) with an extended 7-day window. The bar gets HIGHER under uncertainty — never lower. If a group cannot reach its 4-of-7, dispute escalates to Tier 3 (Quorum Guardian) under the Dispute Resolution Ladder. Funds remain locked throughout; cannot be unilaterally released.
Member rotation: staggered 2-year terms — three seats rotate every year. Term-limited members may stand for re-election. Mid-term vacancies fill from next-ranked candidate of the most recent skill-matched election. If no candidate available, seat opens to community election within 30 days. Council operates with reduced membership (minimum 4-of-7 voting members for any action) until vacancy filled.
Split responsibilities: the 7 voting seats divide into two functional clusters — three seats hold milestone validation authority (Security & Custody · Technology & Protocol · Finance & Treasury) covering smart contract releases, development milestone attestation, and infrastructure approvals; four seats hold dispute arbitration / member protection authority (Legal & Compliance · Community & Trust · Ecosystem & Growth · Member Protection) covering dispute review under Tier 2 of the Resolution Ladder, conduct enforcement, and member-facing decisions. Vision Guardian is a separate constitutional seat outside the 7 voting seats — non-voting, permanent, omniscient read access via Brain across all clusters, recuse-on-self veto only on member-protection changes.
In practice, DAO participation rates have collapsed to levels that make most DAOs functionally oligarchic. Token-weighted voting rewards capital over participation, and the result is governance capture by whales and insiders — exactly the failure mode decentralisation was meant to prevent.
The Guardian Council's role is narrow and specific by constitutional design. They are keyholders and compliance checkers — not decision makers. The community decides. The contracts execute. The Guardian Council ensures nobody cheats between the two.
Vault Releases. Description: Hold MPC keys mechanically. Verify proof of work was delivered for prior milestone. Approve Schedule B release via threshold vote inside the interface.. Limit: Cannot release outside Schedule B under any circumstance.
Dispute Flags. Description: If SotaTek raises a dispute flag on a milestone, Guardian Council pauses release for 14 days and holds the pause. Does not arbitrate — named Swiss arbitrator does.. Limit: Pause only. Cannot resolve disputes unilaterally.
Constitutional Compliance. Description: If any action proposed inside the system appears to breach Brain Section 0 principles, Guardian Council flags it. Cannot veto — a flag triggers a community vote.. Limit: Flag only. Community votes. Guardian Council does not decide..
CEO Oversight. Description: Reviews CEO logged actions periodically. If CEO proposes something outside constitutional mandate, flags for community vote.. Limit: Review and flag only. Cannot remove CEO without community vote..
Guardian Council members work exclusively inside the Chronimy interface. Every deliberation, every vote, every communication relevant to a platform decision occurs inside the logged system. The internal message layer captures all Guardian threads. The Vision Guardian AI reads every message in real time. There is no Telegram group, no WhatsApp, no personal email exchange that carries any operational weight. If it did not happen inside the system, it did not happen.
Security & Custody. Type: Elected · Voting. Primary Domain: MPC ceremony oversight, contract security, audit coordination.
Legal & Compliance. Type: Elected · Voting. Primary Domain: Regulatory compliance, legal opinion review, jurisdiction monitoring.
Technology & Protocol. Type: Elected · Voting. Primary Domain: SotaTek deliverable review, upgrade approvals, API governance.
Community & Trust. Type: Elected · Voting. Primary Domain: Badge policy, KYC standards, dispute process oversight.
Finance & Treasury. Type: Elected · Voting. Primary Domain: compensation review request review, profit split oversight, Glass Treasury governance.
Ecosystem & Growth. Type: Elected · Voting. Primary Domain: Partner integrations, platform growth decisions, SDK governance.
Member Protection. Type: Elected · Voting. Primary Domain: Badge holder safeguards, fraud reporting oversight, refund architecture, member dispute escalation review.
The Guardian Council comprises seven voting seats — all community-elected, all skill-vetted, all subject to the same compensation cap and inactivity slashing rules. Vision Guardian is a separate constitutional seat outside the Council voting body — see Section 2.3.E (Vision Guardian — Permanent Constitutional Seat) for full canonical specification.
Guardian Council seats exist to protect contributor interests. They cannot be self-appointed, founder-appointed, or chosen by closed committee. Selection follows a four-phase public process: open application, AI-powered merit vetting, member vote on the independent AI screen-AI-whitelisted shortlist, and on-chain term commencement. The process is designed to be transparent, sybil-resistant, and skill-aligned across the seven voting domains.
The Chronimy AG operations team posts an open call on the official @ChronimyHQ X account at the start of each election cycle. The post specifies which seats are open, the skill profile required for each, and the application portal URL. Applications are open to anyone — there is no pre-existing badge requirement, no geographic restriction, and no industry credential prerequisite. Applicants submit through the application portal: a CV / professional history, a public statement explaining their interest in the role, social and professional links (LinkedIn, GitHub, X, public publications, regulatory licenses if applicable), and a candidate-attestation form acknowledging they have read the Brain (Section 0) and the Eleven Constitutional Immutables.
independent AI screening conducts deep web analysis of every applicant against the seat-specific skill profile and the Eleven Constitutional Immutables. The vetting examines: professional credentials, publication history, social / public-discourse alignment with mission, prior governance experience, regulatory standing (no enforcement actions, no sanctions, no reputational red flags), independence from conflicting interests, and skill-fit to the specific seat. the independent AI screen produces a public reasoning report for each applicant — published in full so applicants and members can verify the analysis. the independent AI screen then publishes a whitelist of the top-ranked merit-qualified candidates per seat, typically 3-7 candidates per seat.
The independent AI screen analysis is deliberately transparent: the analysis prompt, reasoning chain, and source materials examined are all published. Applicants who are not whitelisted may submit a written appeal within 7 days; appeals are reviewed by a 4-of-7 Guardian Council multisig (or, during the founding cycle when no incumbent Council exists, by Chronimy AG operations team transparently logged on-chain). The appeal mechanism prevents arbitrary AI dismissal while preserving the merit-based filter.
Once the whitelist is published, all active Green Badge holders may vote — one badge equals one vote per the constitutional governance principle. Voting is conducted via on-chain badge-attested ballot submitted through the Chronimy interface. Each member votes for the candidate they prefer per open seat. Voting opens for 14 days. Members can change their vote during the voting window but are limited to one active vote per seat at any time. Vote tallies are visible in real time to maintain transparency, but final selection occurs only at voting window close.
The candidate with the highest vote tally per seat wins. In the event of a tie at voting window close, a 48-hour run-off vote is held between the tied candidates. The winning candidate enters an 18-day onboarding period: identity confirmation (KYC at the Council level — names known to Chronimy AG and Stiftung director, public identity disclosed except where Vision Guardian-tier confidentiality is operationally justified), MPC ceremony participation for key share assignment, signed onboarding to the Council Charter, and access provisioning to the internal interface. Term commences day 60 of the election cycle. Initial term length is 2 years, with one consecutive re-election permitted (4-year cumulative cap), then a mandatory 1-term break before re-eligibility.
Chronimy operates predominantly via independent contractors rather than full-time employees — this is a deliberate operational choice that aligns flexibility, accountability, and cost discipline with the platform's revenue trajectory. Guardian Council members frequently possess skill sets directly applicable to operational delivery (development, legal, treasury, security, ecosystem), and the constitutional structure explicitly permits a Council member to also serve as a paid Chronimy contractor where their skills overlap with operational needs.
This dual-role pathway is governed by transparent conflict-of-interest controls: any contractor agreement between Chronimy AG and a sitting Guardian must be (a) publicly disclosed at signing, (b) approved by the remaining 6 Council members via 4-of-6 majority recusal vote (the affected Council member recuses from the decision), (c) priced at fair-market arm's-length rates documented in the contract, (d) bounded by maximum annual aggregate value (no single Council-contractor relationship may exceed CHF 500,000 per fiscal year). The Council member's compensation as a Council seat (token-only, vested) is fully separate from contractor compensation (cash + applicable token bonuses per contract terms). Both streams are publicly disclosed in the annual Glass Treasury report.
Chronimy runs two kinds of community competition: recognition and access awards during the Genesis and Aurora campaigns (Genesis seats, Aurora exclusive-window access, recognition awards), and ongoing high-value cash competitions funded from the 20% Competition Fund (real prizes such as Bitcoin and watches) that compound community reach in place of paid marketing. Both are skill competitions judged against criteria published before entries open — never lotteries or games of chance.
An independent AI acts as a third-party judge: it scores each entry against the published criteria, selects winners purely on merit, and publishes its reasoning for every result. All entries and scores are logged to the Glass Treasury, so each outcome is auditable rather than a black box. There are no insider-only awards, no founder-determined outcomes, and no opacity in selection logic.
Results are not left to the judge alone. Any entrant may appeal an outcome to the Guardian Council, which holds an explicit override where the published criteria were misapplied. High-value cash prizes (Bitcoin, watches and similar) are geo-screened before award, so no prize is paid into a jurisdiction where it would be unlawful. All competition prizes are cash drawn from the 20% Competition Fund; no CNMY token allocation funds, or is awarded by, any competition.
Important canonical clarification: Vision Guardian is a permanent constitutional seat outside the seven-voting Guardian Council. Vision Guardian holds no Council vote (the Council is 7 voting seats: Security & Custody, Legal & Compliance, Technology & Protocol, Community & Trust, Finance & Treasury, Ecosystem & Growth, Member Protection). Vision Guardian's authority is defensive-only: observe via AI-powered Brain access, alert via Beacon Layer publication, and recuse-on-self-bounded veto on proposals that would materially diminish member-protection guarantees of the Eleven Constitutional Immutables. Vision Guardian compensation is constitutionally CHF 0 (unpaid). Removal requires 75% DAO supermajority. Vision Guardian veto cannot extend to proposals about Vision Guardian role itself (recuse-on-self) — this prevents the role from becoming entrenched. The role is therefore a defensive constitutional sentinel, not a governance vetoer.
Member data is never exposed externally. The Vision Guardian's omniscient read access is a member-side constitutional role, held to protect members — it is never granted to any external party, partner, or investor. No external commercial party ever receives member personal data (PII). Any external oversight a strategic partner may hold is limited to aggregated metrics and the public Glass Treasury — both of which contain no personal data. This boundary is structural: it protects members' privacy and it protects partners from ever becoming a data controller of members' information.
The Chronimy Intelligence Layer ingests every consequential action across the platform into a single immutable audit log. Nothing is excluded. Nothing is summarised before storage. The raw record is permanent.
Guardian Council threads. Source: Internal message layer. Visibility: All Guardians + Vision Guardian.
CEO communications. Source: Internal message layer + CEO interface. Visibility: Guardian Council + Vision Guardian.
All @chronimy.com email. Source: Self-hosted mail routed to interface. Visibility: Role holder + Vision Guardian.
Every vote. Source: On-chain + interface log. Visibility: All contributors + public.
SotaTek deliveries. Source: Interface milestone submissions. Visibility: Guardian Council + Vision Guardian + contributors.
Every fund movement. Source: Smart contract + Schedule B log. Visibility: All contributors + public Glass Treasury.
Partner communications. Source: Internal partner channel. Visibility: CEO + Vision Guardian.
AI recommendations. Source: Oracle Engine output log. Visibility: All contributors + public.
Every role holder is issued a @chronimy.com email address. Inbound email from the outside world arrives inside the platform. It is read inside the interface. It is replied to from inside the interface. The sender receives a reply from @chronimy.com and is unaware the response came from a locked internal system. No external mail client ever touches a Chronimy role holder's professional communications.
The system has no forward function. No CC or BCC to external addresses. No copy of message content to external systems. Every message in and every reply out is logged permanently with timestamp, sender, recipient, and full content. The Vision Guardian reads every thread in real time.
ceo@chronimy.com. Role: CEO. Behaviour: Inbound from outside. Read and replied to inside only..
guardian@chronimy.com. Role: Guardian Council shared. Behaviour: All Guardians see it. Reply from inside..
In-platform support tickets. Role: Member-facing. Behaviour: All member-to-Chronimy contact routes through the in-app ticket system inside the interface — no external email..
partners@chronimy.com. Role: Partner inquiries. Behaviour: CEO + Vision Guardian see it..
compliance@chronimy.com. Role: Legal / regulatory. Behaviour: Compliance role + Vision Guardian..
Every week the Vision Guardian AI produces a plain-language digest published to all Green Badge holders. It covers: votes taken and outcomes, fund movements, SotaTek milestone status, key communications summary, constitutional health score trended week on week, and any flags raised. If anything classified as urgent is detected — a fund movement outside Schedule B, communication suggesting an off-platform decision, repeated AI recommendation overrides on the same question — the alert reaches the Vision Guardian dashboard immediately and does not wait for the weekly digest.
MakerDAO deliberates on Discord. Compound's core team operates outside its governance system. Uniswap Labs has no logging obligation to token holders. Every DAO that has ever been captured was captured in the gap between what the system showed and what the team actually did. Chronimy has no gap. The Intelligence Layer is why.
The Oracle Engine is Chronimy's governance intelligence layer — a three-AI consensus system that analyses every governance proposal before human deliberation begins. It uses the independent AI screen, Claude, and GPT in parallel, requiring consensus across all three before producing a recommendation. It never makes decisions and cannot bind Guardian Council votes.
A fee change that improves overall efficiency but harms 28% of Casual Traders disproportionately will be flagged before the Guardian Council sees it. The system surfaces second-order effects that pure majority-vote analysis misses. The 1,000 personas are the silent majority made audible — governance that considers everyone before the vote.
Casual Trader. % Pool: 28%. Badge Tier: Green. Primary Governance Concern: Fee-sensitive, low engagement, reacts to PRU coverage changes.
Active Merchant. % Pool: 22%. Badge Tier: Silver–Gold. Primary Governance Concern: High participation, escrow fee changes are primary concern.
Long-Term Holder. % Pool: 18%. Badge Tier: Green–Silver. Primary Governance Concern: Conservative, opposes burn rate changes, values supply stability.
Governance Activist. % Pool: 12%. Badge Tier: Gold. Primary Governance Concern: Maximum participation, platform-improvement focused, proposes changes.
Dispute-Prone User. % Pool: 8%. Badge Tier: Red–Green. Primary Governance Concern: Sensitive to dispute resolution rules and compensation review request policy changes.
Institutional User. % Pool: 5%. Badge Tier: Gold. Primary Governance Concern: API-integrated, compliance-focused, batch operation requirements.
Passive Member. % Pool: 7%. Badge Tier: Red. Primary Governance Concern: Rarely votes, represents the silent majority, influenced by outcome quality.
Click Next Below to continue to Zone 4 — Proposals, Decentralization, Burns & Competitive Analysis
When a Module 2 transaction is disputed, the protocol routes the dispute through a four-tier ladder. Each tier has defined evidence types, resolution paths, and escalation triggers. The ladder exists because most marketplaces fail at dispute resolution, not at payments.
Tier 1 — Auto. Resolution path: Smart contract auto-resolves objective milestones (delivery confirmed on-chain, deadline expired, both parties signed completion).. Evidence considered: On-chain transaction state · timestamp · cryptographic signatures.. Escalation trigger: Either party flags the auto-resolution as contested within 72 hours..
Tier 2 — Council Review. Resolution path: Guardian Council dispute-arbitration seats (selected from the 7 voting seats) review the contested case. Majority vote of the 3 resolves.. Evidence considered: On-chain data · submitted files · in-platform communication logs · transaction metadata.. Escalation trigger: Council split decision OR transaction value > CHF 5,000 OR either party formally requests escalation within 14 days..
Tier 3 — Quorum Guardian. Resolution path: Quorum Guardian pool (21–49 Gold Badge+ members, randomised selection of 7 per case) review under Module 3 governance once instantiated. Decision by 5-of-7 majority.. Evidence considered: All Tier 1+2 evidence · Quorum Guardian-requested clarifications · expert witness submissions where applicable.. Escalation trigger: Either party files for Tier 4 within 30 days, citing procedural failure or material new evidence..
Tier 4 — Swiss Arbitrator. Resolution path: Named Swiss arbitrator (Chronimy-retained, conflict-free) under Swiss Rules of International Arbitration.. Evidence considered: All prior tier evidence · written submissions · oral hearing if requested.. Escalation trigger: Final and binding. Tier 4 is the appellate end-point..
Where work is partially delivered or quality is contested but partially acceptable, the resolving tier may award partial release (e.g., 60/40 split). Full forfeiture of escrow is reserved for clear-cut breach.
A party found to have filed a frivolous or bad-faith dispute (per the resolving tier's documented finding) incurs: (a) badge-tier downgrade (Gold → Silver, Silver → Green); (b) dispute fee deducted from PRU vault contribution; (c) public log entry under Brain §0.2.
Module 1 ships three subscription tiers on the verified identity layer:
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.
Proposals are categorised by impact level — each category carries different submission requirements, quorum thresholds, voting duration, and approval mechanics. All proposals are assessed by the Oracle Engine before going to vote. All outcomes are permanently recorded on the Beacon Layer.
Operational. Quorum: To be set at Chronimy constitution*. Duration: 5 days. Approval: Simple majority. Scope: Fee adjustments within ranges, UI changes, non-structural updates.
Structural. Quorum: To be set at Chronimy constitution*. Duration: 14 days. Approval: Supermajority. Scope: Badge thresholds, governance parameters, PRU coverage limits.
Constitutional. Quorum: To be set at Chronimy constitution*. Duration: 30 days. Approval: Unanimous GC + supermajority. Scope: Changes to governance rules, Council structure, immutables.
Emergency. Quorum: GC only. Duration: Immediate. Approval: 4-of-7 GC. Scope: Active security threat, platform integrity risk, automatic expiry.
Each phase transition is gated by both a time-based AND a metric-based trigger — whichever happens later determines transition. This dual-track design prevents premature decentralization (community not ready) AND prevents indefinite founder-control (time-based forcing function).
Aurora → Nebula governance. Time Gate: End of Aurora (M10). Metric Gate (whichever later): Genesis members all activated AND first 5,000 Green Badges issued AND first Guardian Council whitelist published via independent AI screening vetting. Authorisation: Founder + Genesis consensus >75%.
Nebula → Pulsar governance. Time Gate: End of Nebula (M16). Metric Gate (whichever later): 50,000+ Green Badges active AND first complete Guardian Council election cycle completed AND DAO has voted on at least 3 protocol proposals successfully. Authorisation: Guardian Council 4-of-7 + DAO supermajority >66%.
Pulsar → Supernova full DAO. Time Gate: End of Pulsar (M23). Metric Gate (whichever later): 1,000,000+ Green Badges active AND treasury solvency >150% AND no open emergency-tier proposals AND open-source handover milestones complete (smart contracts published, dev tooling open, documentation public). Authorisation: Guardian Council 6-of-7 supermajority + DAO supermajority >75% + Vision Guardian non-veto.
Mature DAO operation. Time Gate: Supernova close + 12 months. Metric Gate (whichever later): 4M+ Green Badges OR CHF 100M+ annual profit (either threshold). Authorisation: Standard DAO governance only — founder retains Vision Guardian constitutional seat (unpaid, defensive-only).
Failure-mode handling: if a phase metric gate is not met by the time gate, transition is delayed by 6-month increments with public reasoning published per increment. If 3 consecutive 6-month delays occur (i.e., 18 months past time gate), the founder + Vision Guardian must commission an external governance review (an independent specialist firm) and publish findings. This prevents indefinite delay through founder discretion alone.
Regardless of governance phase, these eleven protections cannot be removed by any vote, governance proposal, smart-contract upgrade, Guardian Council action, DAO supermajority, or external coercion:
CNMY Token.Chronimy uses four canonical deflationary burn mechanisms — badge activation, transaction fees, revenue-funded buyback-and-burn, and time-decay. The Fifth Gate is governance friction itself, but it is fundamentally different: it does not burn CNMY from proposers. Instead, it stakes the proposer's badge — making it non-transferable for a period calibrated to proposal severity. This serves two purposes: it prevents spam proposals (each consumes the proposer's badge mobility, and each proposer has only one badge per identity), and it creates real cost without ever taxing holders for participation. Per canonical principle: burns happen only from profit allocations, never from individual holders for governance participation.
Every major DeFi governance system uses legacy token-weighted voting. Every major DeFi governance system has a documented participation crisis. This is not coincidence — it is the predictable consequence of aligning governance power with financial speculation rather than verified participation.
Chronimy ✓. Voting Model: 1 Badge = 1 Vote. Participation: Incentivised. AI Layer: Triple-AI Oracle. Core Failure Mode: KYC provider dependency — mitigated by Didit.me + iDenfy dual-provider architecture.
Uniswap. Voting Model: Token weight. Participation: 3–5%. AI Layer: None. Core Failure Mode: Whale dominance, persistent low participation across all proposal types.
MakerDAO. Voting Model: Token weight. Participation: <20 voters. AI Layer: None. Core Failure Mode: Critical risk parameters changed by tiny insider group — de facto oligarchy.
Compound. Voting Model: Token weight. Participation: 0.4%. AI Layer: None. Core Failure Mode: Vast majority permanently disengaged — insiders govern by default.
Aragon. Voting Model: Configurable. Participation: Variable. AI Layer: None. Core Failure Mode: Framework only — no platform, no community, no trust infrastructure.
Optimism. Voting Model: Bicameral. Participation: Improving. AI Layer: None. Core Failure Mode: Dual-house model — still token-weighted at base layer.
Every competitor governs tokens with tokens. Chronimy governs a trust protocol with verified humans. The alignment is architectural: people who use the platform to conduct real transactions govern it — not speculators holding tokens for price appreciation.
Part 2 builds the governance architecture that separates Chronimy from every existing DeFi governance model. It demonstrates why legacy token-weighted voting fails with real participation data, proposes a three-layer AI/Human/Council architecture that structurally prevents plutocratic capture, and establishes governance badge-staking as the Fifth Gate (a non-deflationary friction mechanism — burns happen only from profit, never from holders for governance participation).
2.1. Title: Why DAOs Fail. Key Finding: Uniswap 3–5%, MakerDAO <20 voters, Compound 0.4%. Token weighting is the root cause of every participation crisis..
2.2. Title: Three-Layer Architecture. Key Finding: AI (Oracle) + Human (badge holders) + Council. Floor / Upgrade / Exit design principle. No single layer acts unilaterally..
2.3. Title: Guardian Council. Key Finding: 7 seats · 4-of-7 · GREEN to EMERGENCY tiers · 90-day auto-sunset · Vision Guardian unpaid watchdog · CHF 500K cap compensation..
2.4. Title: Oracle Engine. Key Finding: the independent AI screen + Claude + GPT triple-AI consensus. Advisory only — zero binding decisions ever made..
2.5. Title: 1,000 Persona System. Key Finding: Seven stakeholder archetypes. Oracle stress-tests proposals against all 1,000 simultaneously before any vote..
2.6. Title: Proposal System. Key Finding: 4 categories · 5 to 30 day duration · Oracle pre-analysis mandatory · Beacon Layer anchoring permanent..
2.7. Title: Progressive Decentralization. Key Finding: Aurora to Supernova. Full DAO at Supernova. Six constitutional immutables survive all phases including full decentralization..
2.8. Title: Governance Badge Staking. Key Finding: 7/21/60/30-day badge non-transferability tiers. Fifth Gate. Zero CNMY burned — badges staked instead. Aligns with canonical: burns only from profit, never from holders for governance participation..
2.9. Title: Competitive Analysis. Key Finding: Chronimy is an identity-anchored non-profit governance model with AI-assisted consensus surfacing..
Click Next Below to continue to Zone 5 — Custody & Treasury
The Architect has zero treasury access. Every fund movement requires the 4-of-7 per group keyholder threshold (8 of 14), with keyholders selected by Chainlink VRF from contributors of the relevant phase. The Architect cannot propose a release without a community-passed poll. The Architect cannot sign as a keyholder. The Architect cannot override the timelock. There is no admin function in any treasury contract that grants the Architect unilateral authority — verifiable on Polygonscan at deployment.
Founder vesting allocations flow to a designated wallet through autonomous contracts. The wallet destination is hardcoded at deployment and cannot be changed — not by the Architect, not by Guardian Council, not by community vote. Vesting continues regardless of whether the Architect role is active, vacant, or held by a successor.
The Treasury Stewards are a community-elected, all-phase oversight body whose sole purpose is to protect the community’s raised funds. They hold the Treasury→Operations gatekeeper role and serve as the standing money-movement watchdog. They are an authoriser and overseer — never a spender, and they never hold MPC signing keys.
Composition. Nine seats — one reserved for each of the five fundraising phases (Genesis through Supernova) so every raise is represented, plus four at-large. Elected one-verified-member-one-vote (identity-verified, so no token-weight capture). Staggered two-year terms; any Steward removable by 75% community vote.
Powers. (1) Co-authorise the Treasury→Operations valve; (2) audit the Glass Treasury and publish findings; (3) veto any release during its timelock; (4) petition an emergency freeze. The Stewards cannot initiate spending, set their own budget, hold signing keys, or override the DAO. A failure-to-engage backstop ensures Steward inaction can never trap funds in a vault (see Failure Mode Provisions).
Security-first means slow by default. Every movement is slow-lane — DAO vote + 6-of-9 Steward supermajority + 7-day timelock + veto window — except recurring operating costs within the DAO-ratified operating budget, which use the fast lane: management request + Guardian Council 4-of-7 + 5-of-9 Steward co-signature + 48-hour timelock. Anything outside the ratified operating budget, or any strategic or capital deployment, is slow-lane.
Separation of powers. Proposer (management) ≠ approver (DAO for strategic, Guardian Council for operating) ≠ signer (MPC 8-of-14) ≠ gatekeeper/overseer (Treasury Stewards). No fund can move without independent action by all four — extraction requires collusion across every layer.
Released funds can reach only two hardcoded destination addresses — enforced in contract logic, not by policy. Every release is contract-logged and signed.
1 · DAO operational draw-down address. The DAO draws operating funds and other authorised draw-downs through this address — the normal forward path, co-authorised by the Treasury Stewards.
2 · Fallback Custodian wallet. A small wallet controlled by an independent backup group of custodians (the “forward” committee), used only when the primary path fails to engage. They hold funds in custody only — they cannot spend; they can only return funds to the DAO operational path once governance is restored. The backup group is small, independent and jurisdiction-diverse — a 3-of-5 signing quorum, with membership strictly disjoint from the Treasury Stewards.
Two committees. The current committee (Treasury Stewards) governs the normal path; the forward committee (Fallback Custodians) is the backup that keeps funds from ever freezing. Membership is strictly disjoint — no person sits on both.
Delivery-gated; no post-delivery refunds. Funds are held in Rédeas vaults and release on delivery of the milestone they fund. Once the technology is delivered, capital is committed and cannot return to contributors. The only refund case is pre-delivery non-delivery, protected by the Rédeas Vault clawback — if the work is not built, contributors are made whole; once it is built, capital builds and runs the company.
No system survives by avoiding all failure. It survives by designing for it. The following are documented provisions for predictable failure modes.
Guardian Council quorum failure. Auto-escalation: if the standard 4-of-7 per group (8 of 14) Genesis Vault keyholder threshold (or 4-of-7 Guardian Council threshold for post-Genesis releases) is not reached within 14 days, the threshold TIGHTENS to a member-protective supermajority (9-of-14 keyholders (two groups of 7) / 6-of-7 Guardian Council) with an extended 7-day window. The bar gets HIGHER under uncertainty — never lower. If the tightened supermajority is still not reached, dispute escalates to Tier 3 (Quorum Guardian) under the Dispute Resolution Ladder. Funds remain locked throughout; cannot be unilaterally released.
Treasury committee failure to engage. No inaction can trap funds, and post-delivery no funds return to contributors. The release contract hardcodes exactly two destination addresses : (1) the DAO operational draw-down address , and (2) a Fallback Custodian wallet controlled by an independent backup group. Operating-budget releases: if the Treasury Stewards do not co-sign within 7 days (+7-day extension), the Guardian Council 6-of-7 supermajority may authorise the operating release to the DAO address alone — payroll, SotaTek and infrastructure never stall. Total primary-path failure: if no release is resolved within 60 days, the affected balance routes — contract-logged — to the Fallback Custodian wallet, where the backup group holds it (custody only, no spending) until governance is restored and it returns to the DAO operational path. Hard maximum-lock rule: no balance sits unresolved beyond 90 days; at the deadline it auto-routes to the Fallback Custodian wallet. Funds can only ever reach one of the two allowlisted addresses — never a personal wallet, and (post-delivery) never back to contributors. The sole refund case is pre-delivery non-delivery, handled separately by the Rédeas Vault clawback. Persistent Steward non-engagement (3 missed actions) triggers seat vacancy and replacement within 30 days.
Guardian seat vacancy. Staggered 2-year terms with rotating replacements. If a seat becomes vacant mid-term (resignation, incapacity, removal by 75% community vote), the next-ranked candidate from the most recent skill-matched election fills it. If no candidate available, seat opens to community election within 30 days. Council operates with reduced membership until filled (minimum 4-of-7 voting members for any action).
Smart contract bug discovered post-deploy. Genesis Vault is non-upgradeable by constitutional design — no patch path exists. Aurora-onwards value-handling contracts are immutable — no proxy, no upgrade key; new features ship as separate opt-in contracts, never an upgrade to a live contract. Discovered vulnerability triggers: (a) immediate pause on affected functions where pause exists; (b) public disclosure within 24 hours; (c) mitigation proposal published with 72-hour public review window; (d) upgrade executed only after timelock expires.
Module underdelivery. SotaTek Development Escrow holds development funds against documented milestones with proof-of-work attestation. Failure to deliver triggers 14-day dispute pause, then Guardian Council 4-of-7 review. Persistent non-delivery can result in: (a) milestone forfeit; (b) code escrow release to secondary firm on retainer; (c) refund of unreleased phase reserve to contributors via Rédeas Vault clawback.
Phase under-raise. Each phase has a documented Schedule B (operational expenses + phase reserve). If a phase’s community raise does not meet its documented development costs, the exchange backstop reserve — held in escrow and released only to the IP-holding company, never to Chronimy directly — may, if the partnership is secured, be drawn down in milestone tranches to cover the shortfall so delivery proceeds. Descoping work to available funds, and (below the operational viability threshold) refunding the phase reserve to contributors via the Rédeas Vault clawback mechanic, apply only as fallbacks where the backstop reserve is itself unavailable.
Architect role incapacity. Succession protocol: role transfers by transfer of access credentials to the unified contributor interface. The successor inherits the role, not the founder identity. Vesting allocations continue flowing to the designated wallet regardless of role status. Vision Guardian seat (permanent, omniscient) provides continuity of constitutional oversight.
Banking partner failure. Chronimy Holdings AG operates two-account architecture (CHF + EUR) at primary banking partner. Secondary banking partner on standby. Beneficiary whitelist locked at the bank level — captured banking partner cannot extract funds outside the whitelist destination. The Treasury Stewards — a community-elected, all-phase oversight body — authorise the Treasury → Operations direction; the Guardian Council controls Operations disbursement.
PRU insolvency. PRU is a discretionary platform-funded reserve. If active pool is depleted, payouts pause. Replenishment continues from 8% profit allocation. Coverage decisions become deferred queue, prioritised by Guardian Council per published rubric. Members are notified of pool status; no implicit guarantee that any case will be paid.
AG / Stiftung legal challenge. FINMA Auskunftsverfahren submitted pre-Aurora. Adverse classification triggers immediate pause on token issuance, public disclosure to all members, and structural review with retained Swiss counsel. Treasury whitelist preserves contributor funds during any pause. Constitutional immutables protect core architecture from any external coercion.
Universal logging (Brain §0.2) means every failure mode invocation is publicly recorded. Members can verify how failures were handled by reading the log directly.
Every CNMY token in existence is held in one of Chronimy's autonomous smart contracts. There is no foundation wallet, no team wallet, no founder wallet with discretionary access to CNMY. Zero founder access is enforced at the contract level, not by policy — there are no private keys that could unlock funds even if the founder wanted to. Moving any treasury funds requires defined contract functions subject to 4-of-7 Guardian Council multi-party computation approval.
PRU Vault. Allocation: 25% supply. Access Control: GC 4-of-7. Release Trigger: Verified platform failure · Guardian Council discretionary vote.
Vesting Contracts (6). Allocation: 15% supply. Access Control: Automated. Release Trigger: Exchange listing trigger · Schedule-based linear release.
Escrow Factory. Allocation: Dynamic. Access Control: State machine. Release Trigger: Dual confirmation · 5-state machine · Settlement finality window.
Burn Contract. Allocation: Accrues. Access Control: None — dead. Release Trigger: Routes to 0x000 dead wallet · Irreversible · No release possible.
MPC Treasury. Allocation: Operational. Access Control: MPC 4-of-7. Release Trigger: Guardian Council approved operational expenditure only.
Community & Growth. Allocation: 60% supply. Access Control: Phase-gated. Release Trigger: Fundraising phases, badge activations, protocol rewards.
Multi-Party Computation (MPC) distributes signing authority across multiple independent parties — no single party ever holds a complete private key. Chronimy uses the tss-lib GG20 protocol with a 14-participant ceremony: 7 public participants (known identities) and 7 private participants (identities confidential). Moving any treasury funds requires 4-of-7 threshold signatures from each group independently — compromise of one group alone cannot move funds.
Jurisdiction diversity. Minimum 8 different countries across all 14 participants. No two in the same legal jurisdiction.
Independence. No financial, employment, or familial relationship with Chronimy Holdings AG, SotaTek, or any other participant.
Technical capability. Demonstrated ability to operate a hardware security module (HSM) or equivalent secure key storage, verified by SotaTek pre-ceremony.
No US persons. Zero US citizen or US resident participants. Consistent with platform-wide zero-US footprint architecture.
Clean background. No criminal convictions relevant to financial integrity, fraud, or digital assets. Verified independently pre-ceremony.
The vesting-wallet jurisdiction was selected for its mature crypto-asset legal framework and its established legal framework for digital-asset custody. The vesting destination is an immutable contract releasing to an independent designated holding entity — no Chronimy entity, no associated party.
Founder allocation. 5% of 20B CNMY total supply = 1,000,000,000 CNMY
Vesting trigger. Exchange listing. First CEX listing activates the schedule. "first listing" does not apply to Chronimy.
Initial unlock. 20% at listing = 200,000,000 CNMY — to independent designated wallet only.
Monthly release cap. 2% of already-vested balance per month. Hardcoded in contract — cannot be changed post-deployment.
Vesting duration. 36 months linear from exchange listing date.
Hardcoded destination. independent designated wallet address only — cannot be altered after deployment.
Acceleration mechanism. None. No early release function exists in the contract. Immutable.
SotaTek admin access. Zero. No admin keys exist post-deployment. Immutable.
The vesting lock is constituted after the Genesis seed close — not before. There is therefore an interim period between Genesis seed close and full Trust operational status during which the Trust does not yet exist as a legal entity. This section discloses exactly what custody arrangements are in place during that interim window, and what changes once the Trust is constituted.
Pre-Genesis. Approximate timing: Genesis pre-launch. Trust status: Vesting contract pending deployment · destination wallet specification in draft. Custody of funds: Operating funds: zero · No raised capital yet. Architect compensation channel: Architect personal capital (out-of-pocket pre-funding).
Genesis active. Approximate timing: 0–6 weeks of Genesis seed campaign. Trust status: Deployment in active progress · Vesting contract deployed · Vesting contract in legal review. Custody of funds: Genesis Vault holds raised CHF in member-keyholder custody (10 VRF-selected depositors · 4-of-7 per group (8 of 14) release threshold · 48hr visibility). Architect compensation channel: Genesis founder costs (covered outside community funds, via the separate IP holding company · documented · time-bounded).
Genesis close → Trust transition. Approximate timing: Approximately 6–9 weeks post-Genesis-close. Trust status: Vesting parameters finalised · designated wallet generated · hardcoded at deployment. Custody of funds: Genesis Vault: unchanged (member-keyholder custody continues) · Aurora preparation funds: in Chronimy Holdings AG operating account (post-AG formation), governed by Swiss CO Art. 716+. Architect compensation channel: founder costs are covered outside the community raise during the interim · no token allocation yet (CNMY does not exist on-chain pre-Nebula).
Trust operational. Approximate timing: Approximately 9 weeks post-Genesis-close · prior to Aurora open. Trust status: Fully deployed · Vesting contract operational · designated wallet active · ready to receive vested CNMY at first CEX listing. Custody of funds: Genesis Vault: unchanged · Aurora-onwards Rédeas Vault instances handle phase contributions · MPC custody operational from Nebula CNMY launch. Architect compensation channel: Founder Vesting hardcoded to designated wallet address at Nebula deployment · vesting begins at first CEX listing · Genesis-phase costs covered outside the community raise, not from community funds.
The Glass Treasury is Chronimy's real-time public financial dashboard. It displays every platform financial flow — fundraising progress, CNMY burned to date, PRU vault balance, profit distributions — sourced directly from on-chain state. There is no database behind it that could be manipulated. There are no adjustable numbers. It is transparency enforced by architecture, not policy.
Collateral Provision Fee. %: 20%. Notes: On-chain Collateral Provision Fee — the 20% ceiling caps the fee. Providers earn a variable, discretionary share of monthly profit (up to 20%, no minimum), paid only after that month's member claims are covered and the PRU is restored to target; AG fiat → market-buy CNMY (TWAP) settles the fee. It is compensation for committing loss-absorbing collateral that can be drawn down to protect members — a variable service fee contingent on real loss events, not a fixed yield or passive APY. See Section 1.3..
Member Growth Rewards. %: 19%. Notes: Activity rewards, referrals, governance participation, dispute resolution, streak bonuses.
Buyback. %: 13%. Notes: On-chain Buyback and Burn . AG fiat → market-buy CNMY (TWAP) → 80% burned to 0x000 + 20% routed to IPDF Strategic Reserve Vault. Autonomous · hardcoded · non-discretionary..
TWAP Execution Discipline. %: —. Notes: Time-Weighted Average Price execution protocol : buybacks are executed via rolling 30-day TWAP windows, broken into hourly micro-orders to prevent price manipulation and minimise market impact. Off-chain execution agents (regulated market makers under contract — candidate firms include established professional market makers) place orders against the deepest CNMY liquidity venues (DEX + designated CEX listings post-Pulsar). Slippage limit 0.5% per micro-order — orders exceeding limit are paused and rolled into the next hour. Transparent reporting : weekly TWAP execution reports published to the Glass Treasury (volume bought, average price, allocation 80% burn / 20% Strategic Reserve, slippage statistics). 100% of bought-back tokens follow the 80/20 split — burn portion sent to 0x000 dead address; Strategic Reserve portion deposited to IPDF Strategic Reserve Vault..
Development. %: 12%. Notes: Development Escrow · Guardian Council 4-of-7 milestone releases · 72hr timelock. SotaTek ongoing engagement, platform build, maintenance, upgrade delivery..
Core Team & Operations. %: 8%. Notes: Staff, running costs, infrastructure — AG nominated director under Swiss CO Art. 716+..
PRU Vault Replenishment. %: 14%. Notes: On-chain PRU Replenishment . AG fiat → market-buy CNMY (TWAP) → send to PRU vault when solvency <120% (until 150% restored). Autonomous · solvency-triggered..
Licensing. %: 5%. Notes: AG fiat sub-account designated to fund the bilateral IP licence arrangement between Chronimy Holdings AG and the separately-constituted IP entity (post-Genesis structural-separation completion) (defensive structural separation). Public allocation magnitude · commercial terms remain corporate-confidential..
IPDF (Litigation-Ready Vault). %: 4%. Notes: AG fiat sub-account routed to IPDF Litigation-Ready Vault (stable CHF/USDC reserves). Funds patent prosecution and defence costs per LFA. Project Lead approves ≤ CHF 50K; Project Lead + Guardian Council 4-of-7 for > CHF 50K. Held separately from PRU and JLDP. See Section 3.5.IPDF..
DAO Governance Fund. %: 3%. Notes: Proposal system, Quorum Guardian compensation, governance operations. DAO supermajority >66% sole authority..
Security & Compliance Reserve. %: 2%. Notes: Independent audits, legal opinions, regulatory filings..
migrateAllocation() function and redirect the 20% allocation to community membership benefits. This is a contingency safeguard, not a substitute for the primary characterisation, which is to be confirmed with Cyprus counsel prior to IEO 1.
PRU (Protocol Reserve Unit). Purpose: Member protection — covers platform-level failures affecting members. Funded by: Burn Reserve bootstrap (5B CNMY → first 500K members) · 8% of post-launch profit (PRU Replenishment per 10-Way Split). Disbursement authority: Member claims only · sacred · Guardian Council 4-of-7 · NEVER used for IP defence.
IPDF (IP Defence Fund). Purpose: Patent prosecution + defence + commercial enforcement actions. Funded by: Aurora raise 12-15% · Platform profit 4% (Litigation-Ready Vault, stable) · Buyback redirect 2.6% effective (Strategic Reserve Vault, CNMY) · Recovered damages net of Licensor + JLDP shares. Disbursement authority: Project Lead approves ≤ CHF 50K · Project Lead + Guardian Council 4-of-7 for > CHF 50K · Strategic Reserve Vault CNMY-to-stable conversion requires Council 4-of-7.
JLDP (Joint Litigation Defence Pool). Purpose: Shared defence costs across commercial licensees of the patent portfolio. Funded by: Commercial licensees (% of annual licence fee, capped CHF 50K per member per year for standard tier). Disbursement authority: JLDP Council vote (5 seats: 3 elected by member contribution weight, 1 AG nominee, 1 Licensor nominee) · proportional · defence-only · never offensive.
"The project [Chronimy Holdings AG] shall maintain at all times an IP Defence Fund (the IPDF), held separately from any other reserve including the Protection Reserve Utility (PRU). The IPDF shall be funded by allocations from platform profit, burn reserve, primary raise proceeds, unclaimed airdrop tokens, and recoveries from intellectual-property enforcement, in proportions set out in the project's standing financial policy. The IPDF shall be disbursed solely (i) to fund defence and prosecution of intellectual-property rights held by the Licensor and licensed exclusively to the project, and (ii) for related platform-integrity matters as defined in the Litigation Funding Agreement. The project shall not comingle the IPDF with the Protection Reserve Utility or any other operational reserve."
"The project shall operate a Joint Litigation Defence Pool (the JLDP), held separately from the IPDF and the PRU. The JLDP shall be funded by contributions from commercial licensees of patents licensed to the project by the Licensor, made under standardised JLDP Member Agreements. The JLDP shall be governed by a JLDP Council comprising five seats: three elected by member contribution weight, one Chronimy nominee, and one Licensor nominee. The JLDP shall be disbursed solely for defence costs against challenges to or infringement of the licensed patents, and shall not fund offensive litigation initiated solely by the project or the Licensor. Recovery from successful enforcement shall be distributed pro-rata to contributing members after legal costs and Licensor share. JLDP membership shall be open to all qualified commercial licensees and shall not be used as an instrument of competitive pricing or market exclusion."
Litigation-Ready Vault. Asset type: Stable assets (CHF / USDC). Disbursement: Always disbursable for active litigation per IPDF disbursement authority. Purpose: Funds active patent prosecution, defence costs, prior-art search, expert witnesses, court fees.
Strategic Reserve Vault. Asset type: CNMY tokens. Disbursement: Convertible to stable on Guardian Council 4-of-7 approval (top-up source for Litigation-Ready Vault). Purpose: Strategic CNMY accumulation · self-reinforcing as platform success grows token value · provides multi-year defence headroom.
Aurora raise carve-out. Allocation: 12-15% of total Aurora raise. Vault destination: Litigation-Ready Vault. Cadence: One-time at Aurora close.
Platform revenue (Litigation-Ready). Allocation: 4% of profit (per 10-Way Split). Vault destination: Litigation-Ready Vault. Cadence: Ongoing post-launch.
Buyback redirect (Strategic Reserve). Allocation: 13% × 20% = 2.6% effective. Vault destination: Strategic Reserve Vault. Cadence: Ongoing post-launch.
Burn Reserve allocation. Allocation: 5% of Burn Reserve canonical = 250M CNMY. Vault destination: Strategic Reserve Vault. Cadence: One-time at AG incorporation.
Unclaimed CNMY airdrop. Allocation: 100% permanently burned. Vault destination: Not redirected to any fund or purpose — the recipient list is locked, so unclaimed tokens are destroyed. Cadence: As the 24-month claim window closes.
Recovered damages. Allocation: Net of Licensor + JLDP shares. Vault destination: Litigation-Ready Vault (replenishment). Cadence: Per recovery.
IPDF and JLDP both exist as constitutional reserves. Absolute fund sizes at any point in time
JLDP membership count (aggregate number). Individual member identities (unless member elects disclosure)
Funding source categories (per table above). Specific allocations at any point in time
"The Licensor" framing for IP entity. Specific name of the IP entity (NDA-protected per OPSEC canonical)
JLDP governance structure (5-seat Council, vote weighting). Specific member contribution amounts · Council vote records
Combined IPDF + JLDP defence capacity exists. Specific defence headroom calculations
Chronimy uses three distinct authorisation regimes (autonomous on-chain · multisig/DAO · AG nominated director) across multiple custody and governance contexts. Confusion between thresholds — particularly between Genesis Vault (member-keyholder) custody and post-Genesis MPC custody — has been a persistent source of inconsistency in earlier drafts. This section establishes the canonical mapping. Where any other paper or section disagrees with this table, this table is authoritative.
Genesis Vault Keyholders. Standard Threshold: 4-of-7 per group (8 of 14). Total Set: 10 (every 15th depositor via Chainlink VRF). Authority Type: Member-elected (random). What It Authorises: Genesis CHF 130K vault releases · 48-hour community visibility · constitutional immutable.
Treasury Stewards. Standard Threshold: 6-of-9 slow · 5-of-9 operating. Total Set: 9 (5 phase-reserved + 4 at-large). Authority Type: Community-elected · 1 verified member = 1 vote. What It Authorises: Co-authorise Treasury→Operations · audit Glass Treasury · veto in timelock · emergency-freeze petition.
MPC Custody Ceremony. Standard Threshold: 4-of-7 per group. Total Set: 14 (7 public + 7 private). Authority Type: Cryptographic ceremony. What It Authorises: Post-Genesis treasury movement · 8 minimum signers from 14 total · tss-lib GG20.
Guardian Council — Standard. Standard Threshold: 4-of-7. Total Set: 7 voting seats (Security & Custody · Legal & Compliance · Technology & Protocol · Community & Trust · Finance & Treasury · Ecosystem & Growth · Member Protection). Authority Type: Community-elected. What It Authorises: Development Escrow milestone releases · 72-hour timelock · ceremony authorisation · participant removal.
Guardian Council — Supermajority. Standard Threshold: 6-of-7. Total Set: 7 voting seats. Authority Type: Community-elected. What It Authorises: Immutable value contracts (no upgrade path); new features as separate opt-in contracts · 72-hour timelock on fund releases · TIGHTENED auto-escalation threshold.
Vision Guardian. Standard Threshold: 1 (constitutional). Total Set: 1 (separate from Council). Authority Type: Architect persona · UNPAID. What It Authorises: Defensive watchdog · observe / alert / veto on member-protection changes · removable only by 75% DAO supermajority.
Quorum Guardian Panel. Standard Threshold: 5-of-7 majority. Total Set: 21–49 Gold Badge holders (randomly assigned, conflicts excluded). Authority Type: Random selection from Gold Badge pool. What It Authorises: Tier 3 dispute resolution · appeals · escalations from Council quorum failure.
DAO Governance. Standard Threshold: >66% supermajority. Total Set: All Green Badge holders (1-badge-1-vote). Authority Type: Member voting (badge-gated). What It Authorises: Constitutional changes · governance fund disbursements · 75% required to remove Vision Guardian.
Member Trust-Locked Asset Vault (TLAV). Standard Threshold: 2-of-3 to 5-of-7 (member-configurable). Total Set: Member-selected co-signers. Authority Type: Product feature. What It Authorises: Personal multisig wallet protection · independent of Council/DAO.
If a release proposal does not reach the standard threshold within the standard window (typically 14 days), the threshold TIGHTENS to a member-protective supermajority — never lowers. This is a deliberate constitutional design: under uncertainty, the bar gets HIGHER, not lower. If the tightened threshold is still not reached, dispute escalates to the Quorum Guardian (Tier 3) panel.
Genesis Vault Keyholders. Standard: 4-of-7 per group (8 of 14). TIGHTENED (after 14-day timeout): 4-of-7 per group (8 of 14) (extended 7-day window). Final Escalation: Tier 3 Quorum Guardian.
Guardian Council — Standard. Standard: 4-of-7. TIGHTENED (after 14-day timeout): 6-of-7 (extended 7-day window). Final Escalation: Tier 3 Quorum Guardian.
MPC Custody (per group). Standard: 4-of-7. TIGHTENED (after 14-day timeout): 6-of-7 (extended 7-day window). Final Escalation: Tier 3 Quorum Guardian.
Note: This is the canonical threshold table. The Architecture Paper §7.2 (smart-contract thresholds), Security Paper §9.6 (MPC ceremony), and Architecture Paper §7.10 (Guardian Council operations) all reference this section as authoritative. Member TLAV thresholds (final row) are user-configurable product features, distinct from protocol-level governance thresholds.
Contributor funds are protected at five distinct architectural layers, applied phase-by-phase. The cascade below documents how funds flow from contribution through custody to release, what triggers a refund or pause at each phase, and which body holds release authority. Funds raised by one phase fund only that phase's modules — never speculative future work.
Genesis (CHF 195K). Custody Contract: Genesis Vault (non-upgradeable). Release Threshold: 8-of-14 keyholders (4-of-7 per group, two groups of 7) + 48hr visibility. Release Authority: 10 VRF-selected member keyholders. Refund Trigger: Aurora target not raised within 6 months · or constitutional breach. Refund Path: Pro-rata refund to Genesis-phase contributors from Genesis Vault residual · keyholder-authorised.
Aurora (CHF 1.5M). Custody Contract: Rédeas Vault (Aurora instance). Release Threshold: 4-of-7 Guardian Council + 48hr Rédeas timelock. Release Authority: Guardian Council — milestone-gated. Refund Trigger: Module 1 milestones not delivered within UAT period · 21-day non-response. Refund Path: Rédeas Vault residual returns pro-rata to Aurora contributors via depositor-keyholder authorisation.
Nebula (CHF 13.44M). Custody Contract: Rédeas Vault (Nebula instance). Release Threshold: 4-of-7 Guardian Council + 48hr Rédeas timelock. Release Authority: Guardian Council — milestone-gated. Refund Trigger: Module 2 milestones not delivered · or FCA s.21 approval blocked / FSMA pathway not viable. Refund Path: Rédeas Vault residual returns pro-rata to Nebula contributors.
Pulsar (CHF 20.16M). Custody Contract: Rédeas Vault (Pulsar instance). Release Threshold: 4-of-7 Guardian Council + 48hr Rédeas timelock. Release Authority: Guardian Council — milestone-gated. Refund Trigger: Module 3 milestones not delivered. Refund Path: Rédeas Vault residual returns pro-rata to Pulsar contributors.
Supernova (CHF 30.2M). Custody Contract: Rédeas Vault (Supernova instance). Release Threshold: 4-of-7 Guardian Council + 48hr Rédeas timelock. Release Authority: Guardian Council — milestone-gated. Refund Trigger: Final platform launch milestones not delivered. Refund Path: Rédeas Vault residual returns pro-rata to Supernova contributors.
Post-launch operating. Custody Contract: MPC Custody (14-participant ceremony). Release Threshold: 4-of-7 per group (8 of 14 minimum) · 72hr Development Escrow release. Release Authority: 10-way sub-account routing — autonomous on-chain · multisig/DAO · AG nominated director. Refund Trigger: Constitutional immutables breach · supermajority DAO action · regulatory adverse classification. Refund Path: PRU Vault (member liability reserve) · structural review with Swiss counsel · Treasury whitelist preserves contributor funds during pause.
PRU Replenishment (8% of post-launch profit) · solvency-triggered <120% · separate from phase Rédeas VaultsThis section consolidates the funding-cascade architecture previously distributed across the Architecture Paper §7.4 (Rédeas Vault per-phase instantiation), Security Paper §9.7 (refund mechanism), Governance Paper §2.1 (Phase Compliance Principle), and Partner Paper §4.3 (mitigation architecture). Where any of those papers references funding cascade behaviour, this section is authoritative.
Part 3 documents the custody architecture that makes Chronimy's zero-founder-access promise verifiable rather than policy-reliant. Every CNMY is in an autonomous smart contract. The MPC ceremony distributes signing authority across 14 independent parties in two groups. The vesting lock adds an institutional accountability layer to founder vesting. The Glass Treasury makes every fund flow — including the full ten-way profit split — publicly visible in real time. Material risks including key person risk are disclosed honestly and fully. Section 3.7 establishes the canonical threshold mapping; Section 3.8 establishes the canonical funding-cascade architecture.
3.1. Title: Custody Architecture. Key Point: 100% CNMY in autonomous contracts. Zero founder access enforced at contract level — not policy. 4-of-7 required for any post-Genesis movement (4-of-7 from each group (8 of 14) for Genesis Vault releases)..
3.2. Title: MPC Ceremony Process. Key Point: 14 participants · 4-of-7 per group · tss-lib GG20 · Proactive resharing · Annual cadence recommended..
3.3. Title: Shard Participant Selection. Key Point: 7 public + 7 private. 8+ jurisdictions. Full independence requirements. Zero US persons. Legal custodian certification for Group B..
3.4. Title: Founder Vesting Framework. Key Point: 5% founder allocation · 20% at listing + 36-month linear · 2% monthly cap · Hardcoded destination · PRU staked throughout vest period..
3.5. Title: Glass Treasury. Key Point: Real-time public financial dashboard. Direct chain reads. No admin panel. Zero override. Full ten-way profit split documented and immutable..
3.6. Title: Material Risk Factors. Key Point: 8 risk categories disclosed. High: regulatory, smart contract, key person. Medium: governance, MPC, KYC. Low: volatility, adoption..
Click Next Below to continue to Zone 6 — Platform Conduct, Quorum Guardians, ECR & Budget
The Five Absolute Rules are non-negotiable platform conduct principles constitutionally protected against Guardian Council override. Any badge holder who violates these rules is subject to badge suspension via the ECR system.
The Chronimy Protocol allocates 1,500,000,000 CNMY (7.5% of total supply) across two distinct philanthropic streams, structurally split per architect canonicals A15 (Scam Victims Airdrop) and A17 (Chronimy Kind Channel): 500,000,000 CNMY (2.5%) to a locked list of scam victims (A15), and 1,000,000,000 CNMY (5%) to the Chronimy Kind Channel for vetted philanthropic causes administered by the Chronimy Stiftung. Both allocations vest 20% at exchange listing and 80% over 36 months linear. Both are pre-locked and immutable from deployment. Neither can be redirected by any governance vote. The Scam Victims Airdrop (Stream 1) recipient list is a locked, founder-determined Merkle list, constitutionally fixed before launch and not open to application; neither allocation can be redirected by Guardian Council vote or DAO proposal.
The Scam Victims Airdrop is not an open programme and cannot be applied for. It is restitution to a fixed, locked list of specific people the founder met across the years building toward Chronimy who were scammed on failed projects and collapsed exchanges — among them IDAX. The recipient list is founder-determined and constitutionally fixed before exchange listing and published as a locked Merkle list. There is no qualification, no eligibility assessment, no claim review, and no additions once the list is locked.
The Chronimy Kind Channel is the broader philanthropic stream — a 1,000,000,000 CNMY (5% of total supply) allocation administered by the Chronimy Stiftung (the separately-constituted Swiss charitable foundation). Where Stream 1 (Scam Victims) is targeted at members harmed by the specific failure mode Chronimy exists to solve, Stream 2 funds vetted philanthropic causes aligned with Chronimy's mission — fraud prevention research, financial-literacy programmes for high-vulnerability populations, recovery support for victims of large-scale scams, and similar mission-aligned philanthropy.
The Quorum Guardians are 21 to 49 verified Gold Badge holders elected by the community to serve as independent adjudicators. Their findings are advisory to the Guardian Council, but form the primary evidence basis for any compensation review request or badge action. The pool scales with platform size — minimum 21 for quorum, maximum 49 to maintain deliberation quality.
The External Conduct Review system provides a formal mechanism for reporting verified off-platform misconduct. It is not a complaint system — it requires a CNMY stake from the reporter to deter false reports, and routes every case through Quorum Guardian adjudication before any badge action can be taken.
Upheld — Serious. Permanent badge revocation. Reporter stake returned. Conduct recorded on Beacon Layer permanently.
Upheld — Minor. Temporary badge suspension. Warning issued. CTS score adjustment. Reporter stake returned.
Dismissed — Unproven. No badge action. Reporter stake returned. No CTS impact on respondent.
Dismissed — Malicious. No badge action on respondent. Reporter stake forfeited. Reporter badge reviewed for abuse pattern.
Combined legal opinion (5 questions). Budget (CHF): 25K–45K. Deliverable: MiCA per phase · PRU classification · SFD · NPR characterisation · qualified external legal counsel.
Smart contract security audits (×2). Budget (CHF): 150K–200K. Deliverable: Two independent firms. All contracts before mainnet deployment. Reports published in full..
FINMA Auskunftsverfahren. Budget (CHF): 2K–5K. Deliverable: PRU classification + CNMY utility token written confirmation from FINMA.
Swiss AG + Stiftung formation. Budget (CHF): 8K–15K. Deliverable: Deed, cantonal registration, notarisation, FINMA notification.
Trademark filings (CH, EU, UK, US, IE). Budget (CHF): 8K–15K. Deliverable: CHRONIMY mark. Five jurisdictions. Classes 36, 42. Madrid Protocol..
founder-vesting establishment. Budget (CHF): 5K–10K. Deliverable: Private foundation deed, immutable vesting contract, regulated jurisdiction compliance.
MPC ceremony legal counsel. Budget (CHF): 10K–20K. Deliverable: Participant verification, ceremony oversight, Group B (undisclosed) custodian certification.
Chronimy executes confidentiality agreements in several contexts: with Guardian Council members (founder identity disclosure), with the legal custodian for shard-participant identity protection, with SotaTek and other operational partners, with the simulated specialist panel and named advisors, with prospective Genesis backers post-introduction, and with specialised legal/audit/regulatory counsel. Every Chronimy NDA is structured with explicit Permitted Purpose carve-outs that preserve discovery, whistleblower, regulator-disclosure, and personal-protection rights. Chronimy NDAs are confidentiality instruments — never gag instruments.
1. Mandatory legal/regulatory disclosure. Scope: Any disclosure required by court order, subpoena, regulatory request (FINMA, FCA, MiCA-passporting Member-State authorities, sanctions authorities), or applicable law of the recipient's jurisdiction.. Notification Requirement: Recipient notifies Chronimy Holdings AG promptly upon receipt of order/request, where doing so is itself permitted by law. Recipient is not required to challenge or delay the order..
2. Whistleblower protections. Scope: Disclosure to a competent regulatory or law-enforcement authority of conduct the recipient reasonably believes is unlawful, fraudulent, or constitutes a material public-interest concern.. Notification Requirement: None. Whistleblower disclosure is unconditionally permitted. Chronimy NDA does not require notification, consent, or pre-clearance for whistleblower disclosure. Retaliation for whistleblower disclosure is itself an Absolute Rule violation..
3. Discovery in litigation. Scope: Disclosure required in the course of legal proceedings, including civil discovery, criminal proceedings, regulatory enforcement, or arbitration where the recipient is a party or witness.. Notification Requirement: Recipient may produce confidential information under standard discovery protections (protective orders, in-camera review where appropriate). Chronimy will not seek to obstruct lawful discovery..
4. Professional advisor disclosure. Scope: Disclosure to recipient's own qualified legal, accounting, tax, audit, or regulatory advisors who themselves are bound by professional confidentiality (legal privilege, accountant duty, etc.).. Notification Requirement: Recipient ensures advisors are aware of the confidential nature of the information. No further notification required..
5. Personal-safety disclosure. Scope: Disclosure necessary to protect the recipient or any other person from imminent harm, including disclosure to law-enforcement authorities, medical professionals, or qualified mental-health professionals.. Notification Requirement: None. Personal-safety disclosure is unconditionally permitted..
6. Public information. Scope: Information that is or becomes publicly available through no breach of the NDA, or that the recipient lawfully obtained from a source other than the disclosing party.. Notification Requirement: None. Public information is outside NDA scope..
7. Independent development. Scope: Information independently developed by the recipient without reference to or use of confidential information disclosed under the NDA.. Notification Requirement: Recipient maintains documentation of independent development..
Chronimy NDAs cover specific categories of information: (a) the Architect's real-world identity and personal details; (b) shard-participant identities and custody operational details; (c) the IP holding entity identity, jurisdiction, and structure (trade-secret); (d) commercial terms of the bilateral IP licence arrangement; (e) SotaTek's pre-existing IP and proprietary methodologies disclosed under the Pre-Project Agreement; (f) personally identifiable information of members, partners, or counterparties; (g) Genesis private SimpleX channel content; (h) trade-secret platform internals not intended for public disclosure. The NDA defines each category with specificity. Information outside these categories is not confidential and is not subject to any non-disclosure obligation.
Standard duration: 3 years from disclosure date for general confidential information; indefinite for trade-secret information explicitly designated as such (IP holding entity identity, certain custody operational details). Permitted Purpose carve-outs survive termination of the NDA. Whistleblower and discovery rights cannot be extended or reduced by NDA term — these rights derive from law, not from the NDA.
This Permitted Purposes Framework is published as the canonical reference for all Chronimy NDAs. Any individual NDA that conflicts with or attempts to narrow these Permitted Purposes is void to the extent of the conflict. Recipients of Chronimy NDAs may rely on this framework as the floor of their disclosure rights.
W1. Item: Authority tier trigger conditions (GREEN → EMERGENCY escalation). Section: 2.3. Phase: Aurora. Design Intent / What Confirms It: Event types, duration limits, and escalation protocols confirmed in Guardian Council governance workshops before community voting begins.
W2. Item: Proposal quorum thresholds (Operational / Structural / Constitutional). Section: 2.6. Phase: Nebula. Design Intent / What Confirms It: Requires real badge-holder distribution data. Design principle: more consequential = higher bar. Set too low = capture risk; too high = paralysis.
W3. Item: MPC ceremony rotation schedule. Section: 3.2. Phase: Nebula. Design Intent / What Confirms It: Annual recommended cadence (proactive resharing). Confirmed schedule and emergency replacement protocol in Nebula MPC governance workshop.
W4. Item: Shard participant rotation triggers & removal procedure. Section: 3.3. Phase: Nebula. Design Intent / What Confirms It: Removal requires GC 4-of-7 vote + emergency resharing within 30 days. Full trigger list confirmed in Nebula workshop.
W5. Item: founder vesting contract terms & destination wallet. Section: 3.4. Phase: Aurora. Design Intent / What Confirms It: Vesting parameters confirmed in Aurora legal workshop. Vesting contract published in full with v1.5 update.
W6. Item: ECR reporter stake amount. Section: 4.3. Phase: Nebula. Design Intent / What Confirms It: Stake must be high enough to deter abuse, low enough to permit legitimate reports. Calibrated against platform CNMY price and community feedback.
W7. Item: Quorum Guardian compensation (CNMY per completed review). Section: 4.2. Phase: Nebula. Design Intent / What Confirms It: Confirmed in Aurora governance workshop. Structure: incentivises quality deliberation, not speed.
W8. Item: KYC re-verification cadence (Silver / Gold). Section: 1.6. Phase: Nebula. Design Intent / What Confirms It: Design intent: annual re-verification at Silver; biennial at Gold with interim sanctions screening. Confirmed in Nebula compliance workshop.
W9. Item: Combined legal opinion (MiCA / PRU / SFD / NPR). Section: 1.3–1.5. Phase: Aurora. Design Intent / What Confirms It: CHF 25,000–45,000. qualified external legal counsel. Five-question scope. Pre-launch requirement — hard gate..
W10. Item: compensation review request eligibility thresholds & minimum loss amounts. Section: 1.2. Phase: Nebula. Design Intent / What Confirms It: Must remain discretionary to preserve its discretionary-reserve classification. Parameters confirmed post-legal opinion and before platform launch.
W11. Item: 1,000 persona calibration parameters. Section: 2.5. Phase: Pulsar. Design Intent / What Confirms It: SotaTek Deliverable 14. Requires real platform behavioural data. Archetypes confirmed at Pulsar when sufficient transaction history exists.
W12. Item: Oracle Engine provider rotation schedule. Section: 2.4. Phase: Pulsar. Design Intent / What Confirms It: Provider selection criteria and consensus algorithm specification confirmed in Pulsar phase. EU-based provider evaluation included..
Chronimy Holdings AG has retired the language of roadmaps in favour of phase-funded modules. A module is not a date commitment; it is a deliverable funded by its phase community raise, released against its verified milestone (an optional separate backstop, if secured, covering any shortfall). The Guardian Council does not authorise speculative work; it authorises milestone tranches against funded modules.
Genesis. Module: AG + Stiftung formation, separately-constituted IP entity, Patents (incl. Verify family). Build Authorisation Trigger: Genesis packs raised & Chronimy Holdings AG legally registered. Council Action: 4-of-7 sign-off to release Genesis tranche to operational accounts.
Aurora. Module: Nebula sale website + KYC + Get-to-Green + Refer-3 (Module Aurora). Build Authorisation Trigger: Aurora raise of CHF 1.5M held in Development Escrow. Council Action: 4-of-7 sign-off to release Module Aurora milestone tranches.
Nebula. Module: Module 1 — Platform layer (347 features). Build Authorisation Trigger: Nebula raise of CHF 13.44M held in Development Escrow. Council Action: 4-of-7 sign-off per milestone (one milestone loaded at a time).
Pulsar. Module: Module 2 (Trust & Marketplace) + Module 4a (Verify B2B Launch). Build Authorisation Trigger: Pulsar raise of CHF 20.16M held in Development Escrow. Council Action: 4-of-7 sign-off per milestone, parallel tracks for Module 2 and Module 4a.
Supernova. Module: Module 3 (Enterprise) + Module 4b (Verify Network Effects). Build Authorisation Trigger: Supernova raise of CHF 30.2M held in Development Escrow. Council Action: 4-of-7 sign-off per milestone; DAO transition active (progressive · readiness-dependent).
Build capital is released only against verified milestones — no upfront war chest. Genesis seeds company formation (AG + Stiftung) and the founding circle; the first milestone funds formation, legal and audit — no SotaTek work until it is held in escrow. The community raises fund the build through the Rédeas vault and also drive membership growth. Module N is funded by the phase community raise and released only when the prior milestone is proven. This principle is constitutional and cannot be overridden by any Council vote, DAO vote, or Architect action. It is the same discipline Chronimy Holdings AG requires of every member: spend only what is in the vault.
A Chronimy Verify badge passes through five governance-defined states. The Guardian Council, Chronimy Holdings AG operational team, and the Quorum Guardian system each have defined authority over different state transitions. No single party can issue, suspend, or revoke a badge unilaterally outside the framework.
Pending. Meaning: Application submitted; KYC and DNS verification in progress. Authority to Enter / Exit: Chronimy operational team (automated checks). Cannot reject without escalation..
Active. Meaning: Badge issued; identity bound; domain bound; live on customer site. Authority to Enter / Exit: Chronimy issues on KYC pass + DNS confirmation. Active state is the default..
Amber (At Risk). Meaning: DNS lapse, KYC re-verification due, or hidden-badge anti-circumvention warning. Authority to Enter / Exit: Automated. 48-hour remediation window. Reverts to Active on remediation; escalates to Red on failure..
Suspended. Meaning: Badge temporarily disabled pending investigation. Authority to Enter / Exit: Chronimy operational team may suspend. Restoration requires Guardian Council 4-of-7 review within 14 days..
Revoked. Meaning: Badge permanently disabled. Site shows red state.. Authority to Enter / Exit: Guardian Council 4-of-7 vote required. Subject's right to appeal via Quorum Guardian adjudication. Revoked entities cannot re-apply for 24 months..
Any verified entity whose badge is suspended or revoked has the right to appeal. The appeal is heard by a panel of 21–49 Quorum Guardians (Gold Badge holders, randomly assigned, conflicts excluded), with the same architecture used for platform dispute resolution. Chronimy Holdings AG must produce evidence of the trigger event; the appellant may submit counter-evidence; the panel votes by simple majority. Appeals must be filed within 30 days of revocation notice.
The chronimy.org/exposed public feed (Module 4b, Supernova build) publishes anonymised reports of phishing sites that copied verified badges. Governance protections:
"Verify is the platform's trust architecture projected outward. The same governance principles that protect Chronimy members — identity-bound credentials, no unilateral authority, constitutional appeal rights, public auditability — protect Verify customers and the visitors they serve."
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.
Verified businesses caught in protocol-compliant phishing incidents are eligible for first-priority PRU vault coverage. Eligibility requires:
This is a discretionary operational reserve. No legally enforceable payment right exists. The same legal characterisation that applies to PRU coverage of Chronimy members applies to PRU coverage of Verify customers (refer to Section 1.2).
This paper establishes the legal framework, governance architecture, and regulatory compliance position of the Chronimy Protocol. It is the compliance and governance anchor of the five-paper Chronimy Suite.
4.1. Title: Five Absolute Rules. Key Point: No Email · No Off-Platform · No Price Mismatch · Confirm Final. Constitutional. Cannot be removed by any vote..
Supp. Title: Philanthropic Allocation (A15+A17). Key Point: 1.5B CNMY · 7.5% supply combined · Stream 1 Scam Victims 500M (A15) + Stream 2 Chronimy Kind Channel 1B (A17 · Stiftung-administered) · 24-month claim window (Stream 1 = locked list, no application) · constitutionally fixed..
4.2. Title: Quorum Guardian System. Key Point: 21–49 Gold Badge adjudicators · Random assignment · Conflict exclusion · Advisory to GC · compensation from DAO fund..
4.3. Title: ECR System. Key Point: Off-platform conduct. Reporter stake deters abuse. Four-stage process. Badge action on confirmed finding..
4.4. Title: Budget Transparency. Key Point: CHF-denominated. SotaTek 3-phase scope. CHF 208–310K pre-launch legal. Key partners named including Didit.me and iDenfy..
App. Title: v1.5 Commitment Register. Key Point: 12 deferred items · AURORA / NEBULA / PULSAR phase gates · no phase transition proceeds with unresolved AURORA items..