Blog
[design] 100% of TRI is mined by accepted .t27 work with zero pre-mine; the mint-on-acceptance rule is a Zig golden oracle (11/11 tests) with a TON and Solana minter whose digest matches cross-language (cargo test 4/4). Nothing is deployed.
The design question a token forces is who gets the first coins for free. The usual answer is a pre-mine: a founder allocation, a treasury, a liquidity reserve, all minted at deploy. We deleted that. One hundred percent of TRI is mined by accepted work. At genesis the minted supply is zero, and the only way a TRI comes into existence is that a verifier accepted a .t27 spec or a node returned a correct, receipt-backed job.
This is not a marketing stance. It is what makes the token honest rather than speculative, and it changes the legal picture: there is no sale, so there is no buyer handing over money in expectation of profit. The closest precedent — the original Gram token on this same network — was killed by the SEC precisely because it was sold. TRI is not sold. It is panned.
A blockchain cannot run t27c. So the chain cannot itself check that a spec was accepted. Every honest design for minting-on-work is therefore about who the chain trusts to say the work happened, and how wrong that party can be. We refused to paper over this. The trust model is versioned, weakest-but-shippable first, and labelled for what it is.
| Version | Mechanism | Trust assumption |
|---|---|---|
| V1 attestor quorum | M-of-N signatures are the only mint authority | an honest majority of the attestor set — not trustless |
| V2 optimistic | mints after a challenge window unless a fraud proof is posted | at least one honest challenger, plus a bond |
| V3 receipt proof | a succinct proof of acceptance, verified on-chain | the proof system only |
V1 is what ships first, and it is only as decentralised as its attestor set. We will say that in public, and never say "trustless". The FPGA path may reach V3 sooner than the software path, because a board already signs its result, and checking a signature on-chain is far cheaper than proving a compiler run.
The mint rule is a golden oracle in Zig: it verifies M-of-N real ed25519 signatures over the attestation digest, refuses a spent nonce (no double-mint, including across chains via one shared nonce set), and refuses a mint that would cross the 3^21 cap. It is tested with real keys and real signatures, so the security properties are executed, not asserted in prose.
All 11 tests passed.
genesis minted supply is zero
a valid M-of-N quorum mints exactly the amount
a sub-quorum / repeated / non-attestor signature mints nothing
a spent nonce is refused — no double-mint
the same global nonce cannot mint on a second chain
a TON quorum does not authorise a Solana mint
a mint over the cap is refused and consumes no nonce
digest matches the cross-language golden vectorThe two chain minters — a TON jetton contract and a Solana program — must reproduce that oracle exactly. The Solana side is verified host-side with cargo test: the attestation digest is byte-identical across Zig, Python and Rust (one golden vector, 9ce2cee5…), and the Ed25519 instruction parser and quorum count behave as the oracle does. A divergence is a bug in the contract, not the oracle.
To test whether the quality gap between full-precision and ternary weights narrows with dataset scale, we completed a controlled twin experiment: two identical 100M parameter models (pair_fp in FP16 and pair_tern in BitNet b1.58 ternary), trained on the exact same 10.0 billion tokens of code.
| Model | Precision | Tokens | Val Loss | Val BPB |
|---|---|---|---|---|
| pair_fp | FP16 (16-bit) | 10.0B | 1.1354 | 0.4217 |
| pair_tern | Ternary {-1,0,1} | 10.0B | 1.2718 | 0.4722 |
The ternary model achieves 0.4722 bits/byte on held-out code streams — a tight +0.0505 bpb gap (+12.0% loss) against FP16 at full 10B token scale, while running purely on additions rather than matrix multiplications.
Nothing here is deployed. No contract, key, or mint exists on any live network. The reference contracts are unaudited. Whether the attestor quorum is honest is a governance choice nobody has made yet, and the compliant issuance path — a foundation entity, counsel, the treatment of secondary trading — is the first task this decision creates, not a thing it settles. The token funds no development: development is funded by hardware sales and grants, and the team earns TRI the same way everyone does, by getting its work accepted.
Work with me
I work contract and part-time on hardware-AI, FPGA/RTL and ML systems — from specification and open toolchains to reproducible measurements.