ISBE Network Technical Parameters

This document collects the operational parameters relevant to teams developing and deploying use cases on the ISBE blockchain network. It includes only the information necessary to connect, deploy contracts, and operate correctly in the public environments (pre, pro).

The ISBE network is based on Hyperledger Besu and uses the QBFT consensus mechanism, fully EVM-compatible.

Scope of this page

The parameters on this page correspond to ISBE's Main Network (UseCase), the network open to use case deployments, in its two public environments: ISBE Mainnet and ISBE Testnet.

ISBE is conceived as a set of networks. The rest of the infrastructure's networks have their own configuration and are not covered here; their documentation will be published once they are available for third-party deployments.

Public environments

Public name	Environment	Purpose	Chain ID
ISBE Mainnet	pro	Production	33073
ISBE Testnet	pre	Pre-production and integration	11073

Reference Parameters

The values presented in this document may evolve according to:

Environment (pre, pro): each environment may have specific configuration.
Project phase: parameters may evolve between deliveries.
Network updates: subsequent improvements, optimizations, and hard forks after initial deployment.

The values in this document are verified and are the reference source; if in doubt or in case of a discrepancy, confirm with the ISBE infrastructure team.

1. Client and Version

The network runs:

Client: Hyperledger Besu
Recommended version: 26.7.1 (updated according to project delivery)
Compatibility: EVM (Ethereum Virtual Machine)
Consensus: QBFT (QBFT is the improved evolution of IBFT 2.0)
Hash Algorithm: Keccak-256 (Ethereum standard)

Besu is an enterprise client maintained by the Linux Foundation, with support for permissioned networks and flexible QBFT configuration.

Besu Version

The specific Besu version may vary depending on the environment and the project phase (MVP, R1, R2). Consult with the ISBE infrastructure team for the exact version for your environment.

2. Consensus: QBFT

The ISBE network uses QBFT (improved evolution of Istanbul BFT 2.0), a Byzantine fault-tolerant mechanism where:

A set of validators proposes and signs blocks.
The block is only valid if it reaches a quorum of signatures.
The system allows tolerating down or non-honest nodes within BFT limits.

Configured consensus parameters:

Block period: 2 seconds (time between blocks)
Epoch length: 30000 blocks (for validator rotation)
Request timeout: 4 seconds (proposal timeout)

Relevant features for use cases:

No mining exists: consensus is deterministic.
Block time is stable (2 seconds configured).
Transaction behavior is predictable.
No deep chain reorganization exists (minimal reorgs).

3. Active EVM Forks

Fork activation is done by timestamp, via the corresponding fields in the genesis config block.

Fork	ISBE Testnet	ISBE Mainnet
Shanghai	✅	✅
Cancun	✅	✅
Prague	✅ 10 Aug 2026	✅ 18 Aug 2026
Osaka	✅ 27 Aug 2026	✅ 2 Sep 2026

All activations took place at 08:00 UTC on the indicated date.

What Prague brings

Prague enables, among others, the BLS12-381 curve precompiles (EIP-2537), historical block hashes in storage (EIP-2935), and set-code transactions (EIP-7702).

What Osaka brings

Osaka brings three changes with direct impact for those developing on ISBE:

P256VERIFY (EIP-7951): a precompile for verifying signatures on the secp256r1 (P-256) curve at address 0x0000000000000000000000000000000000000100. It allows verifying on-chain signatures generated by Secure Enclave, TPM, WebAuthn/passkeys, and cryptographic cards, without implementing the curve in Solidity.
Gas limit per transaction (EIP-7825): see the gas limit section.
Upper bounds on MODEXP (EIP-7823).

How to check a node's active fork

geth attach -exec "admin.nodeInfo.activeFork" <rpc-url> returns the name of the active fork. geth attach -exec "admin.nodeInfo.protocols.eth" <rpc-url> shows the complete config block, with the timestamps for each fork.

4. Block Time

The block generation time configured in ISBE is:

Block time: 2 seconds (blockperiodseconds parameter)
Variability: very low (deterministic consensus)
Suitable for:
- Notarization protocols
- General purpose smart contracts
- Backend integrations with predictable latency

This block time may be adjusted if the network requires subsequent optimizations, but use cases must be designed considering that blockchain writing is never instantaneous and always implies structural latency (minimum 2 seconds for confirmation).

5. Gas Limit and Transaction Cost

ISBE, being a Besu-based permissioned network, does not use an economic token. Therefore:

There are no economic costs per transaction.
Gas is used solely as an execution control mechanism.
Transactions must include a reasonable gas limit to avoid excessively heavy operations or infinite loops.

Configured Limits

Limit	Value	Source
Gas per block	30,000,000 (`0x1C9C380`)	`gasLimit` genesis parameter
Gas per transaction	16,777,216 (2²⁴)	EIP-7825, active since the Osaka hard fork
Minimum gas price	1 Gwei (`1000000000`)	`minGasPrice` genesis parameter
Maximum contract size	24,576 bytes	Genesis `contractSizeLimit` parameter

Gas limit per transaction

Since the activation of Osaka, no transaction can declare a gasLimit higher than 16,777,216 units (2²⁴, approximately 16.7 million). This is a protocol limit introduced by EIP-7825 and is independent of the per-block gas limit: even though the block allows 30,000,000, an individual transaction exceeding 16,777,216 will be rejected.

If your deployment scripts set gasLimit above that value, they will fail. Review your Hardhat, Foundry, or library configuration. For complex contract deployments, 10,000,000 is a reasonable starting point.

This allows deploying complex contracts without artificial restrictions, but it is recommended to avoid:

Operations that cannot be split and that approach the 16,777,216 gas limit.
Contracts with massive storage in a single block.
Unnecessarily heavy internal logic.

6. Chain ID and Network ID

ISBE's UseCase network uses a different Chain ID per environment. The Network ID matches the Chain ID in each case. See the Public environments table at the top of this page.

Signed transactions must include the exact Chain ID for your environment.
Wallets and EVM libraries must be configured with the matching chainId from the canonical table.
Frameworks like Hardhat or Foundry must use that same value in their configuration.

Important

Always confirm with the ISBE infrastructure team the exact Chain ID assigned to your use case before configuring your development tools.

7. Types of RPC Endpoints

Each environment exposes a single Ethereum JSON-RPC compatible endpoint, served by the ISBE Client's Filtering Proxy:

HTTP RPC: used for all backend interactions (reads, writes)
- Standard port: 8545 (the Filtering Proxy's, not the Besu node's directly)
- Enabled APIs: ETH, NET, QBFT
- CORS enabled for development
WebSocket RPC: not available. Direct access to the Besu node's port (own or shared) is not permitted for GDPR compliance reasons; all RPC traffic must go through the Filtering Proxy, which only exposes HTTP RPC.

RPC Configuration Parameters:

--rpc-http-enabled
--rpc-http-host=0.0.0.0
--rpc-http-port=8545
--rpc-http-api=ETH,NET,QBFT
--rpc-http-cors-origins="all"
--host-allowlist="*"

Use cases will receive final URLs for their endpoints when their execution node or shared node access is activated.

8. Permissioning Rules

The network is permissioned: each node must be included in the authorized node list to join the P2P.

Permissioning affects only:

Execution nodes (belonging to a use case).
Validator nodes and bootnodes (managed by ISBE).

Permissioning does not affect dApps: any application can connect to the assigned RPC without needing to be part of the P2P.

9. Recommended Operational Limits

To ensure proper use of the network:

Avoid sending more than 10–20 transactions per second from the same account without prior coordination.
Wait for block confirmation before starting dependent processes.
Design smart contracts following efficiency patterns:
- Avoid redundant storage.
- Use events instead of storing internal logs.
- Do not make loops dependent on dynamic size without control.

10. Additional Node Configuration

ISBE nodes use the following additional Besu parameters:

Networking:

P2P port: 30303 (TCP/UDP)
P2P host: configurable according to deployment

Metrics:

Metrics enabled by default
Metrics port: 9545
Metrics host: 0.0.0.0

Logging:

Default level: INFO

Customizable Paths:

--data-path: Path to the node data directory
--genesis-file: Path to the genesis.json file
--node-private-key-file: Path to the node private key file

11. Summary of Parameters

Parameter	Value
Client	Hyperledger Besu 26.7.1
Consensus	QBFT (evolution of IBFT 2.0)
Block time	2 seconds
Gas per block	30,000,000 gas
Gas per transaction	16,777,216 gas (2²⁴) — EIP-7825, since Osaka
Minimum gas price	1 Gwei
Maximum contract size	24,576 bytes
Economic cost	None
Compatibility	Ethereum/EVM
Chain ID / Network ID	Different per environment — see section 6
HTTP RPC Port	8545
P2P Port	30303
Metrics Port	9545
RPC APIs	ETH, NET, QBFT
Network	Permissioned

Public environments​

1. Client and Version​

2. Consensus: QBFT​

3. Active EVM Forks​

What Prague brings​

What Osaka brings​

How to check a node's active fork​

4. Block Time​

5. Gas Limit and Transaction Cost​

Configured Limits​

6. Chain ID and Network ID​

7. Types of RPC Endpoints​

8. Permissioning Rules​

9. Recommended Operational Limits​

10. Additional Node Configuration​

11. Summary of Parameters​