L1 Protocol Specification

Abstract

Movement L1 is a blockchain infrastructure built for the Move programming language and virtual machine. Movement L1 provides native Move execution with performance optimizations, security features, and developer tooling.

This protocol specification presents the technical foundation, architectural decisions, and features of Movement L1 for decentralized applications, DeFi protocols, and enterprise blockchain solutions. The system employs a Jolteon-based consensus with Quorum Store–style data dissemination, tuned for low latency and high throughput.

1. Introduction

1.1 Background

The blockchain ecosystem has evolved rapidly, with various platforms attempting to address the trilemma of scalability, security, and decentralization. While significant progress has been made, existing solutions often require trade-offs or complex architectural decisions that limit their effectiveness. The "blockchain trilemma" refers to the challenge of achieving scalability, security, and decentralization simultaneously; most platforms must compromise on one to optimize the others.

The Move programming language, originally developed for the Diem project, represents a significant advancement in blockchain programming with its resource-oriented design, formal verification capabilities, and built-in safety guarantees.

1.2 Vision

Movement L1 is designed to unlock the full potential of the Move programming language by providing:

Native Move Execution: High-performance, production-grade MoveVM runtime purpose-built for Layer 1 scalability and security
High Performance: Consensus and execution for high throughput
Developer Experience: Tooling and documentation for Move developers
Enterprise Ready: Production-grade infrastructure suitable for enterprise applications

1.3 Key Features

Movement L1 implements the following key features:

Move Runtime: MoveVM implementation for blockchain execution
High-Throughput Consensus: Jolteon lineage, using a 2-chain commit and quadratic view change; optional Quorum Store–like dissemination layer for scaling under load.^[Jolteon originated as DiemBFT v4 and is the basis of AptosBFT — see the Jolteon paper.]
Parallel Execution: Transaction parallelization for increased throughput
State Management: State storage and management solutions
Developer Tooling: Development environment and debugging tools

2. Technical Architecture

2.1 System Overview

Movement L1 employs a modular architecture with distinct layers handling different aspects of blockchain operation:

Application Layer    │ DApps, DeFi, NFTs, Enterprise Applications
API Layer            │ REST, WebSocket, Indexer GraphQL Interfaces
Execution Layer      │ MoveVM Runtime, Transaction Processing
Storage Layer        │ State Store, Transaction History, Events
Consensus Layer      │ BFT Consensus, Validator Network
Network Layer        │ Peer-to-peer communication, Mempool management, Message routing

2.2 Consensus Protocol

2.2.1 Jolteon

Movement L1 adopts a Jolteon-style BFT protocol. Jolteon introduces a 2-chain commit rule and a quadratic view change (pacemaker) to reduce latency and ensure fast recovery. In the happy path it achieves linear message complexity with one-round confirmations; under stress it remains robust.

The protocol guarantees safety with consistency up to 1/3 Byzantine validators, ensures liveness with progress under network asynchrony, provides finality through 2-chain commit for fast confirmations, and maintains efficiency with optimized message complexity and round duration.

2.2.2 Validator Selection

The network employs Proof-of-Stake (PoS) with weighted selection where validator selection probability is proportional to stake, a dynamic set allowing validators to join/leave based on stake and performance, and rewards with staking rewards for honest validation and block production. (Note: slashing is defined in protocol but not currently active.)

2.2.3 Block Production

Block production follows a deterministic leader selection algorithm:

// Note: This is a simplified pseudocode representation.
// Deterministic, stake/reputation-weighted round-robin (illustrative)
fn select_leader(set: &ValidatorSet, round: u64) -> ValidatorId {
let order = set.weighted_order_by_stake_and_rep(); // fixed per epoch
order[(round as usize) % order.len()]
}

2.2.4 Data Dissemination

Quorum Store–style dissemination: separate transaction dissemination from ordering to stabilize throughput under bursty load; bypass under low load for minimal latency.

2.3 Move Virtual Machine

2.3.1 Runtime Optimization

Movement L1's MoveVM implementation includes an optimized interpreter with verified bytecode, instruction caching for caching of compiled bytecode for repeated execution, gas optimization with precise gas metering and minimal overhead, and memory management with efficient memory allocation and garbage collection.

2.3.2 Security Features

The MoveVM provides built-in security guarantees including resource safety to prevent double-spending and resource leaks, type safety with compile-time and runtime type checking, access control with fine-grained permission management, and formal verification support for mathematical proof of contract correctness.

2.3.3 Parallel Execution

Transaction execution can be parallelized when dependencies allow (Block-STM approach):

// Note: This is a simplified pseudocode representation.
struct ParallelExecutor {
    worker_pool: ThreadPool,
    dependency_graph: DependencyAnalyzer,
    conflict_detector: ConflictDetector,
}

impl ParallelExecutor {
    fn execute_batch(&self, transactions: Vec<Transaction>) -> Vec<ExecutionResult> {
        let dependency_groups = self.dependency_graph.analyze(&transactions);
        let results = dependency_groups.par_iter()
            .map(|group| self.execute_group(group))
            .collect();
        self.resolve_conflicts(results)
    }
}

2.4 State Management

2.4.1 Global State Model

Movement L1 maintains a global state organized by account addresses using an account model where each address can hold multiple resources and modules, resource storage with native storage of Move resources and type information, module storage for compiled Move modules with metadata, and versioned state indexed by ledger version, with authenticated proofs via the Jellyfish Merkle Tree.

2.4.2 Jellyfish Merkle Tree (JMT)

State commitment uses the Jellyfish Merkle Tree:

Movement L1 uses a Jellyfish Merkle Tree for state commitment. This structure enables efficient proofs of state and supports scalable verification for light clients and full nodes.

State Root (Jellyfish Merkle Tree)
├── Account Subtree
│   ├── Address_1 → {Resources, Modules}
│   ├── Address_2 → {Resources, Modules}
│   └── ...
├── Events Subtree
│   ├── Event_Stream_1 → [Event_1, Event_2, ...]
│   └── ...
└── Metadata Subtree
    ├── Validator Set
    ├── Network Configuration
    └── ...

2.4.3 Storage Optimization

Several optimizations improve storage efficiency including state pruning for removal of old state versions (configurable), RocksDB-level compression for data storage and transfer, indexing with efficient indexing for common query patterns, and caching with multi-level caching for frequently accessed data.

2.5 Network Protocol

2.5.1 Peer-to-Peer Communication

Network communication uses a gossip-based protocol with peer discovery for automatic discovery and connection to network peers, message routing for efficient routing of messages based on type and priority, bandwidth optimization through compression and batching of network messages, and security with cryptographic authentication and message integrity.

2.5.2 Transaction Propagation

Transaction propagation is optimized for low latency:

Client Submission: Transaction submitted to any network node
Initial Validation: Basic validation (signature, format, balance)
Mempool Insertion: Addition to local mempool if valid
Gossip Protocol: Propagation to connected peers
Consensus Inclusion: Selection for inclusion in next block

3. Economic Model

3.1 Token Economics

3.1.1 MOVE Token

The native MOVE token serves multiple purposes including transaction fees for payment of transaction execution and storage, staking for validator staking and network security, governance for voting on protocol upgrades and parameters, and incentives for rewards to validators and network participants.

3.1.2 Fee Structure

Transaction fees are calculated based on resource consumption:

// Note: This is a simplified pseudocode representation.
// Fee model: gas unit price × gas used, minus storage refund
struct GasSchedule {
    instruction_costs: HashMap<Opcode, Gas>,
    storage_costs: StorageGasSchedule,
}

fn calculate_fee(gas_used: Gas, gas_unit_price: Octa, storage_refund: Octa) -> Fee {
    gas_used * gas_unit_price - storage_refund
}

3.1.3 Staking Mechanism

Validator staking follows these principles including minimum stake requirements for validator participation, delegation allowing token holders to delegate stake to validators, rewards with proportional rewards based on stake and performance, and slashing defined in protocol but not active on mainnet as of 2025.

3.2 Governance Model

3.2.1 On-Chain Governance

Governance decisions are made through on-chain voting with proposal submission allowing stakeholders to submit governance proposals, voting periods with time-bounded voting on active proposals, and execution with automatic execution of approved proposals.

3.2.2 Parameter Management

Key network parameters can be adjusted through governance including gas prices for base gas price and fee structure, block parameters for block size, time, and transaction limits, staking parameters for minimum stake, reward rates, and slashing conditions, and network configuration for validator set size and consensus timeouts.

4. Security Analysis

4.1 Threat Model

4.1.1 Network Attacks

Protection against various network-level attacks includes DDoS attacks with rate limiting and traffic analysis, eclipse attacks through peer diversity and connection management, sybil attacks via Proof-of-Stake and identity verification, and long-range attacks using checkpointing and weak subjectivity.

4.1.2 Consensus Attacks

Safeguards against consensus-level attacks include nothing-at-stake protection with economic penalties for equivocation, supermajority (≥ 2/3 voting-power capture) deterrence through high economic cost and provable misbehavior penalties, grinding and leader manipulation reduction via a deterministic stake-weighted leader schedule, and bribe attacks prevention through accountability of votes and misbehavior proofs.

4.1.3 Smart Contract Security

Move language features enhance smart contract security through a resource model that prevents double-spending and asset duplication, type safety with compile-time prevention of common vulnerabilities, access control with fine-grained permission and capability systems, and formal verification support for mathematical proofs of contract correctness.

4.2 Cryptographic Primitives

4.2.1 Digital Signatures

Movement L1 uses Ed25519 signatures for transaction authentication providing proof of transaction authorization, validator signatures for consensus vote authentication, message integrity for P2P message authentication, and multi-signatures via Multi-Ed25519 threshold schemes.

4.2.2 Hash Functions

SHA-3 (Keccak) is used throughout the system for block hashing with unique block identification and in the Jellyfish Merkle Tree for authenticated state and transaction commitments. Consensus uses deterministic leader selection; there is no proof-of-work or random beacon.

4.3 Audit and Verification

4.3.1 Code Audits

Regular independent security audits ensure system integrity covering the core protocol including consensus and networking components, MoveVM implementation for the virtual machine and execution engine, cryptographic libraries for all cryptographic implementations, and smart contracts including system contracts and modules.

4.3.2 Formal Verification

Mathematical verification of critical components includes consensus safety with formal proofs of consistency for the underlying Jolteon protocol and Move semantics with automated verification of language safety properties through the Move Prover. Incentive economics and governance-driven upgrades are not subject to the same level of formal proof.

# Note: This is a simplified pseudocode representation.
# Create new Move project
movement init my-project

# Compile Move modules
movement build

# Deploy to testnet
movement deploy --network testnet

# Run local testnet
movement node run-local

# Interact with deployed contracts
movement call --function transfer --args 0x123 100

5.1.2 IDE Integration

Support for popular development environments:

VS Code Extension: Syntax highlighting, debugging, IntelliSense
IntelliJ Plugin: Full IDE support with advanced features
Language Server: Language Server Protocol for editor integration
Web IDE: Browser-based development environment

5.1.3 Testing Framework

Comprehensive testing infrastructure:

// Note: This is a simplified pseudocode representation.
#[test]
public fun test_transfer() {
    let sender = @0x1;
    let receiver = @0x2;
    let amount = 100;

    // Setup test environment
    let state = create_test_state();

    // Execute transfer
    let result = transfer(sender, receiver, amount);

    // Verify results
    assert!(result.success, 1);
    assert!(balance_of(receiver) == amount, 2);
}

This protocol specification is a living document and will be updated as Movement L1 continues to evolve and mature.

L1 Protocol Specification

On this page