The TORA field guide.
Protocol & CLI.

TORA, from wallet to verified work.

TORA is a SHA-256 CPU mining protocol on Elysium. Hold at least 5,000,000 TORA in your wallet, authenticate with a wallet signature, and run the local miner. The API verifies submitted work and records accepted shares in SQLite.

Your token balance provides access. Your CPU performs the work. Tokens stay in your wallet without staking. Mining does not create new tokens or change the fixed ERC-20 supply.

Before the token contract is configured, a wallet can connect and show its address. “Mining activates after token launch” means mining access is deliberately disabled. It is not an estimate of a launch date or earnings.

How Hold-to-Mine fits together.

1. Wallet: MetaMask or another injected EVM wallet supplies your address and signs a login message.
2. Eligibility: the Node.js API reads the configured token contract’s balance and decimals over Elysium RPC.
3. Compute: a Node.js CLI searches SHA-256 nonces on your CPU using short-lived challenges.
4. Verification: the API recomputes each proof, checks difficulty and eligibility, and accepts each challenge once.
5. Accounting: SQLite stores miners, sessions, accepted shares, reward balances, payout batches and transaction history.

The MVP uses one API and one database. It does not implement on-chain mining settlement or a new mining smart contract. Reward transfers use the existing ERC-20 contract after treasury approval.

Start with a wallet and a computer.

1. Install Node.js 22.13 or later. Open a terminal in the TORA project directory; these commands run from the source project, not a standalone published package.
2. Use an operator-provided API and frontend, or start a local instance using the operator instructions below.
3. Open Mine, connect your wallet, and select Elysium. Confirm the network shown by your wallet.
4. After launch configuration is ready, hold at least 5,000,000 TORA and sign the login nonce. Copy the CLI login command from Mine or Dashboard.
5. Run that command, check your session, then start a single-share mining run before continuous mining.

npm install
npm run miner -- help
npm run miner -- login --api http://127.0.0.1:8787/api --token <SESSION_TOKEN>
npm run miner -- status
npm run miner -- mine --once

Replace <SESSION_TOKEN> with your own signed session credential. Replace the loopback API URL with the operator’s verified API URL when using a hosted service. Never paste a session token into public chat.

Connect first. Sign in to mine.

Wallet connection and mining authentication are separate steps. Connecting shares your public address with the site. Authentication requests an EIP-191 message signature; it does not request a token transfer, staking approval or private key.

The API generates a random login nonce and a message containing the address, Elysium network name and origin. The nonce expires after five minutes and can be used once. The API recovers the signer from the signature, verifies it matches the requested address, and checks token eligibility before issuing a bearer session.

Read the wallet message before signing. A prelaunch wallet connection alone does not establish a CLI mining session. If the nonce expires or the wallet account changes, request a fresh login.

The 5,000,000 TORA requirement.

Eligibility requires at least 5,000,000 TORA in the authenticated wallet on Elysium. The API uses balanceOf(address) and the deployed token’s decimals, not a displayed browser balance or a user-supplied number.

Checks happen at authentication, when a challenge is requested, and when a valid proof is submitted. If the balance falls below the threshold, further work cannot be accepted. Moving tokens between wallets does not transfer a mining session.

No tokens are locked or staked. An unset contract, a contract address without code, an RPC network mismatch or an unverifiable balance prevents mining access. A connected wallet address is not proof of eligibility.

Run the CPU miner.

The worker runs locally on your CPU. It is not a browser miner and has no GPU configuration, hardware purchase requirement or implemented thread-count option. Mining can increase CPU load, heat and electricity use. Stop it when you need the machine for other work.

The CLI stores credentials in ~/.tora/config.json, or %USERPROFILE%\.tora\config.json on Windows. TORA_MINER_CONFIG overrides that path; TORA_API_URL changes the default API endpoint. Protect the file using your operating system’s user permissions.

What counts as a verified share?

A challenge contains a random identifier, random challenge bytes, a difficulty in leading zero bits and an expiry timestamp. It belongs to the authenticated session. The CLI tries non-negative decimal nonces until the digest satisfies the requested difficulty.

SHA256("tora-sha256-v1|" + challengeId + "|" + challenge + "|"
  + address.toLowerCase() + "|" + nonce)

The API accepts a decimal nonce string of 1–78 digits. It recomputes the digest itself; the miner cannot claim a result by submitting a made-up hash. A share must meet the challenge’s stored difficulty, belong to the same session, remain unexpired, and pass a fresh token-balance check.

Difficulty is measured in bits, not hexadecimal characters. A challenge with d leading zero bits has an expected search cost of 2^d hashes. This is a statistical expectation, not a guaranteed number of attempts or a measured CPU benchmark.

Acceptance consumes the challenge atomically alongside the share and reward records. Unique constraints block reused challenges and duplicate proofs. Invalid, expired and replayed submissions do not earn accepted shares. The CLI requests a new challenge when its current challenge expires.

Manage access to your miner.

A session is a bearer credential associated with a wallet and an expiry. The server stores its hash. The sample session lifetime is 24 hours; operators can configure it. Login nonces, mining challenges and mining sessions have separate lifetimes.

The CLI checks session status before mining and authenticates every challenge and submission. Expired or revoked sessions must sign in again. Stopping the CLI with Ctrl+C stops computation but does not revoke the session.

Use the Dashboard’s revoke control when finished or if a credential may have leaked. Keep the browser session and CLI configuration private. A session token cannot sign wallet transactions, but it can authorize API mining actions until revoked or expired.

From accepted shares to reward balances.

When verified token information and valid accrual settings are available, each accepted share contributes work weighted by its challenge difficulty. The configured rate is a decimal TORA amount per expected SHA-256 work unit.

workWeight = 2 ^ difficultyBits
computedReward = configuredRatePerWork × workWeight
creditedReward = min(computedReward, remainingDailyCap)

Here ^ denotes exponentiation. The implementation uses integer arithmetic in the token’s smallest units and reads token decimals from the contract. If the daily cap is exhausted, an accepted share can credit zero TORA. Disabled accrual also credits no token rewards. There is no automatic retroactive reward promise for earlier work.

Accrual is an API ledger entry, not an immediate wallet payment. Actual payout requires the minimum payout amount, available treasury funds and an approved transfer. No fixed rate or guaranteed earnings is published by this documentation.

A finite treasury, not newly minted supply.

The intended initial mining treasury is 5% of the fixed TORA supply, acquired through a project-approved developer buy and held in a dedicated Elysium wallet. This is a launch funding plan, not a claim that the buy or funding has already happened.

The API does not buy tokens, mint tokens, stake balances or fund the treasury. Operators must independently confirm the allocation and fund the configured wallet. Rewards are transfers of existing treasury tokens; mining does not expand the token supply.

TORA_DAILY_EMISSION_CAP limits newly accrued TORA across this API database per UTC calendar day. Despite its name, “emission” here means reward accounting, not minting. The last credited share can be reduced to the day’s remaining allowance.

The daily cap controls accrual, not the amount of previously earned rewards that may be paid that day. Treasury balance checks apply when creating and approving payout batches, including existing reservations. These checks do not automatically replenish funds or guarantee that every accrued balance is immediately payable. Operators must monitor the finite treasury and set sustainable parameters.

Review, approve and sign payouts.

The Dashboard includes a restricted payout workflow for configured administrators. Ordinary miners do not need admin access. The treasury address must be included in the configured admin addresses; approval and transaction signing require the treasury wallet.

1. Authenticate: connect the authorized Elysium wallet and sign the admin login message.
2. Generate a draft: eligible unallocated reward balances meeting the payout minimum become batch items. The API checks treasury coverage and reserves the source accruals atomically.
3. Review: inspect every recipient, exact token amount, token contract and treasury address before approval.
4. Approve: the treasury wallet approves the batch through the API workflow, with treasury coverage checked again.
5. Execute: sign each ERC-20 transfer in MetaMask using the treasury wallet. This is a real transaction and requires the network’s native gas token.
6. Reconcile: submit the transaction hash for API verification. A successful matching receipt must be confirmed before the ledger marks the item paid.

Batch creation uses an idempotency key. Reward allocations, transaction hashes and payment records have duplicate protections. If a receipt is unavailable, the item stays pending. A confirmed failed receipt releases the source accruals for a later batch.

If MetaMask submission is ambiguous, recover and reconcile its transaction hash before retrying. A transaction may have reached the network even if the browser reported an error. Do not sign a replacement payment blindly. No private key or seed phrase is sent to the API.

Read your work and the network record.

Aggregate hashrate is unavailable because the MVP does not measure every miner’s attempted hashes. Mining rounds are unavailable because protocol round settlement is not implemented. Illustrative hero diagrams do not represent live telemetry.

An unavailable value is not zero. Token reward fields require verified reward configuration; payment history requires confirmed receipts. Follow Dashboard, Network or Leaderboard for actual connected records.

Keep wallet control and credentials separate.

• Use the verified TORA site, API endpoint and contract information. This documentation intentionally contains no invented token or treasury address.
• Never share a seed phrase, private key or bearer session. A miner login uses a message signature; a treasury payout uses a separately reviewed transaction.
• Verify Elysium chain ID 99901 in your wallet. The API must also verify its configured RPC network and token contract code.
• Protect the SQLite database and back it up. Reward accounting, reservations and idempotency depend on this persistent record; independent API databases do not share a global cap.
• Keep the API loopback-only for local use. Public hosting needs HTTPS, exact allowed frontend origins, request limits and operational monitoring.
• Revoke exposed sessions promptly. Anti-replay and atomic accounting protect the implemented workflow, but this MVP should not be described as an audited protocol.

Common questions.

Find the next useful step.

Local setup and operator reference.

Run from the project directory with Node.js 22.13 or later. Copy the sample environment file, then enter verified deployment values. Keep secrets and the database out of public hosting artifacts.

npm install
# PowerShell
Copy-Item .env.example .env
# Edit .env, then use separate terminals:
npm run api
npm run dev

The local site is http://127.0.0.1:3100; the default API base is http://127.0.0.1:8787/api. Sample difficulty and lifetimes below are configuration defaults, not live network measurements.

API routes

Authenticated miner routes use Authorization: Bearer <SESSION_TOKEN>. Wallet authentication is signed in the browser. Do not put session tokens in URLs.

npm run miner -- help
npm test
npm run build
npm run typecheck

Tests use deterministic wallets and a local EVM chain with a test-only ERC-20. They cover authentication, invalid proofs, expiry, replay, difficulty-weighted accrual, caps, treasury limits, failed transfers and duplicate prevention. They do not fund the live treasury or broadcast Elysium payouts.