Clary CoinTECHNOLOGY AND TRUST
Inspect the system.
Understand the assumptions.
Clary Coin separates the currency ledger from mathematical verification. Each part has a defined responsibility, a public identity, and limits worth understanding.
This is an experimental testnet system. No independent security audit or production readiness certification is claimed. Its complete public proof-to-reward-and-transfer rehearsal remains unfinished.
DATED EVIDENCE
What has been demonstrated.
The October 20, 2026 chain observation at 20:25 UTC found one research family, one verifier version, no rounds, and zero token supply in the two readers’ common finalized history. This is a dated snapshot, not a live activity counter.
The proof check occurred before the checker’s controllers were removed. Separate later certificates authenticated the same module and an empty controller list. The known proof is a compatibility fixture, not a new discovery. Local reward demonstrations used simulated consensus and accelerated time; they are not public payments.
Where verification happens.
| Layer | What it establishes | Additional assumptions |
|---|---|---|
| Ethereum and Base | Ordering and execution of ledger transactions, public results, balances, and capped issuance. | Ethereum PoS plus Base’s sequencing, derivation, rollup implementation, and administration. |
| ICP application subnet | Replicated execution of the fixed Rust checker compiled to WebAssembly. | ICP execution and governance, the checker implementation, and the admitted library. |
| ICP threshold signing | An ECDSA attestation for the exact checked result and destination verifier. | ICP’s threshold-key infrastructure and the authenticated admitted public key. |
| Base verifier | Signature validity, matching score and artifact, and complete public artifact publication. | The chosen external authority and verifier. It does not rerun Lean or prove ICP state. |
“Distributed” means that a subnet replicates one deterministic checking program. It does not mean a group of mathematicians votes on whether a result is interesting or original. There is no separate Clary validator set or research staking network.
The fixed prior library was checked before admission. Each new proof is checked against that library. Reproducing the one-time admission remains part of assessing the system; an Ethereum signature check does not establish it.
PUBLIC IDENTITIES
Verify the deployment.
The configured currency is Clary Coin, symbol CLARY, 18 decimals, on Base Sepolia, chain ID 84532. The contract address below comes from this site’s descriptor; the explorer provides the public chain record.
Loading the configured token address…
View the CLARY ledger on BaseScan →
| Component | Public identifier |
|---|---|
| DFT verifier | 0x02e872F14B7a4Db2c279754651595AEfCcEd92c1 |
| Publication batcher | 0x6AA589028F816Fcc67d327326f8a71b0f4700cD7 |
| ICP checker canister | sj2rm-xaaaa-aaaar-qciga-cai |
| Admitted Ethereum signing authority | 0xe16d96862ebcCE3BC99D05C1f07d15CAA7826df6 |
| Frozen checker module SHA-256 | 852610810df8e449b979adc221fe5e60da22f9450cb3a8ae54d06a871ab3d8fa |
The verifier version activates on October 21, 2026 at 21:22:52 UTC. Activation does not itself open a round. Its new-round admission window ends January 19, 2027 at 21:22:52 UTC; existing earned claims do not expire at that timestamp.
- Contract deployment observation · JSONExact transactions, runtime identities, and the initially empty ledger.
- Frozen checker observation · JSONCertified module, empty controllers, key identity, and dated subnet/capacity observations.
- Known DFT proof trial · JSONActual public checking and signature verification, with measurement limits.
- Verifier registration observation · JSONRegistration transaction, activation window, and readback.
- October 20 chain snapshot · JSONCommon finalized state from the two fixed RPC readers.
These files are selected observations with provenance, not an independent audit or a full light-client proof. The complete reproducible source and runtime release is still being prepared.
What the operator controls.
The token core has one owner address. It can schedule future rounds and prizes within immutable limits, add problems, register verifier versions with advance notice, pause new work, and permanently disable a verifier. Disabling can cancel unsettled rounds. The owner cannot seize balances, rewrite the issuance schedule, change an opened round’s prize, or redirect an established claim.
Future verifier selection is a strong authority. A malicious verifier could approve invalid research within the remaining budget. The current system therefore requires trust in the operator’s future configuration decisions. Two-step ownership transfer supports a future multisignature owner; there is no built-in community governance vote.
The selected ICP checker has no controllers, so the operator cannot upgrade it. ICP’s own network and governance assumptions remain. Checker renewal deploys and admits a separate version while preserving the currency ledger and family record.
Protection has a defined scope.
Sealed commitments fix the reward recipient before proof disclosure. Supported clients wait for their commitment and the cutoff in finalized history before sending proof bytes to ICP or the publication registry. The current policy checks two RPC providers; agreement is not a light-client proof. The contract does not enforce this off-chain waiting step.
This protects against copying a safely disclosed proof to create a new commitment in the same round. It does not eliminate censorship, premature disclosure, independent identical results, exceptional consensus failures, or improvements built from published work in later rounds.
Checker bugs, an incorrectly admitted theorem, compromised network assumptions, and invalid future verifiers can affect correctness. A finite sponsor-funded service can also run out of funds or be exhausted by hostile requests. The issuance ceiling limits token creation; it does not guarantee mathematical soundness, availability, market demand, or price stability.
Public records, private credentials.
Wallet addresses, transactions, published proofs, and contract state are public. A standard transaction does not publish an IP field, but RPC, hosting, AI, and payment providers can receive connection or account information. Public activity can also be correlated with external identities.
The participant does not send wallet keys, passwords, or its private commitment opening to the research model. Proofs become public after the protected cutoff. Never provide a seed phrase or wallet password to a site or project operator.
This site uses local assets and no added analytics service. That does not make your wallet, network provider, hosting provider, or browser extension anonymous. Future published packages will use a reviewed snapshot rather than private development history.