We are publishing the MerdekaL1 Litepaper. MerdekaL1 is a sovereign Layer-1 blockchain for Malaysia, built by e23 in Rust, that uses post-quantum cryptography to secure its consensus and networking. The litepaper sets out the network's architecture, its proposed governance and a first financial use case. It is written for banks, regulators and builders planning infrastructure that must stay secure for decades.
MerdekaL1 is a pre-pilot developer network. It is not in production, has not been independently audited and has no external financial institution connected. Features described as proposed or planned may change.
Why Financial Infrastructure Needs Cryptographic Agility
Most digital assets and financial records today are protected by elliptic-curve cryptography, which a sufficiently capable quantum computer could break. That matters most for anything built to last. A bond, a trust deed or a financing record may need to stay secure for decades, and encrypted data captured today could be decrypted later.
The standards have started to arrive. NIST finalised its first post-quantum standards in August 2024, including FIPS 203 for key establishment and FIPS 204 for digital signatures. In October 2025, Malaysia's National Cyber Security Agency (NACSA) issued its National PQC Readiness Roadmap.
Picking an algorithm is only half the job. Some post-quantum schemes have been weakened by new research after publication, so long-lived infrastructure needs a way to replace its cryptography without restarting the network or moving the assets on it. It also needs a clear process for deciding when to make that change. The litepaper is our answer to both.
Introducing MerdekaL1
MerdekaL1 is a Layer-1 blockchain built from the ground up in Rust. Post-quantum cryptography protects how its validators agree on transactions and how its nodes communicate. It runs standard Ethereum smart contracts and developer tools through compatible interfaces.
"Sovereign" refers to how the network is intended to be governed: under Malaysian law, by a consortium of institutions. It does not mean the network is operated or endorsed by the Malaysian government.
Inside the MerdekaL1 Architecture
Post-quantum-secured consensus and networking
MerdekaL1 uses MERDEKA Consensus, a Byzantine Fault Tolerant engine from the Tendermint family. A block is final as soon as the required share of validators agrees on it. Every validator vote carries two signatures: a classical Ed25519 signature and a post-quantum ML-DSA-65 signature. Both must verify for the vote to count.
Connections between nodes use hybrid key establishment, which combines classical cryptography with ML-KEM-768, and traffic is encrypted with AES-256-GCM. These protections apply to validators and network traffic. User transaction signing is a separate design, described below.
Institutional governance and crypto-agility
Every key, signature and address on MerdekaL1 carries an algorithm identifier, so the protocol can recognise new algorithms as standards change.
The litepaper also proposes how such changes would be decided. It describes a MERDEKA Security Council that would oversee validator admission, protocol upgrades and cryptographic transitions. It also proposes a hybrid signing model in which governance actions and high-value transactions require post-quantum signatures, linked to an Ethereum-compatible address through a design called WalletSymlink. The Security Council, hybrid user signing and WalletSymlink are all proposals and have not been built.
Ethereum-compatible execution and shared verification
MerdekaL1 supports the EVM Cancun release and standard Ethereum JSON-RPC. Automated tests cover wallet connection, contract deployment, execution, event logs and error reporting using MetaMask, Hardhat, Foundry, ethers and viem. Two transaction rails share one account state.
Cryptographic state proofs let any participant check an account or contract against a block header directly. They do not have to rely on an operator's word.
From Architecture to Application
The litepaper's first use case is invoice financing. Under LHDN's MyInvois system, each e-invoice is validated and given a unique identifier.
The litepaper proposes recording those validated invoices on MerdekaL1 as a shared verification layer. A licensed financier could then confirm that an invoice is genuine and not already pledged before financing it, and flag it once financed so it cannot be pledged a second time. Invoices would not be tokenised as tradeable securities.
This is a proposed proof of concept. MerdekaL1 has no integration with MyInvois or any bank. The relevant authorities would need to confirm feasibility before any implementation begins.
From Phase 1 to Institutional Pilot Readiness
We completed Phase 1 on 18 September 2026. All 11 planned modules were built, tested and documented, and the result is a working pre-pilot developer network. It has been tested through validator failure and recovery.
The next stage is pilot readiness. The work includes:
- Account binding and a compliance gate
- Longer testing across multiple machines
- Monitoring and deployment hardening
- A live wallet validation session
- Governance-controlled validator changes and fees
Phase 2 covers national identity integration, a WASM runtime and a native SDK and wallet. No regulated pilot has launched.
Read the MerdekaL1 Litepaper
Read the litepaper: MerdekaL1 Litepaper
Learn more about e23: e23.io
If your organisation is a bank, custodian, regulator or development team planning for post-quantum migration, we would like to hear from you at contact@e23.io.
This article is for general information only and does not constitute investment, legal or tax advice. MerdekaL1 has no token and nothing here is an offer of any security or financial instrument. The governance arrangements described, including the MERDEKA Security Council, are proposals by e23 and do not indicate that any authority or institution has agreed to participate. References to NIST, NACSA and LHDN are for context and do not imply endorsement of e23. All features may be modified, delayed or cancelled.
