Animica 3.0.0 — Bitcoin-Core-Compatible RPC Mode
Animica 3.0.0 introduces a Bitcoin-Core-compatible RPC mode designed to make Animica easier to integrate with existing crypto infrastructure.
This does not mean Animica is a Bitcoin clone. Animica remains its own post-quantum, account-model, PoIES useful-work Layer 1. The compatibility layer exposes Bitcoin Core-style JSON-RPC method names and response shapes so existing explorers, wallets, exchanges, bots, indexers, pool dashboards, and other Bitcoin RPC tooling can connect with much less custom integration work.
Bitcoin-style endpointsAnimica now supports Bitcoin-style JSON-RPC calls at the root endpoint:
POST / Bitcoin-compatible RPC endpoint
POST /rpc Native Animica RPC + Bitcoin-compatible methods
That means tools can be pointed at an Animica node similarly to a Bitcoin node:
bitcoin-cli -rpcconnect=<host> -rpcport=8545 getblockcount
curl -s http://<host>:8545/ \
-d '{"jsonrpc":"2.0","id":1,"method":"getblockchaininfo","params":[]}'
JSON-RPC 2.0, positional parameters, named parameters, batch calls, and notifications are supported.
Implemented Bitcoin-style RPC categoriesRead-only chain / node methodsgetblockcount
getbestblockhash
getblockhash
getblock
getblockheader
getblockchaininfo
getchaintips
getdifficulty
getmempoolinfo
getrawmempool
getrawtransaction
sendrawtransaction
testmempoolaccept
decoderawtransaction
validateaddress
getnetworkinfo
getpeerinfo
uptime
stop
help
These are the most useful methods for explorers, indexers, exchange integrations, bots, and monitoring tools.
Wallet adapter methodsgetnewaddress
getbalance
listunspent
sendtoaddress
sendmany
listtransactions
gettransaction
createwallet
loadwallet
listwallets
backupwallet
Because Animica uses an account model instead of Bitcoin’s UTXO model, some wallet calls are compatibility adapters. For example, listunspent can synthesize a UTXO-like view from an Animica account balance, while listtransactions currently returns an empty list unless backed by an external explorer/history index.
Mining / pool compatibilitygetblocktemplate
submitblock
prioritisetransaction
generatetoaddress
getmininginfo
Mining compatibility is mapped into Animica’s PoIES useful-work system. getblocktemplate returns a Bitcoin-shaped template, while Animica-specific consensus values such as thetaMicro, templateId, stateRoot, and PoIES fields are carried under animica:* extension keys.
How Bitcoin RPC maps to Animicagetblockcount -> chain.getHead().height
getbestblockhash -> chain.getHead().hash
getblock/getheader -> chain.getBlockByHash
getrawtransaction -> tx.getTransactionByHash + mempool raw tx lookup
sendrawtransaction -> tx.sendRawTransaction
getmempoolinfo -> mempool.getStats
getrawmempool -> mempool.getPending
getnetworkinfo -> node.health
getpeerinfo -> p2p.listPeers
getblocktemplate -> miner.getBlockTemplate
submitblock -> miner.submitBlock
Animica hashes are SHA3-256 and normally use 0x-prefixed 64-hex formatting internally. The Bitcoin compatibility layer strips the 0x prefix for Bitcoin-style bare hex responses.
Balances are mapped from nANM to coin-unit display values, similar to how Bitcoin RPC returns BTC-denominated numbers. Difficulty is synthetic because PoIES does not use Bitcoin nBits; Animica maps thetaMicro into a monotonic Bitcoin-style difficulty analogue.
Important compatibility notesAnimica is not pretending to be Bitcoin at the consensus level.
Some Bitcoin fields are compatibility-only values so existing software does not break:
chainwork compatibility placeholder
bits compatibility placeholder
verificationprogress 1.0
pruned false
softforks {}
Transactions are also adapted. Bitcoin expects vin/vout UTXO-style transactions, while Animica is account-based. The RPC layer creates a Bitcoin-shaped transaction view with one synthetic vin and one vout, while keeping the real Animica fields under animica:* keys.
Why this mattersThis makes Animica 3.0.0 much easier to integrate with existing Bitcoin-oriented infrastructure:
- Explorers can query familiar block and transaction methods.
- Exchanges can reuse parts of existing Bitcoin RPC integration logic.
- Bots and indexers can consume familiar JSON shapes.
- Pool dashboards and mining tools can use getblocktemplate-style flows.
- Developers can test with bitcoin-cli-style commands instead of learning a completely new RPC surface first.
SummaryAnimica 3.0.0 adds a practical Bitcoin Core 30.x-style RPC compatibility layer while keeping Animica’s own consensus, post-quantum address model, useful-work mining, account system, and native RPC intact.
It is best described as:
Bitcoin RPC compatibility for Animica — not Bitcoin consensus compatibility.
The goal is simple: let existing Bitcoin infrastructure point at Animica faster, while still preserving what makes Animica different.
Animica 4.0.0+ — Ethereum/EVM RPC Facade is LiveAnimica has now added an Ethereum/EVM-compatible JSON-RPC facade.
This does
not mean Animica is becoming an Ethereum clone, and it does
not yet mean Solidity bytecode execution. Animica remains its own post-quantum PoIES useful-work L1.
What this release does add is a familiar Ethereum-style RPC surface so tools like MetaMask, ethers.js, web3.js, explorers, bots, dashboards, and indexers can begin connecting to Animica through common eth_*, net_*, and web3_* methods.
EVM bridge:https://evm.animica.orgWhat works in this phase:[] Ethereum-style JSON-RPC facade
[] eth_chainId
[] eth_blockNumber
[] eth_getBlockByNumber
[] eth_getBlockByHash
[] eth_getBalance
[] eth_getTransactionCount
[] eth_getTransactionByHash
[] eth_getTransactionReceipt
[] eth_gasPrice
[] eth_estimateGas
[] eth_call
[] eth_getLogs
[] net_version
[] net_peerCount
[] web3_clientVersion
- web3_sha3
Why this matters:Ethereum tooling already has a massive ecosystem. By exposing Ethereum-style RPC methods, Animica can become easier for existing wallets, explorers, bots, and infrastructure providers to understand without changing Animica’s native architecture.
Animica uses post-quantum anim1... accounts, while Ethereum uses 20-byte 0x... addresses. The new facade includes an address bridge layer that can create deterministic EVM-style aliases for Animica accounts.
Example concept:
This allows Ethereum-style tooling to display and query Animica accounts through familiar 0x addresses while the real chain remains Animica-native.
Important boundary:This is an
Ethereum RPC-compatible facade, not full EVM execution yet.
That means:
[] Animica does not currently run Solidity bytecode through this facade.
[] eth_getCode returns empty code.
[] eth_call is currently a compatibility/read placeholder.
[] eth_sendRawTransaction is bounded because Ethereum uses secp256k1 signatures while Animica uses post-quantum identity.
The honest claim is:
Animica now has an Ethereum RPC-compatible facade, with a path toward full EVM execution.Roadmap:[list=1]
[] EVM RPC facade — live in 4.0.0+
[] Wallet compatibility and binding flow
[] Relayer support for EVM-wallet transaction submission
[] ERC-style facade for native Animica assets/contracts
- Full EVM execution module for Solidity deployment
Animica is building compatibility outward while keeping its core identity intact: post-quantum security, useful-work consensus, AI compute, native Python-VM contracts, and a blockchain architecture designed around more than just hashing.
This release makes Animica easier to connect to, easier to index, easier to build around, and easier for existing Ethereum infrastructure to experiment with.
Install/update:
Animica 4.0.0+ is another step toward making useful-work blockchain infrastructure accessible through the tools developers already know.
