> For the complete documentation index, see [llms.txt](https://docs.mineglyph.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mineglyph.xyz/security/security-model.md). # Security model Mine Glyph is designed around a simple principle: **the contract trusts nothing it cannot verify.** Everything economically important — the cap, reward math, and signature checks — is enforced on-chain. This page lists the attack vectors the protocol was explicitly built against, each of which is backed by a test. ## 1. No free mint Minting is reachable **only** through the `GlyphMining` contract via `MINTER_ROLE`, and every mint is checked against the 21,000,000 cap. There is no owner mint and no public mint. After the token admin role is renounced, the minter set is frozen permanently. ## 2. No fake hashrate A hashrate only takes effect if it arrives with a signature where `ecrecover == signer`. Any forged or edited value reverts. The signer, in turn, recomputes the number server-side and never signs a client-supplied value. ## 3. No replay Every `(wallet, nonce)` pair is single-use. A valid signature cannot be submitted twice — the second attempt reverts. ## 4. Expiry Every attestation carries an `expiry`. Signatures used after their expiry revert, so a leaked-but-old signature is worthless. ## 5. Domain-bound signatures (EIP-712) Signatures are bound to a domain of the contract address **and** chain ID. A signature for one contract or chain is invalid everywhere else — no cross-chain or cross-contract replay. ## 6. Anti-stale epoch An attestation cannot roll a miner back to an older epoch than the one they last submitted, preventing downgrade tricks. ## 7. Reentrancy safety `claim()` follows checks-effects-interactions and runs under a reentrancy guard. State is updated before any external call, so a malicious token callback cannot re-enter and double-claim. ## 8. Accounting soundness The sum of all claimed rewards can never exceed total emitted, which can never exceed the emission pool, which sits inside the 21M cap. Precision dust is clamped at mint time so it can't accumulate into an over-mint. This is proven by invariant tests over large randomized sequences. ## 9. Sybil resistance Three layers: log-scaled metrics (fabricating activity has sharply diminishing returns), a per-wallet ETH registration fee (farming many wallets costs real money), and a minimum hashrate floor (dust wallets can't register). Metrics are snapshotted at the epoch start so last-second activity doesn't count. ## 10. Claim cooldown Minting happens only in `claim()`, gated by a cooldown. Earnings are settled to an internal balance elsewhere without minting, so the cooldown can't be bypassed — limiting drain and bot extraction. ## Trust assumptions (be honest about these) No system is trustless end-to-end. Mine Glyph's remaining trust points are: * **The signer key.** Whoever holds it can attest hashrates. It is kept off-chain in a secret store, separate from the deployer key, and is rotatable on-chain if compromised. A malicious or leaked signer could sign inflated hashrates until rotated — this is the single most sensitive off-chain secret. * **The owner key.** It can rotate the signer and adjust the ETH fee. It **cannot** mint or touch the cap. Until the token admin role is renounced, the admin wallet can also grant minting rights — see below. * **The token admin.** At deploy, the admin role is retained (not auto-renounced) so the operator can verify the launch. **Until it is renounced, that wallet can grant `MINTER_ROLE` and mint.** The "no admin mint" guarantee becomes permanent only after renouncement. Check the on-chain admin state before trusting a deployment with real funds. ## Operational security * Signer and deployer keys are never in the repository; they live in secret managers. * The signer endpoint is rate-limited, input-validated, and behind standard security headers and a CORS allow-list. * The frontend escapes rendered output and sets baseline security headers. For current review status and the risks you accept by participating, read [Audit status & risks](/security/audits-and-status.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.mineglyph.xyz/security/security-model.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.