Discover
About EBLA Roadmap Technology Security
Economics
Tokenomics Airdrop Staking
Build
Validators Developers
Network
Community FAQ Join Now
🔐 Security

Built to Last.
Audited to Trust.

EBLA's security starts with the consensus model and goes all the way down to the genesis file. Everything is code.

✓ True Finality <3.7s ✓ 15/24 Consensus ✓ Independent Audit Planned
🛡️ Security Model

Four Layers of Defense

🗳️

15/24 Consensus

EBLA requires 15 out of 24 committee members to agree before any block finalizes. The threshold (62.5%) is custom-tuned for fast finality on a BlockDAG, with the exact ratio enforced on-chain via integer arithmetic (no floating-point rounding), no approximations.

Custom on-chain threshold
⚡

True Finality <3.7s

PBFT consensus makes blocks irreversible in under 3.7 seconds. There are no reorganizations on EBLA. A confirmed transaction cannot be undone, period. No probabilistic guessing.

Zero reorganization risk
🛡️

aBFT Security

Asynchronous Byzantine Fault Tolerant. The network maintains security and continues producing blocks even when some validators are slow, offline, or acting maliciously. The protocol is designed to survive partial network failures without halting.

Resilient to faulty nodes
💀

Automatic Slashing

Double-vote jailing and inactivity penalties are enforced automatically in the DPoS contract. No governance vote, no admin action required. Bad behavior is punished by code, not people.

Code-enforced, not human-enforced
🔎 External Audit

Planned Before Mainnet

External Security Audit

Planned Before Mainnet
  • 🎯

    Scope

    The audit covers every line of code that differs from the original Taraxa codebase. Focus areas: the 15/24 consensus threshold implementation (C++ and Go must match), inactivity slashing logic and decay math, reward decay implementation and integer overflow protection, genesis balance verification, and all DPoS contract logic.

  • 🏢

    Auditor

    A professional blockchain security firm will be engaged. The auditor selection, scope, and timeline will be announced publicly in Discord and Telegram before engagement.

  • 📋

    Publication Policy

    The full audit report — including all findings, severity ratings, and remediations — will be published publicly on this page before mainnet launches. No selective disclosure. No buried footnotes. Everything visible.

  • 🚦

    Resolution Policy

    All critical-severity findings must be resolved before mainnet. All high-severity findings must be resolved before mainnet. Medium and low severity: resolved or documented as accepted risk — also published in the report.

🔄 What Changed from Taraxa

The Security-Relevant Differences

🌉 Ethereum Bridge — Removed

The original Taraxa network included an Ethereum bridge. EBLA made the decision to permanently disable this bridge after a vulnerability was discovered in the bridge's Ethereum-side contract. In the EBLA genesis, the bridge contract address is set to zero and the bridge feature is disabled at a block height that will not be reached for centuries — a permanent, code-enforced disablement. A secure cross-chain bridge can be reintroduced in the future, but only after a full independent audit. No funds will be put at risk on an unaudited bridge.

✗ Bridge permanently disabled in genesis

🔢

Custom 15/24 Quorum

EBLA's 15/24 quorum (62.5%) is slightly lower than the standard 2/3 (66.7%) — a deliberate trade-off optimized for fast finality on a BlockDAG. The exact threshold is enforced via integer arithmetic in both C++ and Go nodes, so the C++ and Go implementations finalize on identical inputs.

💾

LZ4 Compression — No Consensus Impact

Storage compression affects only how data is stored on disk. It has zero effect on consensus rules, state roots, or on-chain data. It is configurable per-validator, and has no security implications.

🐛 Responsible Disclosure

Found a Vulnerability?

Report it. Don't exploit it.

If you discover a security vulnerability in EBLA, we ask that you report it responsibly before public disclosure. The network is community-owned — protecting it protects everyone.

  1. 1

    Report the vulnerability privately in the #security channel on Discord, or by direct message to the community moderators.

  2. 2

    Include as much detail as possible — reproduction steps, affected code, potential impact, and any proposed fix if you have one.

  3. 3

    Allow a reasonable time for the community to assess and address the issue before public disclosure.

  4. 4

    The finding and your contribution will be acknowledged in the public audit log when resolved — unless you prefer anonymity.

There is no formal bug bounty program yet. The community will decide how to reward significant findings as governance matures.