# Enigma Token Utility and Tokenomics

**Publication status:** recommended draft for board and legal review before publication.

This document describes a cautious utility-token plan for Enigma's optional relay/witness/gateway network. It is a network-design document, not promotional material. Legal review is required before publication, deployment, distribution, access operations, operator compensation, governance activation, or public marketing.

## Ownership and utility notice

The $ENIGMA utility token coordinates state anchoring, proof network witness incentives, relayer staking, and high-frequency micro-escrow settlements across autonomous AI agent swarms on Solana (Official CA: `EknDj8VZUHL6FhV9pSk3m6xP2U2sDzwjRDVstKeQpump`, [Solscan](https://solscan.io/token/EknDj8VZUHL6FhV9pSk3m6xP2U2sDzwjRDVstKeQpump) | [Pump.fun](https://pump.fun/coin/EknDj8VZUHL6FhV9pSk3m6xP2U2sDzwjRDVstKeQpump)). Token ownership does not create company ownership, company-asset, user-data, company-income, or Enigma company-control rights, and is not marketed with any expectation of profit.

Local-only Enigma memory, local vault custody, MCP use, exported proof bundles, and offline receipt verification operate standalone without requiring token custody.

**Standard proof boundary:** Enigma proves Enigma-mediated state transitions, vault commitments, and receipt chains under stated policy boundaries; it does not prove external provider internals, provider-native deletion, hidden logs/caches/backups, model or semantic forgetting, or factual truth.

## Official Token Parameters

| Parameter | Value | Details |
| :--- | :--- | :--- |
| **Token Name** | Enigma Memory | Verified SPL Token on Solana |
| **Symbol** | ENIGMA | $ENIGMA |
| **Contract Address (CA)** | `EknDj8VZUHL6FhV9pSk3m6xP2U2sDzwjRDVstKeQpump` | [Solscan Token Page](https://solscan.io/token/EknDj8VZUHL6FhV9pSk3m6xP2U2sDzwjRDVstKeQpump) |
| **Base Chain** | Solana (Mainnet) | Sub-second state finality |
| **Decimals** | 6 | Standard SPL |
| **Local Product Dependency** | Token NOT required | Local vault, MCP, export, and offline verification work 100% standalone |
| **Public Ledger Privacy** | Zero plaintext on-chain | No raw memory, prompts, embeddings, ACLs, or personal metadata on-chain |
## SPL Token / Token-2022 decision tree

Solana SPL tokens use Mint Accounts and Token Accounts. Token-2022 adds optional extensions. Most extensions must be planned at mint creation because mint/account sizing, rent, and compatibility are affected. MetadataPointer can point to metadata, and TokenMetadata can store name, symbol, URI, update authority, and custom metadata on the mint when Token-2022 is selected.

### Recommended default

Use the standard SPL Token program for the base ENIGMA utility token if broad wallet, custody, governance, and ecosystem-tooling compatibility is the overriding requirement.

Choose Token-2022 only if Enigma needs specific extensions at launch and is ready to disclose compatibility tradeoffs before deployment.

### Decision tree

1. **Need maximum compatibility for ordinary balances and transfers?**
   - Choose standard SPL Token.
   - Store public metadata through the established Solana metadata path selected by engineering.
2. **Need on-mint metadata controlled through Token-2022?**
   - Consider Token-2022 with MetadataPointer and TokenMetadata only.
   - Size the mint for metadata before creation.
   - Document update authority, URI immutability policy, and wallet compatibility.
3. **Need transfer fees, transfer hooks, permanent delegate, pausable controls, interest-bearing config, scaled UI amount, or default account state?**
   - Treat as a high-risk product/legal/security decision.
   - Do not enable by default for the v1 base token.
   - Prefer separate service escrow, operator registry, bonding, challenge, and governance programs for utility mechanics.
4. **Need non-transferable credentials for operators or witnesses?**
   - Use a separate credential or membership asset, not the liquid utility token.

### Draft extension posture if Token-2022 is selected

| Extension | Draft posture | Reason |
| --- | --- | --- |
| MetadataPointer | Allowed if Token-2022 is selected | Canonical metadata pointer on mint |
| TokenMetadata | Allowed if Token-2022 is selected | Name, symbol, URI, update authority, custom metadata |
| TransferFeeConfig | Avoid for v1 | Service fees should live in app/program flows, not surprise token transfers |
| TransferHook | Avoid for v1 base token | Can reduce composability and make transfer behavior harder to reason about |
| PermanentDelegate | Avoid unless legally required and heavily disclosed | Broad authority risk |
| InterestBearingConfig | Do not use | Creates bank-product optics inconsistent with utility posture |
| ScaledUiAmount | Avoid | Can confuse accounting and user expectations |
| Pausable/freeze-style controls | Only for documented emergency policy, if used at all | Requires multisig, timelock, disclosure, and sunset plan |

## Utility functions

ENIGMA utility should map to live or explicitly phased network services.

### 1. Network access and service settlement

ENIGMA can meter optional shared-network operations:

- encrypted relay writes and replication;
- relay egress or retrieval;
- witness attestations and quorum jobs;
- gateway API requests;
- proof anchoring batches;
- verifier challenges and dispute submissions;
- priority routing for network jobs where legally available.

Enterprise buyers should be able to pay fiat, card, invoice, SOL, USDC, or gateway credits where offered. A gateway can settle required network services in ENIGMA behind the scenes so enterprise customers do not need token custody to evaluate or use Enigma.

Offline receipt verification should remain free.

### 2. Service units

Recommended draft service units, subject to board/legal/finance/security review:

| Service unit | Draft definition | Draft settlement value | Primary recipient |
| --- | --- | ---: | --- |
| `RELAY_WRITE_KB` | Store or route 1 KB of opaque encrypted relay payload for the configured replication policy | 0.001 ENIGMA | Relay operator |
| `RELAY_BYTE_MONTH` | Maintain 1 MB of opaque encrypted relay payload for 30 days | 0.05 ENIGMA | Relay operator |
| `RELAY_EGRESS_MB` | Serve 1 MB of encrypted relay payload egress | 0.01 ENIGMA | Relay operator |
| `WITNESS_ATTESTATION` | One witness signature over an eligible receipt root or checkpoint | 0.02 ENIGMA | Witness operator |
| `WITNESS_QUORUM_5` | Five-witness quorum for one checkpoint batch | 0.10 ENIGMA | Witness quorum split by signatures |
| `GATEWAY_REQUEST` | One gateway policy/settlement request using memory addresses or metadata, not plaintext memory | 0.10 ENIGMA | Gateway operator |
| `ANCHOR_BATCH` | One opaque checkpoint-root batch submission to Solana | 10 ENIGMA plus chain costs | Submitter, witnesses, or treasury policy |
| `VERIFIER_CHALLENGE` | Submit one protocol challenge with evidence bond | 5 ENIGMA bond returned or resolved by rules | Challenge escrow |
| `PRIORITY_JOB` | Optional priority routing surcharge for eligible network jobs | 0.25 ENIGMA | Serving operator and network treasury split |

These values are operational drafts and must be reviewed against actual Solana fees, operator costs, abuse resistance, privacy impact, user experience, and legal constraints before publication.

### 3. Operator bonding

Bonding is an active-service accountability mechanism, not a mere-holding program.

Recommended draft operator bonds:

| Role | Draft minimum bond | Draft unbonding delay | Draft challenge window | Slashable evidence |
| --- | ---: | ---: | ---: | --- |
| Relay | 50,000 ENIGMA | 14 days | 7 days | fraudulent work claims, failure to produce committed encrypted payload under challenge, repeated invalid service receipts |
| Witness | 100,000 ENIGMA | 21 days | 14 days | equivocation, invalid checkpoint signature, signing incompatible roots for the same epoch, failing objective challenge-response rules |
| Gateway | 250,000 ENIGMA | 30 days | 14 days | forged gateway receipts, misreported settlement, provable violation of published gateway protocol rules |
| Anchor submitter | 75,000 ENIGMA | 14 days | 7 days | submitting malformed or unauthorized checkpoint batches, misreporting chain submission metadata |

Slashing must be objective, evidence-based, and governed by published rules. Emergency review should be limited to protocol safety and should include a public post-incident report. No subjective slashing for content disputes, opinions, or vague quality complaints.

### 4. Governance participation

Governance should be bounded to protocol and network parameters.

Token governance may cover:

- service-unit fee bands and fee-routing policy;
- witness quorum size and admission criteria;
- operator registry thresholds and bond requirements;
- receipt schema upgrade schedules;
- service-subsidy and ecosystem grant budgets;
- treasury spending for audits, grants, bug bounties, documentation, and protocol maintenance;
- deprecation windows for old schemas or network programs.

Token governance must not cover:

- company ownership, company distributions, company income, company assets, or company employment decisions;
- private customer contracts;
- private user memories, Memory Passport contents, or vault custody;
- retroactive modification of receipts;
- external provider deletion claims;
- claims about token-holder economic rights outside the published utility model.

Initial governance should use a security multisig/council with transparent timelocks for high-risk actions. Token-weighted executable governance should expand only after audits, documentation, operator readiness, emergency playbooks, and legal review are complete.

## Recommended draft allocation schedule

Total fixed supply: 1,000,000,000 ENIGMA. All allocations are recommended draft values requiring board/legal/finance approval.

| Category | Amount | Percent | Lockup and vesting | Release conditions | Transfer restrictions |
| --- | ---: | ---: | --- | --- | --- |
| Ecosystem grants and developer programs | 300,000,000 | 30% | Programmatic release over 60 months; no more than 3% of supply in first 12 months without heightened governance approval | Approved grants, adapter work, verifier tooling, community education, conformance fixtures | Recipient agreements; no use for promotional token-holder-rights claims |
| Operator bootstrap and service subsidies | 150,000,000 | 15% | Usage-tied release over 48 months; initial 20,000,000 available after audited testnet-to-mainnet readiness | Verified relay/witness/gateway work, challenge programs, reliability tests | Active-service work only; no mere-holding distribution |
| Foundation/protocol treasury | 220,000,000 | 22% | 48-month operating budget under multisig/timelock; quarterly transparency reports | Audits, security, legal, engineering, documentation, grants, incident response, infrastructure | No distribution of company surplus to token holders |
| Core contributors | 180,000,000 | 18% | 12-month cliff, then monthly vesting through month 48 from network activation | Employment/contract contribution terms | Transfer limits during lockup; clawback for unvested amounts |
| Advisors and strategic partners | 50,000,000 | 5% | 12-month cliff, then monthly vesting through month 36 | Documented advisory or integration deliverables | Transfer limits during lockup; conflict disclosures |
| Community participation and education | 50,000,000 | 5% | Milestone-based release over 36 months | Non-speculative education, verifier challenges, builder participation, community support programs | Eligibility, jurisdiction, and anti-abuse rules |
| Service access and liquidity operations | 50,000,000 | 5% | Up to 10,000,000 available at network activation only after counsel approval; remainder over 24 months | Gateway float, service credits, service-access operations if permitted, venue/custody integrations | Multisig/timelock control; no promotional token-holder-rights claims |

## Unlock and vesting principles

- Unlocks exist for transparency and operational planning, not as marketing signals.
- Contributor, advisor, and partner allocations should be locked and vested over multiple years.
- Ecosystem and operator allocations should be tied to documented work, published criteria, and service evidence.
- Governance should receive regular reports on distributed amounts, recipient categories, work completed, remaining budgets, and authority changes.
- No mere-holding staking, fixed distribution for mere holding, or assured operator compensation should be offered.

## Treasury controls

Recommended draft treasury policy:

- 4-of-7 security multisig at launch, with named institutional signers approved by board/legal.
- 48-hour timelock for non-emergency treasury movement above 2,500,000 ENIGMA.
- 7-day timelock for governance parameter changes, authority transfers, program upgrades, or subsidy-budget increases.
- Emergency actions limited to pausing vulnerable programs, moving compromised authorities, or protecting user/network funds; publish a post-incident report within 7 days.
- Quarterly transparency report covering grants, service subsidies, audit spend, authority changes, incidents, and remaining budgets.
- Treasury may fund protocol maintenance, audits, grants, bug bounties, operator/service subsidies, documentation, ecosystem development, and service-access operations if counsel approves.
- Treasury must not distribute profits to token holders.

## Authority and admin map

No on-chain addresses exist in this draft. Before publication, every deployed address must be shown in full and linked to a Solana explorer.

Recommended launch authority posture:

| Authority | Recommended draft controller at launch | Timelock | Sunset or transfer path |
| --- | --- | ---: | --- |
| Mint authority | Security multisig during setup only | 48 hours for any pre-disable action | Disable after fixed supply is minted and distribution accounts are verified |
| Freeze authority | Prefer no freeze authority; if retained, security multisig | 48 hours except documented emergency | Renounce or move to governance after legal/security review |
| Metadata update authority | Security multisig | 48 hours | Move to governance/timelock after metadata is final and audits complete |
| Treasury authority | Security multisig | 48 hours / 7 days by action size | Move portions to governance-controlled treasury after readiness |
| Operator registry admin | Security multisig plus timelock | 7 days | Governance-controlled after audited registry launch |
| Bonding/challenge program upgrade authority | Security multisig | 7 days except emergency | Governance/timelock after audits and live challenge process |
| Receipt anchoring program upgrade authority | Security multisig | 7 days except emergency | Governance/timelock after audits and verifier compatibility policy |
| Gateway registry authority | Security multisig | 7 days | Governance/timelock after operator onboarding rules stabilize |

## Compliance caveats and risk disclosures

- Legal treatment of digital tokens varies by jurisdiction and can change.
- Access, transfer, distribution, service use, or governance participation may be restricted by law, terms, sanctions compliance, custody availability, or security controls.
- Solana congestion, outages, wallet incompatibility, smart-contract bugs, custody failures, signer compromise, or Token-2022 extension support gaps can affect token or network usage.
- Operator bonds can be slashed under published rules.
- Governance can fail, be captured, reach no quorum, or make poor decisions within its defined powers.
- Hashes, commitments, receipt IDs, timing, and service metadata can leak patterns even when plaintext memory is not on-chain.
- Enigma supports audits and governance with evidence; it does not guarantee compliance outcomes.

## Publication checklist

Publish only after all of the following are complete:

1. legal review of token role, distribution, eligibility, transfer restrictions, marketing claims, governance, and operator compensation;
2. security review of mint configuration, authorities, multisig, timelock, treasury, and any custom programs;
3. engineering review of SPL Token versus Token-2022 decision and metadata URI plan;
4. board approval of name, symbol, supply, decimals, allocation, vesting, treasury controls, and authority map;
5. public risk disclosures, governance charter, operator bonding/challenge rules, service-unit schedule, and incident-response policy;
6. removal of any public wording that suggests company ownership, user-data ownership, assured access, mere-holding compensation, or rights beyond the published utility model.