Transaction Lifecycle

Transaction Flow

Transaction Submission

Transaction initiation

Users initiate transactions on Neura using standard Ethereum tooling — including Web3 wallets (MetaMask), libraries (ethers.js and web3.js), IDEs like Remix, or dApp interfaces.

The most secure method is submitting signed transactions via eth_sendRawTransaction, where signing happens client-side before sending the transaction to a Neura node.

Gas estimation

eth_estimateGas is the recommended method to perform gas estimation for typical transaction flows. Neura follows Ethereum gas pricing standards:

  • Legacy: gasPrice.

  • EIP-1559: maxFeePerGas and maxPriorityFeePerGas.

The node uses these values to prioritize transactions accordingly.

Mempool Propagation

Upon receiving a transaction, a Neura validator node performs several validation checks:

  • Signature verification

  • Nonce correctness (sequential, not a duplicate)

  • Sufficient balance to cover gas_limit * gas_price + value

  • Gas limit does not exceed the block gas limit

If any of these checks fail, the transaction is rejected. Valid transactions are added to the node's local mempool and propagated via Besu's native P2P gossip protocol.

Each Neura node maintains its own mempool — there is no global transaction queue. Validators (or proposers) select transactions from their own view of the mempool.

If a transaction isn’t picked up immediately, it remains pending, subject to node-specific eviction policies (usually based on low fees or age). Wallets or dApps may resubmit transactions with higher gas fees to expedite inclusion.

Block Inclusion

The current proposer (based on QBFT round-robin rotation) selects transactions from its mempool. Selection typically follows a priority gas auction model — higher-fee transactions are preferred.

Additional constraints for inclusion:

  • Nonce continuity: Only a transaction with nonce N can be included only after nonce N-1 is confirmed.

  • Balance check: The sender’s balance must be sufficient at block construction time.

Block Propagation

Once the proposer assembles a block, it is broadcast to the rest of the validator set using Besu’s native P2P gossip protocol. QBFT consensus then proceeds through its rounds to finalize the block.

Local Execution

Once consensus on block N is reached, the finalized block is handed off for execution. Transactions in the block are executed serially (one by one) in the order defined in the block.

This pipelined execution model allows consensus to begin on block N+1 even while execution of block N is in progress.

If a transaction included in the block fails during execution (example: REVERT), it is still included in the block, consumes gas, and the failure is recorded in the transaction receipt.

There is no retry or reordering of transactions once a block is finalized — execution is strictly deterministic and linear.

Querying the Outcome

Once a transaction is executed and the block is finalized, users can query the result using standard Ethereum JSON-RPC calls:

  • eth_getTransactionByHash

  • eth_getTransactionReceipt

These return the transaction status, logs, gas usage, and metadata.

For advanced debugging, debug_traceTransaction is supported.

Users may also track their transactions via Blockscout, the default block explorer for the Neura network.

Bridging Flow

Supported Bridging Directions & Chains

  • Supported Tokens: Only the ANKR token is currently supported for bridging.

  • Supported Chains:

    • Ethereum (both directions: to Neura and from Neura)

    • Other chains: Not yet supported.

  • Directions: Bridging is bidirectional for Ethereum:

    • From Ethereum to Neura (inbound)

    • From Neura to Ethereum (outbound)

On-Chain Contracts

Ethereum Bridge Contract

  • Deployment: Deployed on Ethereum

  • Token Support: Only supports bridging the ERC-20 ANKR token

  • Contract Functions:

    • deposit(): locks tokens, emits TokensDeposited event

    • claim(): releases tokens on return bridging, emits TokensClaimed event

Neura Bridge Contract

  • Purpose: Handles outbound transfers from Neura to Ethereum

  • Contract Functions:

    • deposit(recipient, chainId): Moves ANKR tokens to the vault and emits a TokensDeposited event

    • approveTransfer(hash, sig): Collects validator signatures and emits a BridgeTransferApproved event when the required threshold is met

  • Signature Format: ECDSA

Neura Treasury Smart Contract (Neura Vault)

  • Role: Custodian of the majority of pre-minted ANKR supply on Neura (~10 billion ANKR)

  • Control: Fully controlled by the Safe Multisig

  • Transfers: Only executable via Safe Multisig

Safe Multisig

  • Ownership: Holds ownership of the Neura Vault

  • Validator Set: All validators are included as multisig owners

  • Functions:

    • execTxn(): Executes transactions when the SafeTxnAggregator reaches the validator signature threshold

    • getOwners(): Returns the current validator set

  • Owner Updates: Can be updated dynamically

Off-Chain Coordination & Validator Logic

Validator Add-on (per validator)

  • Deployment: Runs alongside each validator’s Besu node

  • Purpose: Handles bridge event observation, message signing, and interaction with smart contracts for both inbound and outbound bridge flows

  • Language: Implemented in Java, same as the Besu node

  • Key Management: Integrated directly within the validator software running on every Neura node; uses the validator’s private key

  • Chain Interaction:

    • Reads event data via indexers (Graph nodes)

    • Submits signed messages to SafeTxnAggregator contracts just like user-submitted transactions

Inbound Flow Role (Ethereum → Neura)

  • Observes BridgeRequested events on Ethereum

  • Signs the bridge message using the validator key

  • Submits the signed message to the SafeTxnAggregator

Outbound Flow Role (Neura → Ethereum)

  • Observes BridgeRequested events on Neura

  • Submits the validator signature via approveTransfer() to the Neura Bridge Contract

SafeTxnAggregator

  • Receives:

    • Proposed transaction data

    • Validator signatures

  • Workflow:

    • Once the required signature quorum is reached, the aggregator submits the transaction to the Safe Multisig

  • Functions:

    • proposeTxn()

    • signTxn()

The SafeTxnAggregator does not sign or execute transactions itself — it only facilitates signature collection and forwarding.

Indexer

  • Role: Monitors and relays bridge-related events from both chains

  • Watched Events:

    • Ethereum: BridgeRequested, Claim

    • Neura: BridgeRequested, BridgeTransferApproved

  • Output: Relays observed events to validator add-ons to initiate signing workflows

Bridging Flow: Ethereum —> Neura (Inbound)

  1. User Action The user calls deposit() on the Ethereum Bridge Contract.

  2. On-Chain Event The contract locks the ERC-20 ANKR tokens and emits a BridgeRequested event.

  3. Event Monitoring The Indexer detects the BridgeRequested event and forwards it to all validator add-ons.

  4. Validator Add-ons Each validator add-on performs the following steps:

    • Constructs the message hash

    • Signs the message hash using its validator key

    • Submits the signature to the SafeTxnAggregator

  5. Signature Aggregation The SafeTxnAggregator:

    • Waits until the configured signature threshold (quorum) is reached

    • Calls execTxn() on the Safe Multisig

  6. Execution The Safe Multisig executes the transaction:

    • Transfers the corresponding amount of native ANKR from the Neura Vault to the user on Neura

The quorum threshold is configurable in the contracts (not dynamic on-chain but adjustable via contract parameters).

Bridging Flow: Neura → Ethereum (Outbound)

  1. User Action The user calls bridge() on the Neura Bridge Contract.

  2. On-Chain Action The Neura Bridge Contract:

    • Moves the specified amount of ANKR to the Neura Vault

    • Emits a BridgeRequested event

    • Generates and stores a message hash: keccak256(amount, recipient, nonce, chainId, sourceChainId)

  3. Event Monitoring The Indexer observes the BridgeRequested event and relays it to all validator add-ons.

  4. Validator Add-ons Each add-on:

    • Verifies the event and message details

    • Calls approveTransfer(hash, sig) on the Neura Bridge Contract

  5. Signature Collection & Approval

    • The Neura Bridge Contract aggregates validator signatures

    • Once the threshold is reached, it emits a BridgeTransferApproved event

  6. Claim on Destination Chain

    • The user collects validator signatures (via smart contracts; the frontend fetches them from the Neura Bridge contract)

    • The user submits the collected signatures to the Ethereum or BSC Bridge Contract by calling claim() to redeem the bridged ANKR

Security Model

Message Replay Protection

To prevent message replay across chains, each bridge message includes the chainId as part of the hash input. This ensures that a message intended for one chain cannot be reused on another.

Uniqueness Enforcement

A nonce is included with all transactions executed via the Safe Multisig, ensuring uniqueness and preventing duplicate execution. This serves a similar role to a transferId in other bridging systems.

Validation & Double-Signing Safeguards

All validator-signed messages are subject to on-chain verification. If a message is invalid or double-signed, it will be rejected by the smart contracts and cannot be executed.

Validator Set & Thresholds

Validator Set Management

Neura operates a permissioned validator set, which is configured at the network level. Validators can be added or removed through defined procedures — the set is not hardcoded, and updates can be made as needed.

Cross-Component Synchronization

Validator identity and permissions are aligned across all bridge components:

  • Safe Multisig: The list of active validators is exposed via the on-chain getOwners() function.

  • Neura Bridge Contract: Only addresses present in the current validator set (via the Safe ownership) are authorized to call approveTransfer().

This ensures consistent validator authorization across signature aggregation, transaction approval, and multisig execution.

Quorum & Thresholds

  • Signature Quorum: The required threshold (e.g., ⅔ of validators) is configurable and adjustable via contract settings.

  • This threshold applies to both inbound execution via the Safe Multisig and outbound approval in the Neura Bridge Contract.

Operational Latency & Retries

Latency Expectations

The time required to complete a bridge transfer — whether inbound (Ethereum → Neura) or outbound (Neura → Ethereum) — depends on the number of simultaneous bridge transfers in progress. Higher traffic may result in slower inclusion and signature aggregation due to validator processing limits.

Automatic Retries

Validator add-ons implement automatic retry mechanisms. If a transfer message is missed, fails validation, or quorum isn’t initially reached, add-ons will retry submission until the threshold is met or the transaction expires under node-level policies.

PreviousNeura for DevelopersNextArchitecture Components

Last updated