Movement Labs
Movement Labs
Movement Labs is building a modular framework to build and deploy Move-based infrastructure, applications, and blockchains in any environment. The docs below are for our products: M1 & M2.
What is M1?
M1 is a community-first Layer 1 partnering with Ava Labs providing the highest possible TPS through Move, instant finality, native day-zero access to mass liquidity, and modular customizations.
Why M1?
Move builders are currently forced to decide between monolithic, low-liquidity, and centralized chains. M1 enables builders to natively tap into large liquidity providers like BenQi and GMX through Avalanche Warp Messaging. M1 is also 100% compatible with any existing Aptos Move code (Sui Move coming) which means any Aptos protocol can simultaneously launch on Avalanche and inherit the liquidity and tooling for no extra cost. Move protocols can also expect to have interoperability and tap into the liquidity of traditional EVM protocols.
What is M2?
M2 is a community-first Layer 2 providing similar capabilities to M1 and sequenced by it.
Why M2?
M2 simplifies the development process for Sui developers aiming to engage with the Movement network. Its design addresses the unique needs of the Sui ecosystem, aligning with its principles and technical framework and seamlessly integrates with the Movement network.
Why Move?
Move is a safe and secure programming language for Web3 that emphasizes scarcity and access control. Any assets in Move can be represented by or stored within resources. Scarcity is enforced by default as structs cannot be accidentally duplicated or dropped. Only structs that have explicitly been defined at the bytecode layer as copy can be duplicated and drop can be dropped, respectively.
Access control comes from both the notion of accounts as well as module access privileges. A module in Move may be a library or a program that can create, store, or transfer assets. Move ensures that only public module functions may be accessed by other modules. Unless a struct has a public constructor, it can only be constructed within the module that defines it. Similarly, fields within a struct can only be accessed and mutated within its module or via public accessors and setters. Furthermore, structs defined with key can be stored and read from global storage only within the module that defines it. Structs with store can be stored within another store or key struct inside or outside the module that defines that struct.
In Move, a transaction's sender is represented by a signer, a verified owner of a specific account. The signer has the highest level of permission in Move and is the only entity capable of adding resources into an account. In addition, a module developer can require that a signer be present to access resources or modify assets stored within an account.
Each deployment of the MoveVM has the ability to extend the core MoveVM with additional features via an adapter layer. Furthermore, MoveVM has a framework to support standard operations much like a computer has an operating system.
