Protocol resources

Security Policy

Aletheia StableChain carries the legal tender of the Sovereign Covenant State. If you find a weakness in the chain, its software or the State's platform, please tell us privately so it can be fixed before anyone can misuse it. Reports go to the State's computer security incident response team, CSIRT-ALE.

Report a vulnerability to CSIRT-ALE

01 How to report

1
Use the official channel. Report through the CSIRT-ALE disclosure page on the State's website, and encrypt your findings with the CSIRT's published PGP key.
2
Describe what you found. The component and version (or commit), the steps to reproduce it, what an attacker could achieve, and a proof of concept if you have one.
3
Keep it private. Do not publish, share or exploit the issue until it has been fixed and a disclosure date agreed with you.
4
Leave personal data out. If a finding exposes anyone's data, stop, keep no copy, and say so in your report.

02 What happens next

1 Acknowledged Your report is confirmed as received.

2 Triaged Its severity and scope are assessed with you.

3 Fixed A fix is prepared, tested and deployed; for the chain, through a coordinated release.

4 Disclosed The issue is published on an agreed date, crediting you if you wish.

The State runs a bug bounty for responsible disclosures; its terms and awards are published by CSIRT-ALE.

03 Scope

In scope

The nodealetheiad: consensus, block execution, the mempool, peer-to-peer networking, storage and recovery.
The protocolStableChain's rules: transaction validity, fees, the AEY supply invariants, governance, registries, the payment network and the bridge.
The public RPCThe REST and JSON-RPC interfaces at rpc.stateofaletheia.org, including input handling and rate limits.
Wallet and CLIaletheia-cli and the wallet library: key derivation, the encrypted keystore, signing and network checks.
This exploreraletheiascan.mainnet.stateofaletheia.org: what it displays, how it reads the node, and its browser security.
The State's platformstateofaletheia.org and its citizen and officer portals.

Out of scope

Volumetric denial of service, or flooding any service with traffic.
Social engineering, phishing or physical attacks on people, offices or data centres.
Findings that need a compromised device, or an attacker who already holds a victim's keys.
Automated scanner output without a demonstrated, concrete impact.
Services run by third parties, such as exchanges or other wallets.

04 How severity is judged

Critical Breaks consensus safety or the money: two conflicting blocks finalized, AEY created without authorisation, funds moved without the owner's signature, a supply invariant (I1–I15) bypassed, or validator keys exposed.

High Halts the chain or a core service: finality stops, honest nodes crash on valid input, a governance or registry rule is bypassed, or the bridge accepts a message it should refuse.

Medium Harms one node or service without breaking the chain: a crafted RPC request exhausts one node, the explorer can be made to display something untrue, or information leaks that should not.

Low Defence-in-depth issues with limited impact: missing hardening headers, verbose errors, or weaknesses that need unlikely conditions.

05 Rules for research

Test on a devnet or your own node. The node runs a local development network in minutes; everything public on the chain can be reproduced there.

Touch only your own accounts. Never move, freeze or read anyone else's funds or data.

Stop at proof. Show that an issue exists; do not use it further than that.

Give time to fix. Agree a disclosure date with CSIRT-ALE before publishing anything.

06 What already protects the chain

Byzantine-fault-tolerant consensus A block is final only with a quorum certificate from the validator set and its successor's; finality cannot be reverted.

Supply invariants every block The AEY ledger checks I1–I15 after every block: issued, burned, held and escrowed amounts must reconcile, or the block is refused.

Keys stay with their owners Validator keys sit in a signer with a persistent record of what it signed; the RPC and explorer never hold keys and cannot move funds.

Network-bound signatures Every signature names the chain and the network, so a signature made for one network cannot be replayed on another.

Checksummed identifiers Addresses and identifiers carry a checksum in the case of their letters, as Ethereum addresses do, with the network folded in; a mistyped or foreign address is refused.

Finalized-only reads The RPC and this explorer serve finalized data only, so nothing shown can be rolled back.