Movement L1 (M1) Protocol Specification

Abstract

Movement L1 (M1) is a blockchain infrastructure built to realize the full potential of the Move programming language. It provides a secure, resource-oriented foundation for decentralized applications, on-chain finance, and digitally native organizations.

Beyond performance and safety, M1 is designed around a simple premise: technology should empower its users. It exists to restore the values of open participation, shared ownership, and verifiable trust to a global, mobile-first economy.

This document outlines the motivation, principles, and high-level architecture of M1 - a people-centered Layer 1 network that unites the efficiency of Move with a design philosophy grounded in accessibility and community ownership.

1. Introduction

1.1 Background

The blockchain ecosystem has evolved through repeated attempts to resolve the tension between scalability, security, and decentralization. Each generation of networks made progress, yet the trade-offs between performance and openness have persisted. The result is a landscape defined as much by fragmentation as by innovation — a collection of specialized systems often optimized for capital, not users.

The Move programming language, originally developed for the Diem project, represents a clean break from that trend. Its resource-oriented design, type safety, and formal verification make it uniquely suited for building verifiable financial systems. M1 extends this vision to the protocol layer itself, creating a network that is both technically robust and socially aligned with the community that depends on it.

1.2 Vision and Motivation

Movement continues the evolution of Move-based blockchain infrastructure with a renewed focus on accessibility, community participation, and sustainable on-chain economies. Its aim is to refine existing foundations toward a more inclusive and purposeful network.

Modern blockchains often measure success primarily through market metrics such as TVL or fees. Movement shifts that focus back to user impact — to how effectively a network can empower people to build, earn, and coordinate. It transforms mature technology into open infrastructure for a real community.

A sovereign Layer 1 enables this direction. By operating its own L1, Movement can shape its economics, governance, and coordination mechanisms around inclusivity and resilience — for instance, by driving value to regional hubs through its validators. The result is a network optimized for community-scale applications, meaningful community participation, real-world assets, and mobile-native finance — a system that prioritizes usability and shared benefit over speculation.

1.3 Guiding Principles

Movement's development is driven by a small set of non-negotiable principles that inform every layer of the system:

People first : technology should expand agency, not enclose it.
Community as infrastructure : decentralization is not only technical; it is social.
Accessibility at the edge : the next billion users will come from mobile, developing, and bandwidth-limited environments.
Composability with purpose : protocols and applications should interconnect into a coherent economic mesh rather than isolated silos.
Sustainability over speculation : value should circulate between builders, validators, and community, forming a stable foundation for long-term growth.

1.4 Applications and Ecosystem

M1 is designed as a general-purpose Layer 1 that supports a wide spectrum of decentralized applications, from on-chain finance to digital identity and coordination systems. Its architecture emphasizes composability, verifiability, and predictable performance, allowing developers to build without compromising safety or accessibility.

The network's focus is on real utility rather than speculative activity. Applications that benefit most from Movement's design include:

Decentralized finance and asset issuance : markets, payment rails, and credit systems where transparency and verifiable execution are essential.
Real-world asset integration : Accredited financial institutions operating on the Movement network can tokenize representations of tangible assets, enabling ownership and yield to be distributed among the community in a compliant and transparent manner, rather than concentrated in custodial entities.
Mobile-native experiences : lightweight clients and wallets enabling users to transact and interact directly from any device.
Identity and reputation frameworks : systems for establishing trust, contribution history, and governance participation on-chain.
Community-driven governance and coordination : mechanisms that allow stakeholders to propose, vote, and execute collective decisions securely.

Together, these categories define the intended shape of the Movement ecosystem: a practical, verifiable network where applications align economic value with human contribution.

1.5 L1 Design Philosophy

M1 is a social-technical system. Its purpose is not to create another marketplace for tokens but to establish a durable framework for coordination and ownership. The network treats every contribution — from validation to governance to development to education — as a building block of value.

In this sense, Movement is less a product than a public utility: a system where effort converts into value, contribution into ownership, and participation into collective strength.

1.6 L1 Key Features

M1 implements the following key features:

Move Runtime: MoveVM implementation for blockchain execution.
High-Throughput Consensus: Jolteon lineage and a Quorum Store–like dissemination layer for scaling under load.
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

M1 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

M1 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

M1'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

M1 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:

M1 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

M1 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 M1 continues to evolve and mature.

Movement L1 (M1) Protocol Specification

On this page