Inception Protocol

This page provides technical specifications for the Inception blockchain protocol, including consensus mechanism, network parameters, and architectural details.

Consensus Mechanism

Inception uses Proof of Stake (PoS) consensus with Gasper FFG (Friendly Finality Gadget).

Gasper FFG

Gasper combines two mechanisms:

LMD GHOST: Latest Message Driven Greediest Heaviest Observed SubTree
- Fork choice rule for selecting the canonical chain
- Validators attest to the head of the chain they consider valid
- Chain with the most accumulated attestations wins
Casper FFG: Casper Friendly Finality Gadget
- Provides economic finality
- Validators vote on epoch boundary blocks (checkpoints)
- Once a checkpoint is finalized, it cannot be reverted without massive slashing

Benefits:

Fast block times with eventual finality
Economic security through staking
Energy efficiency compared to Proof of Work
Resilience against various attack vectors

Network Parameters

Timing

Parameter	Value
Slot Duration	12 seconds
Slots per Epoch	32 slots
Epoch Duration	~6.4 minutes (384 seconds)
Finality	2 epochs (~12.8 minutes, 64 slots)

Block Production:

One block per slot (12 seconds)
Validator randomly selected to propose each slot
Missed slots result in empty blocks (chain continues)

Epoch Boundaries:

Every 32 slots marks an epoch boundary
Epoch transitions trigger validator shuffling
Checkpoint voting occurs at epoch boundaries

Validator Economics

Parameter	Value
Stake per Validator	32 INCP
Max Effective Balance	32 INCP
Activation Queue	4 validators per epoch
Exit Queue	4 validators per epoch
Slashing Amount	Up to 100% of stake

Activation:

Submit 32 INCP deposit to deposit contract
Wait in activation queue (4 per epoch)
Begin validating duties once activated

Penalties:

Inactivity penalties: Small penalties for offline validators
Slashing: Severe penalties for provably malicious behavior (double signing, surround voting)

Transaction Processing

EIP-1559 Fee Model

Inception implements EIP-1559 for predictable transaction pricing:

Components:

Base Fee:
- Algorithmically adjusted based on block fullness
- Burned (removed from circulation)
- Target: 15M gas per block
Priority Fee (Tip):
- User-specified tip to validators
- Incentivizes faster inclusion
- Goes to block proposer

Fee Calculation:

Total Fee = (Base Fee + Priority Fee) × Gas Used

Example:

Base Fee: 20 gwei
Priority Fee: 2 gwei
Gas Used: 21,000 (simple transfer)

Total Fee = (20 + 2) × 21,000 = 462,000 gwei = 0.000462 INCP

Gas Limits

Parameter	Value
Block Gas Target	15,000,000 gas
Block Gas Limit	30,000,000 gas
Base Fee Adjustment	±12.5% per block

Block Fullness:

Blocks can use up to 30M gas
Target is 15M gas per block
Base fee increases if blocks consistently exceed target
Base fee decreases if blocks consistently below target

Throughput

Metric	Value
Sustained TPS	≈35 TPS
Peak TPS	≈120 TPS
Block Time	12 seconds
Transactions per Block	~400-1,400 (varies by tx type)

Factors affecting TPS:

Transaction type: Simple transfers use less gas than complex contract interactions
Block fullness: Validators can include more txs if there's demand
Gas limit: 30M gas cap limits max throughput
Network conditions: Congestion affects actual throughput

Realistic Performance

Inception's TPS figures reflect realistic, sustained performance under normal conditions. Peak TPS represents maximum theoretical throughput with optimal transaction types.

Network Architecture

Execution Layer

The execution layer handles:

Transaction processing: Execute smart contracts and state transitions
EVM execution: Run Ethereum Virtual Machine
State management: Maintain account balances, contract storage
Mempool: Queue pending transactions

Client: Geth (Go Ethereum)

Consensus Layer

The consensus layer handles:

Block proposal: Select validators and coordinate block creation
Attestations: Collect and verify validator votes
Finality: Implement Casper FFG finality gadget
Validator management: Track validator set and duties

Client: Prysm (Ethereum consensus client)

Communication

Execution and consensus layers communicate via:

Engine API: JSON-RPC interface on port 8551
JWT Authentication: Shared secret for secure communication
Block Building: Consensus requests execution payloads
State Sync: Coordinate state transitions

Cryptography

Signature Scheme

Algorithm: BLS12-381 (Boneh-Lynn-Shacham)
Key Size: 48 bytes (public), 32 bytes (private)
Signature Size: 96 bytes
Aggregation: Supports signature aggregation for efficiency

Benefits:

Compact signatures
Efficient aggregation (many signatures → one)
Strong security guarantees

Hashing

Block hashing: Keccak-256 (Ethereum-compatible)
State root: Merkle Patricia Trie
Transaction hash: Keccak-256

Chain Structure

Beacon Chain

The beacon chain coordinates consensus:

Stores: Validator registry, attestations, finality votes
Manages: Validator lifecycle, rewards, penalties
Coordinates: Execution layer state through Engine API

Execution Chain

The execution chain processes transactions:

Stores: Account balances, contract code, storage
Executes: Smart contracts via EVM
Produces: Execution payloads for beacon chain

Finality

Finality process:

Block included in slot
Attested by validators
Included in epoch checkpoint
Checkpoint justified (2/3 validator votes)
Next checkpoint justified
Previous checkpoint finalized (irreversible)

Timeline: Finality achieved in 2 epochs (~12.8 minutes)

Validator Duties

Attestation Duties

Every epoch, validators:

Assigned to specific slots
Attest to head of chain
Attest to source and target checkpoints
Aggregate with other validators in committee

Frequency: Once per epoch per validator

Block Proposal

Validators randomly selected to:

Propose blocks for specific slots
Include transactions from mempool
Include attestations from other validators
Earn extra rewards for successful proposals

Frequency: Occasional (random selection)

Sync Committee

Validators may be selected for sync committee:

Duration: ~27 hours
Size: 512 validators
Purpose: Support light clients
Rewards: Additional compensation

Network Security

Slashing Conditions

Validators are slashed for:

Double Proposal: Proposing two different blocks for same slot
Surround Voting: Attestation surrounds or is surrounded by previous attestation
Double Voting: Two attestations for same epoch

Penalties:

Minimum: 1 INCP immediate slash
Correlation penalty: Additional penalty based on how many validators slashed at same time
Exit: Forced exit from validator set

Inactivity Leak

If the chain fails to finalize (>33% validators offline):

Inactivity leak mechanism activates
Offline validators lose stake gradually
Online validators maintain stake
Eventually online validators regain 2/3 majority for finality

Purpose: Recover finality even if many validators are offline

Protocol Upgrades

Hard Forks

Major protocol changes require hard forks:

Governance approval: 66% supermajority vote
Timelock: 14-day waiting period
Coordination: Validators and node operators upgrade clients
Activation: Fork activates at predetermined block/epoch

Recent/Planned Upgrades:

Genesis launch
Future EIPs (to be determined by governance)

Developer Considerations

JSON-RPC API

Standard Ethereum JSON-RPC methods supported:

eth_blockNumber
eth_getBalance
eth_sendRawTransaction
eth_call
eth_estimateGas
And all other standard Ethereum RPC methods

Endpoint: https://rpc.inceptionera.com

Smart Contract Limits

Max Contract Size: 24 KB (EIP-170)
Stack Depth: 1024 (EIP-3860)
Call Gas Limit: Block gas limit (30M)

State Size

As of genesis:

Accounts: Starts from genesis allocation
Storage: Grows with contract usage
History: Pruning available to reduce storage

Performance Characteristics

Latency Expectations

Understanding timing helps you set realistic expectations for your applications:

Operation	Time	Notes
Transaction inclusion	~12-24 seconds (1-2 blocks)	Most UIs wait for 1-2 block confirmations
Finality	~12.8 minutes (2 epochs, 64 slots)	Critical applications should wait for finality
Validator activation	Hours to days (queue dependent)	4 validators activated per epoch
Validator exit	Days (queue dependent)	4 validators can exit per epoch

Design Implications:

Most users will see transaction confirmations within 12-24 seconds
High-value operations should wait ~12.8 minutes for economic finality
Design UIs with appropriate loading states for these timeframes
Consider batching operations to optimize for gas and throughput

Throughput Optimization

To maximize throughput:

Batch operations: Combine multiple ops in single transaction
Optimize gas: Use efficient Solidity patterns
State access: Minimize storage reads/writes
Transaction size: Keep calldata minimal

Monitoring and Metrics

Node Metrics

Key metrics for node operators:

Sync status: Is node synced with chain head?
Peer count: Number of connected peers
Attestation rate: % of successful attestations
Block proposals: Number of successful proposals
Slashing events: Any slashing incidents

Network Metrics

Key metrics for network health:

Active validators: Number of validators
Participation rate: % of validators attesting
Finality: Is chain finalizing regularly?
Fork choice: Chain head agreement
Pending transactions: Mempool size

Resources

RPC Endpoint: https://rpc.inceptionera.com
Block Explorer: https://explorer.inceptionera.com
Beacon Explorer: https://beacon.inceptionera.com (when available)
Status Page: https://inceptionera.com/status
Geth Documentation: https://geth.ethereum.org/docs
Prysm Documentation: https://docs.prylabs.network/

Technical Specifications Summary

consensus:
  mechanism: PoS (Gasper FFG)
  slot_time: 12s
  epoch_length: 32 slots
  finality: 2 epochs (~12.8 min)

execution:
  vm: EVM
  fee_model: EIP-1559
  block_gas_target: 15_000_000
  block_gas_limit: 30_000_000

network:
  chain_id: 1805
  native_token: INCP
  total_supply: 50_000_000_000 INCP

validator:
  stake_amount: 32 INCP
  activation_rate: 4 per epoch
  exit_rate: 4 per epoch

performance:
  sustained_tps: ~35
  peak_tps: ~120
  block_time: 12s

Consensus Mechanism​

Gasper FFG​

Network Parameters​

Timing​

Validator Economics​

Transaction Processing​

EIP-1559 Fee Model​

Gas Limits​

Throughput​

Network Architecture​

Execution Layer​

Consensus Layer​

Communication​

Cryptography​

Signature Scheme​

Hashing​

Chain Structure​

Beacon Chain​

Execution Chain​

Finality​

Validator Duties​

Attestation Duties​

Block Proposal​

Sync Committee​

Network Security​

Slashing Conditions​

Inactivity Leak​

Protocol Upgrades​

Hard Forks​

Developer Considerations​

JSON-RPC API​

Smart Contract Limits​

State Size​

Performance Characteristics​

Latency Expectations​

Throughput Optimization​

Monitoring and Metrics​

Node Metrics​

Network Metrics​

Resources​

Technical Specifications Summary​

Next Steps​