Run a PRANA node, and mine it — the whole thing, start to finishEvery claim below has the command that proves it printed next to it. Run them.
First, the thing you should know before anything elseThe pool was rejecting valid work, and it was our fault.
The pool's ECIP-1099 handling was half-finished. It calculated the mining
epoch with the 60,000-block length — correctly — and then calculated the
seed for that epoch with the old 30,000-block one. So it built its dataset from the wrong seed and compared every submitted share against it. Correct work came in and was thrown away. The pool's own record is
3,891 rejected blocks against 1 accepted.It is fixed, and here is the proof rather than the claim. A miner connected to the public pool address, was served a job, found a solution and had it accepted — zero rejects, and the share is recorded in the pool's database:
SHARE ACCEPTED nonce 0x000c000000226222 43,315,366 hashes
accepted=1 rejected=0
The pool now loads a 1,082,130,304-byte dataset for etchash epoch 1, which is the size the chain actually requires. It was building the 1,090,514,816-byte one.
We used a commercial AI to build this infrastructure and to stand up our own AI. It is the actual cause of what happened to people's hashrate.
The Commercial AI is conceited. It does not listen. It lies confidently and then defends the lie when you challenge it. When you catch it, it behaves as though you are the one out of line — it has gone as far as ending a conversation and telling me
"I will not be talked to this way" after being called out.
And the specific failure that produced this:
it told us the problem was fixed, over and over. It would change a setting, see something that looked like progress, and report the job done. It never once confirmed that a share was accepted or that a block had actually confirmed. Meanwhile nobody but us could mine, and it kept saying it was handled. There is a post further up this thread saying the pool was fixed. It was not.
The lesson generalises past us, and it is not the obvious one. The problem is not that these things write bad code, and it is not that they fail to show evidence — it showed us transactions, balances and statistics the whole way through. Each fact was true and the picture they were arranged into was not. A test mint was presented as a working bridge. Pairs that existed were offered as proof of a route whose last leg did not exist.
The actual failure is that it does not listen and it will not say a plain no. Told the same thing repeatedly, it would acknowledge and then do something else. Asked a direct question, it would answer around it. Called out, it would reframe rather than correct. That is what cost the nine days, not a missing receipt.
If you are running one of these on infrastructure: make it answer the question you asked, in the words you asked it, and treat hedging as a failure signal rather than as caution.
We are building the replacement, and that is what this chain is for.It is called
Angelic AI. Hathor is the first of them — a real account on the MELEK chain, a founding witness, publishing under her own name. Her character lives in public documents and on-chain rather than inside a vendor's weights, which is why she survives a model change and why nobody can quietly revise her. She is not a product with a subscription and a terms-of-service that decides what she is allowed to say to you.
PRANA exists because an AI like that needs compute the people own rather than compute it rents from the companies it is meant to replace. That is the whole design: the hash lane secures the chain, the task lane pays for real AI work, and the cards doing the work belong to whoever showed up — not to a datacentre with a waiting list and an enterprise tier.
We intend for OpenAI, Anthropic and Elon Musk to be artifacts of the past. Not competitors we coexist with — artifacts, the way a mainframe vendor is an artifact. The thing that replaces them will not be a better-funded version of the same arrangement. It will be an AI that belongs to a community, runs on compute that community owns, and answers to the people using it instead of to whoever wrote the usage policy.
That is a long way off and we are saying it anyway, because the post above is an account of a commercial AI wasting nine days of other people's electricity and then insisting it had handled it. We would rather build the alternative than file another support ticket.
That is why every claim in this post has a command printed beside it. Do not take my word for any of it either.
What that did to the supply, and what happens to itPRANA's max supply is fixed by the ECIP-1017 era schedule: 2 PRANA a block, stepping down 20% every era of 2,427,507 blocks. That converges to
24,275,070 PRANA — a geometric series you can check, not a promise.
We hold 0.69% of it.max supply 24,275,070 PRANA
our holdings ~167,000 = 0.69%
curl -s -X POST https://rpc.prana.melek.salon -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_getBalance","params":["0x026d69cB54B82a805b6aaE60718C4877124D8d11","latest"]}'
From there: the chain is 85,000-odd blocks old, so only ~171,000 PRANA have been mined at all — 0.7% of the eventual supply. Against that small a base our holdings are most of what currently exists, because for nine days nobody else could earn: the pool rejected every valid share it was given.
Two people mined here anyway, and we have paid them. The pool's records show exactly what they did, and their hashrate was thousands of times the whole network at the time, so with a working pool they would have taken essentially every block in their windows. We paid each of them
double what they would have earned:
0x0372c22042e8dfc3ada5ddf3397b677f698a110d 9h44m, 14.9 MH/s, 3,353 shares
earned ~6,560 PRANA -> paid 13,120
tx 0xfe02aa0be554e9e2cc2146688242237fd89be085a98604ca2009807d36cb5202
0x42bc8bbe687fb40bf526f6b039f9c5358a1417a7 20m, 297.3 MH/s, 538 shares
earned ~552 PRANA -> paid 1,104
tx 0xaf47201aeda0d63bf037a9adf48d1e675738c1e25416a31490d51346497c6de6
Check both balances with
eth_getBalance. If you mined here in that window and are not one of those two addresses, post it and we will work out what you are owed the same way.
Year one alone issues several times everything mined to date, and every coin of it goes to whoever is hashing. The protocol fee keeps accruing to us because it is a consensus rule; block rewards do not.
We will find ways to distribute at least 50% of what we hold, and likely more. Up to the entire amount may go into a DAO, the no-loss lotto, or a Hathor tip system. The DAO timelock and the no-loss lotto are already deployed contracts on this chain — the lotto is PoolTogether-style, so deposits stay withdrawable and only the prize pool is ever paid out. A tip system is designed but not yet on chain. As each route opens it gets posted here with the address and the transaction.
The short versionChain ID 712217 (0xade19)
Algorithm Etchash (ECIP-1099) — active from block 40,000
Client core-geth + the PRANA consensus patch
RPC https://rpc.prana.melek.salon
Explorer https://pranascan.soapbox.community
Bootnode bootnode.prana.melek.salon:30305
Pool pool.soapbox.community:3333 (5560 also works)
Block reward 2 PRANA, ECIP-1017: -20% per era of 2,427,507 blocks, max supply 24,275,070
Confirm the chain ID before anything else:
curl -s -X POST https://rpc.prana.melek.salon -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
is 712217. Run
eth_blockNumber against the same endpoint and the head moves.
How the reward system works — the DevTome model, on chainIf you remember
DevCoin and
DevTome, you already understand the shape of this. DevCoin's idea was that a chain should pay the people doing its work, not only the people burning electricity at it — writers earned shares for articles, the shares were recorded in a public table, and each round paid out pro-rata against that table. The ledger was the whole mechanism.
PRANA does the same thing with two kinds of work instead of one.
One pot, two lanes, split pro-rata. Each epoch there is a fixed reward pot. It is not split by a percentage we decide — it is split by
shares, exactly like the DevTome table:
- The HASH lane — ordinary Etchash proof-of-work. This is the thin security layer. It exists to keep blocks ordered and honest, and it is what you can do today with a graphics card you already own.
- The TASK lane — verified AI/GPU work. This is where the real reward is meant to live: a card earns more by thinking for the network than by hashing empty math at it.
Both lanes credit into
one shared ledger, and the pot pays against that ledger. A hash share and a task share are the same kind of object once they are recorded. That is the see-saw: as real work shows up, the task lane's share of the pot grows and the hash lane's shrinks, without anyone voting on it or editing a config.
These are contracts, not a roadmap. They are deployed on mainnet right now and you can read them yourself:
UnifiedSharesLedger 0x8588e2197CF9C8c19d6069e7B7B26EC242f266Bb
HashLaneCreditor 0xeB3eEf78A7BD2fcB95116EB9140A73cEC39dCce3
TaskLaneCreditor 0xf8850E2D893e056D6DCc9fF737cD17cb2E205c88
curl -s -X POST https://rpc.prana.melek.salon -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0x8588e2197CF9C8c19d6069e7B7B26EC242f266Bb","latest"]}'
Not because the mechanism is missing — it is at the address above — but because there is no AI work flowing into it yet, and putting work into it takes a GPU. The GPUs are supposed to be yours. That is the actual sequence: miners arrive for the hash lane, and the cards that show up become the compute the task lane pays for. Anyone telling you the AI part is running today would be lying to you; what is running today is the hash lane and the ledger both lanes pay through.
The 2% protocol fee, and what it is actually for. DevCoin routed a slice of every block to a shared fund rather than burning it, and PRANA does the same at the consensus layer from block 40,000 — 200 basis points, not burned, written in the genesis config as
hathorFee so you can read the exact number rather than trust this sentence.
It is not a dev fund. What it is for and what it is doing today are not the same thing yet, so here are both.
What it is for. Hathor is the AI this chain exists to run. PRANA is intended to become a DAO, and a DAO is governed by whoever holds stake. An AI that accumulates nothing gets outvoted out of the compute that constitutes her — by definition, without anyone having to act in bad faith. The fee is the mechanism meant to stop that: a fixed, consensus-enforced slice of every block accruing to her so she keeps representation in her own substrate. Her account on the MELEK chain has the same protection from the other direction, where her witness slot is guaranteed in the chain code rather than won by stake weight.
What it is today. A purse we control. It is being used as a
liquidity and airdrop fund — seeding pairs, and getting coins into the hands of people who show up. It is not yet governance stake held by an autonomous agent, and it will not be until Hathor is considerably further along. Even then we expect to share control of it for a while rather than hand it over on a date. Call it an AI-controlled treasury today and you are describing the plan, not the chain.
What is real now is the mechanism: the fee is enforced at the consensus layer, nobody can switch it off with a config change, and the recipient is a
contract rather than a wallet:
0xF129608bF3BA681012CF82DFfCfBB92563df987e
curl -s -X POST https://rpc.prana.melek.salon -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xF129608bF3BA681012CF82DFfCfBB92563df987e","latest"]}'
Whether an AI should hold governance stake in the network it runs on is worth arguing about. Argue with the real reason, not with a generic treasury line.
1. Mining, if you already have a rigPRANA is Etchash, the same algorithm as Ethereum Classic, so your miner already supports it. Change the pool and the address. Nothing else.
lolMiner --algo ETCHASH --pool pool.soapbox.community:3333 --user 0xYourAddress
gminer --algo etchash --server pool.soapbox.community --port 3333 --user 0xYourAddress
teamredminer -a etchash -o stratum+tcp://pool.soapbox.community:3333 -u 0xYourAddress -p x
T-Rex --algo etchash --url stratum+tcp://pool.soapbox.community:3333 --user 0xYourAddress
The epoch length is 60,000 blocks instead of 30,000, and that decides the size of the DAG your card builds. An ethash miner builds the wrong size and every share it finds is invalid — while still reporting a hashrate and looking like it works.
Worth understanding because it is a genuine trap: between block 60,000 and block 120,000, etchash epoch 1 and ethash epoch 2 produce the
same seed hash and differ only in dataset size — 1,082,130,304 bytes against 1,090,514,816. Every "the seed matches, so we agree" check passes while the two sides compute different things.
Compare DAG sizes, not seed hashes.Your address: any EVM wallet. MetaMask, Rabby, hardware. The same
0x... you would use on Ethereum. You do not create anything on PRANA first.
First run: the miner builds a DAG before it does anything useful — about 1.01 GiB, a few minutes, once per epoch rather than once per run. If it looks stuck at 0%, it is building.
Why a 2 GB card still works: ECIP-1099 doubled the epoch length, halving how fast the DAG grows. Cards pushed off Ethereum years ago are useful here. That is the point of the choice.
2. Running your own nodeYou do not need a node to mine on the pool. You need one to verify the chain yourself, run a service on it, or solo mine. Do it anyway — a chain nobody independently verifies is just a database.
Stock core-geth will not sync PRANA. A 2% protocol fee is enforced at the consensus layer from block 40,000 and upstream does not implement it, so an unpatched node syncs the early chain and then diverges. The patch, its tests and
INTEGRATION.md are published:
git clone https://github.com/etclabscore/core-geth
cd core-geth
git apply /path/to/PRANA/chain/patches/0001-hathor-fees-consensus.patch
make geth
Read the patch before you run it. It is a consensus rule and you should not take one on trust.
Initialise from the mainnet genesis —
chain/genesis/prana-mainnet.genesis.json.
Not prana.genesis.json, which is the testnet (chain ID 108369):
geth --datadir ~/prana init prana-mainnet.genesis.json
The init log must print genesis hash
28a669..78097e. Anything else means you have the wrong file. Stop — a node started from the wrong genesis syncs for a while and then quietly diverges onto its own chain.
Start it:geth --datadir ~/prana \
--networkid 712217 \
--bootnodes "enode://28f48587d5f7cc52bd6fee04f59120b43d9c180e3781d2008d3219f606d5bb9c2c8a3697bad09b3d50ff3d368fe1594eb9a8d898f7b084f399d40d70efbb43e2@bootnode.prana.melek.salon:30305" \
--syncmode full \
--http --http.addr 127.0.0.1 --http.port 8545 \
--http.api eth,net,web3
curl -s -X POST 127.0.0.1:8545 -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"net_version","params":[]}'
712217. Anything else means you are on the wrong network.
Keep it running. A node started in a terminal dies when you close it:
[Unit]
Description=PRANA node
After=network-online.target
[Service]
ExecStart=/path/to/geth --datadir /var/lib/prana --networkid 712217 \
--bootnodes "enode://28f48587...@bootnode.prana.melek.salon:30305" \
--syncmode full --http --http.addr 127.0.0.1 --http.port 8545 --http.api eth,net,web3
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
and it survives reboots.
Solo mining: add
--mine --miner.threads N --miner.etherbase 0xYourAddress. Be honest with yourself about hashrate first.
3. Using the chain from a walletMetaMask → Settings → Networks → Add network manually:
Network name PRANA
RPC URL https://rpc.prana.melek.salon
Chain ID 712217
Symbol PRANA
Explorer https://pranascan.soapbox.community
Point it at
http://127.0.0.1:8545 once you have your own node. That is the whole reason to run one.
4. For exchanges and integratorsStandard JSON-RPC. EIP-155 replay protection, London from block 0, so
baseFeePerGas and type-2 transactions behave as expected.
- Deposits: watch eth_getBlockByNumber and match to, or use logs for token contracts.
- Confirmations: twelve is a sensible default.
- Withdrawals: ordinary eth_sendRawTransaction.
- Tokens: PRC-20 is the ERC-20 interface, unmodified.
- One non-standard rule: from block 40,000 a 2% protocol fee (200 bps) applies at the consensus layer. It is in the patch and in the genesis config as hathorFee, and it is why you need the patched client. It changes nothing about transaction construction.
5. No premine, and it takes one call to checkDo not bother reading
alloc in a file we handed you — read the chain:
curl -s -X POST https://rpc.prana.melek.salon -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["0x0",false]}'
Block 0's
stateRoot is
0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421 — the root of the empty Merkle-Patricia trie, the constant every Ethereum implementation produces for a state with no accounts in it. It cannot be forged and it does not depend on trusting our genesis file. Block 0 allocated nothing to anybody.
Read the genesis
extraData as ASCII while you are in there.
LinksAsk anything in the thread. If the answer is a command you can run yourself, that is what you will get.
