Overview

The Endless Web3 Genesis Cloud is the world’s first distributed cloud-based intelligent component protocol, integrating a wide range of advanced technological solutions such as AI, serverless architecture, full distributed frameworks, relay networks, and various SDKs and APIs. These innovations enable developers to rapidly and seamlessly build decentralized applications (DApps) for Web3, utilizing any programming language while delivering a user experience comparable to Web2 applications.

The Endless Web3 Genesis Cloud is a truly secure Web3 cloud service platform that guarantees user privacy, virtual asset security, and data sovereignty. It offers Web2 application developers comprehensive support—from smart contract development, decentralized storage, and modular components to enhanced information security and privacy protections—significantly reducing the barriers to transitioning from Web2 to Web3 and improving the Web3 user experience.

Core Value

The Endless was founded with the vision of leveraging technological innovation to empower users with greater autonomy, ensuring data privacy and security. It aims to foster a decentralized co-creation ecosystem where users can create and fully enjoy the value they deserve in the digital world. By shifting the focus of Web3 from financial orientation to practical utility, the Endless seeks to deliver on the promise of decentralized technologies by enabling user empowerment and collaborative value creation.

The core values of Endless include:

Security and Privacy as Foundational Elements

Endless ensures high levels of security and privacy protection for users throughout their interactions by leveraging an advanced data security and privacy architecture. This approach attracts security-conscious user groups, enhances trust in the project, and fosters deeper relationships with potential partners and investors. Endless’s data security and privacy framework relies on several key technologies: dynamic end-to-end encryption, data isolation and access control, zero-knowledge proofs, and storage security based on distributed key management and redundant encryption.

Developer and Project-Centric Modular Design

As a decentralized technology development platform, Endless introduces an innovative distributed cloud component protocol, redefining development approaches through its modular component framework. The Endless distributed cloud component protocol offers an open component marketplace and a rich suite of essential components, enabling developers to easily build and deploy Web3 applications through flexible component combinations without requiring an in-depth understanding of complex blockchain technology. This feature significantly lowers technical barriers, allowing Web2 developers to transition rapidly into the Web3 space.

User-Friendly Design with Low Barriers

To optimize user experience, the Endless introduces a gas subsidy mechanism that allows developers or project teams to cover gas fees required for blockchain transactions. Through this mechanism, users can explore DApp functionalities without bearing transaction costs, particularly beneficial for new users who can experience and understand Web3 applications without financial barriers. This feature also enables developers to promote their DApps more effectively, increasing user engagement and activity. The gas subsidy mechanism holds strategic importance in driving Web3 adoption and promoting application deployment.

AI Integration for Ecosystem Innovation and Enhanced User Experience

Endless deeply integrates AI capabilities with the platform’s decentralized architecture, empowering Web3 applications and accelerating the expansion of value-driven use cases. By incorporating advanced AI models, Endless brings AI capabilities to various application scenarios, such as automated execution of smart contracts, intelligent data analytics, automated processing, personalized recommendations, smart customer service, and dynamic risk management. This integration significantly enhances user experience and application engagement. By embedding AI technology within the Endless platform, developers can streamline their development processes, achieve intelligent user interactions and data processing, and provide users with personalized and efficient services, boosting engagement through precise recommendations and automated workflows.

By integrating AI technology, Endless will leverage decentralized storage solutions to safeguard user data privacy and security, providing users with customized and secure services.

Achieving True Economic Value through Co-Creation

Beyond innovations in technical architecture, Endless supports a truly decentralized co-creation economy. In the Endless ecosystem, users can share in ecosystem growth benefits through their participation and contributions, rather than relying on centralized platforms for value distribution.

Through smart contracts, creator economy innovations, and decentralized governance, the Endless ensures that users receive rewards for contributing content, providing services, or participating in community governance. This approach fosters user engagement, creating a diverse, secure, and user-centric ecosystem. Endless helps users break free from the constraints of traditional centralized platforms, granting them true autonomy and enabling them to earn fair rewards through transparent and equitable mechanisms.

\

Start here to get into the core concepts of the Endless blockchain. Then review our research papers and the Endless source code found in the Endless repository of GitHub while continuing your journey through this site. The source contains READMEs and code comments invaluable to developing on Endless.

Libraries

Endless provides multiple useful libraries for developers. The complete up-to-date docs can be found here.

Tutorials

If you are new to the Endless blockchain, begin with these tutorials before you get into in-depth development. These tutorials will help you become familiar with how to develop for the Endless blockchain using the Endless SDK.

Your First Transaction

How to generate, submit and verify a transaction to the Endless blockchain.

Your First NFT

Learn the Endless token interface and how to use it to generate your first NFT. This interface is defined in the Move module.

Your First Coin

Learn how to deploy and manage a coin. The coin interface is defined in the Move module.

Your First Fungible Asset

Learn how to deploy and manage a fungible asset. The fungible asset interface is defined in the Move module.

Your First Move Module

Write your first Move module for the Endless blockchain.

Your First Multisig

Learn how to perform operations using Off-Chain K-of-N multi-signer authentication.

Getting Stared

Start Learning

Learn the key concepts specific to Endless development.

The Endless blockchain account addresses use Base58 encoding and have the following characteristics:

1. The length of most regular account addresses is between 43 and 44 characters.

2. You can quickly differentiate between accounts by checking the first and last few characters of the address.

3. Vanity addresses are supported.

Sponsored Transactions

Sponsored transactions on the Endless chain refer to transactions where the gas fees are paid by the contract invoked by the transaction.

On the Endless blockchain, executing transactions requires a fee, also known as a gas fee, which is typically paid in the native token of the Endless chain (EDS). Gas fees are paid to the validators of the Endless chain to ensure network security. However, for new users, especially those transitioning from Web 2.0, this requirement can increase the barrier to entry.

Sponsored transactions lower the difficulty of interacting with contracts for users, particularly beginners. By leveraging sponsored transaction technology, contracts can make it easier for users to interact while ensuring the contract itself covers the gas fees, thereby maintaining stable chain operations.

Start

The Endless Blockchain

Endless is a per-transaction versioned database. When transactions are executed, the resulting state of each transaction is stored separately and thus allows for more granular data access. This is different from other blockchains where only the resulting state of a block (a group of transactions) is stored.

Blocks are still a fundamental unit within Endless. Transactions are batched and executed together in a block. In addition, the proofs within storage are at the block-level granularity. The number of transactions within a block varies depending on network activity and a configurable maximum block size limit. As the blockchain becomes busier, blocks will likely contain more transactions.

System transactions

Each Endless block contains both user transactions and special system transactions to mark the beginning and end of the transaction batch. Specifically, there are two system transactions:

The EndlessBFT consensus protocol provides fault tolerance of up to one-third of malicious validator nodes.

Validator node components

Mempool

Mempool is a component within each node that holds an in-memory buffer of transactions that have been submitted to the blockchain, but not yet agreed upon or executed. This buffer is replicated between validator nodes and fullnodes.The JSON-RPC service of a fullnode sends transactions to a validator node's mempool. Mempool performs various checks on the transactions to ensure transaction validity and protect against DOS attacks. When a new transaction passes initial verification and is added to mempool, it is then distributed to the mempools of other validator nodes in the network.When a validator node temporarily becomes a leader in the consensus protocol, consensus pulls the transactions from mempool and proposes a new transaction block. This block is broadcast to other validators and contains a total ordering over all transactions in the block. Each validator then executes the block and submits votes on whether to accept the new block proposal.

Learn the Move Language

To begin your journey in developing Move, we provide the following resources:

• Your first move module to walks you through compiling, deploying, and interacting with Move.

Introduction

Welcome to Move, a next generation language for secure, sandboxed, and formally verified programming. It has been used as the smart contract language for several blockchains including Endless. Move allows developers to write programs that flexibly manage and transfer assets, while providing the security and protections against attacks on those assets. However, Move has been developed with use cases in mind outside a blockchain context as well.

Move takes its cue from by using resource types with move (hence the name) semantics as an explicit representation of digital assets, such as currency.

Move Tutorial

Please refer to the .

Global Storage - Structure

The purpose of Move programs is to read from and write to tree-shaped persistent global storage. Programs cannot access the filesystem, network, or any other data outside of this tree.

In pseudocode, the global storage looks something like:

Structurally, global storage is a consisting of trees rooted at an account address. Each address can store both resource data values and module code values. As the pseudocode above indicates, each address can store at most one resource value of a given type and at most one module with a given name.

Target Audience

The target users of Endless include Web2 developers, Web3 developers, project teams, and general users. Addressing the diverse needs and challenges of different user groups, Endless provides comprehensive solutions aimed at promoting the adoption and application of Web3 technology.

Below is a detailed analysis of each target group along with the corresponding application scenarios:

Web2 Developers

Web3 development involves complex technologies such as smart contracts, decentralized storage, and consensus mechanisms. For developers accustomed to the Web2 technology stack, transitioning to Web3 presents a steep learning curve. Web2 developers typically work with traditional programming languages and frameworks such as JavaScript, Python, and Java. To transition to Web3, they need to master new development languages such as Solidity, Rust, and Move, as well as blockchain technology. This transition not only requires learning an entirely new development paradigm but also demands an in-depth understanding of how decentralized systems operate.

To address the challenges faced by Web2 developers, Endless offers a series of pre-built modules and multi-language SDKs, enabling developers to build DApps using familiar programming languages such as JavaScript and Python. These modular components cover core functionalities such as payments, identity authentication, and data storage, allowing developers to focus on business logic without delving deeply into the underlying technical implementations. Additionally, Endless provides comprehensive documentation, tutorials, and community support to help developers quickly grasp key Web3 development concepts and tools. This not only lowers the learning barrier but also fosters a collaborative ecosystem where developers can share knowledge and insights.

Web3 Developers

Web3 developers require a high-performance blockchain platform to support the development of complex DApps, particularly those handling high-concurrency user transactions. The efficiency and stability of the system are essential for ensuring a seamless user experience. Furthermore, Web3 developers aim to create innovative functionalities and applications that cater to evolving market demands and user expectations.

For Web3 developers, Endless delivers powerful computing and data processing capabilities to ensure exceptional DApp performance even under high workloads. Its architectural design supports horizontal scalability, allowing for seamless growth in user base and business expansion. Additionally, Endless provides smart contract automation tools and AI-powered analytics, enabling developers to incorporate intelligent elements into contract design and execution. This enhances development efficiency and optimizes the overall intelligence of applications. Using the Endless platform, Web3 developers can build high-frequency trading applications or leverage AI functionalities to automate and refine smart contract execution.

Project Teams

In a highly competitive market environment, increasing user engagement and activity is a key priority for project teams. The ability to attract and retain users effectively is directly linked to the long-term success of a project. Additionally, project teams require efficient tools for managing communities and token economies to ensure sustained community engagement and token market stability.

For project teams, Endless provides an infrastructure that supports multi-currency payments and smart contract security, enhancing transaction convenience and security. Through the platform's token management tools, project teams can effortlessly manage token issuance, distribution, and governance, ensuring a healthy token economy. Additionally, Endless offers a range of private domain operation tools, including precision marketing, airdrop campaigns, and social platform integrations, helping project teams rapidly scale their community presence. These tools not only boost user interaction frequency but also enhance user engagement and loyalty.

General Users

Web2 users prioritize data privacy, while Web3 users place greater emphasis on decentralization and transparency. General users expect blockchain applications to provide a user experience comparable to Web2 applications while benefiting from the privacy protection inherent in decentralization. Additionally, users seek to avoid complex operations and high usage costs, aiming for a seamless and intuitive experience akin to traditional internet applications.

To cater to general users, Endless supports developers at both the protocol and component levels in optimizing user interfaces and enabling a seamless transition from Web2 to Web3. This ensures that users can enjoy the convenience and smooth experience of traditional applications. Furthermore, Endless integrates decentralized storage and zero-knowledge proof technologies to safeguard user data privacy and security.

Business Model

As a blockchain-based ecosystem protocol, Endless has a diversified revenue stream. Below are the monetization models of Endless within the Web3 Genesis Cloud ecosystem:

Component Marketplace

The Endless Component Marketplace is a decentralized trading platform for components, where developers can publish and sell self-developed components. Users can browse, purchase, and integrate these components into their applications through the Endless platform. All transactions are executed automatically via smart contracts to ensure transparency and security. Endless charges a fixed percentage as a transaction fee for each sale. This fee model not only incentivizes developers to continuously innovate and release high-quality components but also provides a stable revenue stream for the platform.

By offering ready-made and easily integratable components, Endless significantly reduces developers' time to market. These components cover a wide range of functionalities, from user authentication to payment processing, enabling developers to focus on business logic without having to build complex underlying infrastructures. Additionally, Endless continuously expands its component library and offers developer support and marketing promotion services to attract more developers into its ecosystem. This strategy not only enhances the platform's market appeal but also strengthens its competitive edge in the Web3 industry.

SDK and API Services

Endless offers multi-language SDKs compatible with existing technology stacks, along with comprehensive documentation, tutorials, and technical support to help developers quickly master Web3 development. This lowers the entry barriers for Web2 developers, allowing them to smoothly transition into the Web3 development environment.

The Endless SDK and API follow a pay-per-call billing model, flexible to accommodate the needs of different developers, with fees calculated based on actual usage. Additionally, for enterprise customers requiring long-term and stable services, Endless provides a subscription-based model, enabling users to pay a fixed monthly or annual fee for unlimited or high-quota API access.

Cloud Server and Storage Fees

Endless offers flexible cloud service packages, allowing developers to choose different storage and bandwidth plans according to the scale and needs of their projects. Its pay-as-you-go model ensures that developers only pay for the resources they actually use, reducing operational costs. Furthermore, leveraging a distributed storage architecture and optimized network acceleration mechanisms, Endless enhances DApp access speed and stability, ensuring a smooth user experience. By providing efficient and secure storage and data transmission services, Endless not only generates a stable revenue stream but also reinforces its market competitiveness.

Node Staking

Endless token holders can stake their tokens to validator nodes to earn network staking rewards. Additionally, as a validator node operator, Endless accepts delegated staking from project teams or individual users and generates revenue through management fees or staking interest. The entire staking process is automated via smart contracts to ensure transparency and security. This mechanism not only creates revenue for the platform but also strengthens the security and stability of the network.

On-Chain Transaction Fees

All on-chain transactions within the Endless ecosystem, including component transactions and DApp operations, require Endless tokens for gas fees. A portion of the collected gas fees will be used for token burning to maintain the economic equilibrium, while the remainder will be allocated to validator nodes and the ecosystem fund to support the sustainable development of the Endless ecosystem.

DApp and Mini-Program Distribution

Endless provides a globalized application distribution platform, enabling developers to publish and promote their DApps and mini-programs. The platform is equipped with analytics tools and user feedback systems to help developers optimize their products and enhance user satisfaction. Endless monetizes this service by charging application promotion fees or sharing revenue with developers. This model not only generates economic benefits for the platform but also provides developers with additional exposure and marketing channels. Additionally, Endless regularly hosts developer conferences and application competitions to foster technological innovation and ecosystem collaboration, promoting long-term growth.

Web3 Gaming and NFT Marketplace

Endless builds a vibrant gaming and NFT marketplace to encourage long-term user engagement and increase platform retention. The platform supports user-generated content (UGC), allowing users to create and trade gaming assets or NFT artworks, thus enhancing interaction and fostering a sense of community. Moreover, Endless provides comprehensive tools and resources to empower developers for innovation in Web3 gaming and NFTs. The platform continuously expands its market influence by collaborating with well-known IPs and hosting creative competitions.

In the Web3 gaming sector, Endless generates revenue through in-game economic activities such as virtual item sales and in-game advertisements. In the NFT marketplace, Endless earns revenue by charging a fixed percentage as a transaction fee for NFT sales. Users need to pay transaction fees when conducting NFT trades on the platform. Additionally, Endless offers NFT minting and display services, further diversifying its revenue streams.

Endless Token Value

The value of the Endless token is a crucial component of the Endless business ecosystem. For more details, please refer to section "5.2 Endless Economic Model."

What are Move Scripts?

Move Scripts are a way to run multiple public functions on Endless in a single transaction. This is similar to deploying a helper module that would do common tasks, but allows for the flexibility of not having to deploy beforehand.

An example would be a function to transfer a half of a user's balance to another account. This is something that is easily programmable, but likely would not need a module deployed for it:

script {
  use std::signer;
  use endless_framework::coin;
  use endless_framework::endless_account;

  fun transfer_half<Coin>(caller: &signer, receiver_address: address) {
    // Retrieve the balance of the caller
    let caller_address: address = signer::address_of(caller);
    let balance: u64 = coin::balance<Coin>(caller_address);

    // Send half to the receiver
    let half = balance / 2;
    endless_account::transfer_coins<Coin>(caller, receiver_address, half);
  }
}

Learn more about using Move Scripts

• Writing scripts

• Compiling scripts

• Running scripts

More details

For more details on Move Scripts, checkout:

• Move Book on Scripts

• Tutorial on Scripts

Vision: Establishing a Collaborative Ecosystem for Web3 Connectors

Endless is a Web3 platform designed to bridge Web2 and AI Agents, providing a foundation for developers to innovate freely. Through an open and collaborative model, Endless lowers the barriers to Web3 development, enabling global developers to share data sovereignty and ecosystem benefits, collectively shaping a decentralized future.

Endless Developer Hub: Empowering Developers

The future of Web3 belongs to every developer willing to explore and innovate. As a project dedicated to the Web3 ecosystem, Endless not only provides a robust technological infrastructure but also offers a comprehensive developer support system to help global developers build high-quality, innovative decentralized applications (DApps) and Web3 infrastructure.

Endless Developer Hub serves as a dedicated platform for developers, focusing on Web3 technology advancements, developer growth, and community co-building, helping developers unlock infinite possibilities.

\

Developer Support System

To empower developers in building applications efficiently, Endless Developer Hub provides a comprehensive and well-equipped support system:

1. Technical Support

Extensive Toolkit: Offers SDKs and API documentation to help developers get started quickly.

Developer Showcase & App Demo: Provides example projects and real-world case studies to lower the development threshold.

Dedicated Technical Support Team: A specialized support team is available to promptly resolve development issues and assist developers in optimizing their projects.

2. Community Support

Building a Strong Developer Network: Developers can communicate and collaborate through multiple channels, including the official developer portal, forums, GitHub open-source community, Medium, and online seminars.

Community Governance Rights: Active contributors gain priority participation in community governance, allowing them to vote on key proposals and shape the future of the ecosystem.

3. Resource Sharing & Market Support

Ecosystem Traffic Support: Developers receive priority access to traffic and market resources within the Endless ecosystem, accelerating their project’s growth.

Ecosystem Partnership Program: By participating in the Endless Ecosystem Partnership Program, developers can collaborate with other projects, share resources, and co-create more application scenarios.

Join the Endless Developer Ecosystem and Innovate for the Future!

Endless Developer Hub is more than just a technical community; it is an accelerator for developers' growth. If you aspire to make an impact in Web3 and collaborate with top-tier Web3 pioneers worldwide, then this is the place for you!

Why Join Endless Developer Hub?

✅ Comprehensive technical, market, and community support

✅ Direct access to the Endless core team for prompt development assistance

✅ Participation in incentive programs to receive ecosystem support and rewards

✅ Collaborate with top Web3 developers globally to build groundbreaking applications

Whether you are an independent developer or a team looking to explore the future of Web3, we welcome you to join us! 📣 Join the Endless Developer Program! \

Website:

GitHub Community:

EndlessHub Email: [email protected]

Luffa Channel:

Luffa Official Endless Developer Community:

Telegram:If you're looking for new opportunities at the intersection of Web3 & AI, apply for the Endless Ecosystem Incentive Program and build the next generation of innovative applications!

\

Address

address is a built-in type in Move that is used to represent locations (sometimes called accounts) in global storage. An address value is a 256-bit (32-byte) identifier. At a given address, two things can be stored: Modules and Resources.

Although an address is a 256-bit integer under the hood, Move addresses are intentionally opaque---they cannot be created from integers, they do not support arithmetic operations, and they cannot be modified. Even though there might be interesting programs that would use such a feature (e.g., pointer arithmetic in C fills a similar niche), Move does not allow this dynamic behavior because it has been designed from the ground up to support static verification.

You can use runtime address values (values of type address) to access resources at that address. You cannot access modules at runtime via address values.

Addresses and Their Syntax

Addresses come in two flavors, named or numerical. The syntax for a named address follows the same rules for any named identifier in Move. The syntax of a numerical address is not restricted to hex-encoded values, and any valid u256 numerical value can be used as an address value, e.g., 42, 0xCAFE, and 2021 are all valid numerical address literals.

To distinguish when an address is being used in an expression context or not, the syntax when using an address differs depending on the context where it's used:

• When an address is used as an expression the address must be prefixed by the @ character, i.e., @<numerical_value> or @<named_address_identifier>.

• Outside of expression contexts, the address may be written without the leading @ character, i.e., <numerical_value> or <named_address_identifier>.

In general, you can think of @ as an operator that takes an address from being a namespace item to being an expression item.

Named Addresses

Named addresses are a feature that allow identifiers to be used in place of numerical values in any spot where addresses are used, and not just at the value level. Named addresses are declared and bound as top level elements (outside of modules and scripts) in Move Packages, or passed as arguments to the Move compiler.

Named addresses only exist at the source language level and will be fully substituted for their value at the bytecode level. Because of this, modules and module members must be accessed through the module's named address and not through the numerical value assigned to the named address during compilation, e.g., use my_addr::foo is not equivalent to use 0x2::foo even if the Move program is compiled with my_addr set to 0x2. This distinction is discussed in more detail in the section on Modules and Scripts.

Examples

Global Storage Operations

The primary purpose of address values are to interact with the global storage operations.

address values are used with the exists, borrow_global, borrow_global_mut, and move_from operations.

The only global storage operation that does not use address is move_to, which uses signer.

Ownership

As with the other scalar values built-in to the language, address values are implicitly copyable, meaning they can be copied without an explicit instruction such as copy.

The Move Programming Language

Introduction

Getting Started

• Modules and Scripts

• Move Tutorial

Primitive Types

• Integers

• Bool

• Address

• Vector

Basic Concepts

• Local Variables and Scopes

• Equality

• Abort and Assert

• Conditionals

Global Storage

• Global Storage Structure

• Global Storage Operators

Reference

• Standard Library

• Coding Conventions

Node Networks and Synchronization

Validator nodes and fullnodes form a hierarchical structure with validator nodes at the root and fullnodes everywhere else. The Endless blockchain distinguishes two types of fullnodes: validator fullnodes and public fullnodes. Validator fullnodes connect directly to validator nodes and offer scalability alongside DDoS mitigation. Public fullnodes connect to validator fullnodes (or other public fullnodes) to gain low-latency access to the Endless network.

Node types

Endless operates with these node types:

• Validator nodes (VNs) - participates in consensus and drives transaction processing.

• Validator fullnodes (VFNs) - captures and keeps up-to-date on the state of the blockchain; run by the validator operator, so it can connect directly to the validator node and therefore serve requests from public fullnodes. Otherwise, it works like a public fullnode.

• Public fullnodes (PFNs) - run by someone who is not a validator operator, PFNs cannot connect directly to a validator node and therefore rely upon VFNs for synchronization.

• Archival nodes (ANs) - is a fullnode that contains all blockchain data since the start of the blockchain's history.

Separate network stacks

The Endless blockchain supports distinct networking stacks for various network topologies. For example, the validator network is independent of the fullnode network. The advantages of having separate network stacks include:

• Clean separation between the different networks.

• Better support for security preferences (e.g., bidirectional vs server authentication).

• Allowance for isolated discovery protocols (i.e., on-chain discovery for validator node's public endpoints vs. manual configuration for private organizations).

Node synchronization

Endless nodes synchronize to the latest state of the Endless blockchain through two mechanisms: consensus or state synchronization. Validator nodes will use both consensus and state synchronization to stay up-to-date, while fullnodes use only state synchronization.

For example, a validator node will invoke state synchronization when it comes online for the first time or reboots (e.g., after being offline for a while). Once the validator is up-to-date with the latest state of the blockchain it will begin participating in consensus and rely exclusively on consensus to stay up-to-date. Fullnodes, however, continuously rely on state synchronization to get and stay up-to-date as the blockchain grows.

State synchronizer

Each Endless node contains a State Synchronizer component which is used to synchronize the state of the node with its peers. This component has the same functionality for all types of Endless nodes: it utilizes the dedicated peer-to-peer network to continuously request and disseminate blockchain data. Validator nodes distribute blockchain data within the validator node network, while fullnodes rely on other fullnodes (i.e., validator nodes or public fullnodes).

Endless Project Development Goals and Key Milestones

Short-Term Plan (1-2 Years)

1 Key Areas of Development and Operations

Optimization of Modular Component Protocols:Deepen the stan-dardization of component interface designs and optimize component perfor- mance to enhance flexibility and scalability,allowing adaptation to diverse application scenarios.

\

All Endless releases are available on GitHub: Endless Release

Currently, we offer the endless-cli, endless-node for all platforms, including Ubuntu and Windows. More tools will be released in the future.

Endless-CLI

• Ubuntu 22.04 (x86_64):

• Ubuntu-24.04 (x86_64):

• Windows (x86_64):

• macOS:

Endless-node

• Ubuntu 22.04 (x86_64):

• Ubuntu-24.04 (x86_64):

• Windows (x86_64):

• macOS:

How can I write Move Scripts?

Move scripts can be written in tandem with Move contracts, but it's highly suggested to use a separate Move package for it. This will make it easier for you to determine which bytecode file comes from the script.

Package layout

The package needs a Move.toml and a sources directory, similar to code modules.

For example, we may have a directory layout like:

Script syntax

Scripts can be written exactly the same as modules on Endless. Imports can be used for any dependencies in the Move.toml file, and all public functions, including entry functions, can be called from the contract. There are a few limitations:

• There must be only one function in the contract, it will compile to that name.

• Input arguments can only be one of [u8, u16, u32, u64, u256, address, bool, signer,

An example below:

For more specific details see: Move Book on Scripts

An Endless node is an entity of the Endless ecosystem that tracks the state of the Endless blockchain. Clients interact with the blockchain via Endless nodes. There are two types of nodes:

• Validator nodes

• Fullnodes

Each Endless node comprises several logical components:

• REST service

• Mempool

• Execution

• Virtual Machine

• Storage

• State synchronizer

The Endless software can be configured to run as a validator node or as a fullnode.

Overview

Fullnodes can be run by anyone. Fullnodes verify blockchain history by either re-executing all transactions in the history of the Endless blockchain or replaying each transaction's output. Fullnodes replicate the entire state of the blockchain by synchronizing with upstream participants, e.g., other fullnodes or validator nodes. To verify blockchain state, fullnodes receive the set of transactions and the accumulator hash root of the ledger signed by the validators. In addition, fullnodes accept transactions submitted by Endless clients and forward them directly (or indirectly) to validator nodes. While fullnodes and validators share the same code, fullnodes do not participate in consensus.

Depending on the fullnode upstream, a fullnode can be called as a validator fullnode, or a public fullnode:

• Validator fullnode state sync from a validator node directly.

• Public fullnode state sync from other fullnodes.

There's no difference in their functionality, only whether their upstream node is a validator or another fullnode. Read more details about network topology here

Third-party blockchain explorers, wallets, exchanges, and dapps may run a local fullnode to:

• Leverage the REST interface for blockchain interactions.

• Get a consistent view of the Endless ledger.

• Avoid rate limitations on read traffic.

• Run custom analytics on historical data.

How can I compile Move Scripts?

Move scripts can be compiled with the already existing Endless Move compiler in the Endless CLI. For more on how to install and use the Endless CLI with Move contracts, go to the Working With Move Contracts page.

Once you have the Endless CLI installed, you can compile a script by running the following command from within the script package:

endless move compile

There will then be compiled bytecode files under build/ with the same name as the function in Move.

For example this script in package transfer_half, would compile to build/transfer_half/bytecode_scripts/transfer_half.mv

Additionally, there is a convenience function for a package with exactly one script with the below command:

Providing output like below returning the exact location of the script and a hash for convenience

The vision of the Endless Web3 Genesis Cloud is to achieve true user empowerment and value co-creation through its innovative decentralized technology platform. By enabling Web3 applications that deliver genuine user value, the Genesis Cloud allows users to actively participate in value creation and sharing within the digital economy, thereby propelling Web3 toward sustainable prosperity.

The Endless Web3 Genesis Cloud is a truly secure Web3 cloud service platform that guarantees user privacy, virtual asset security, and data sovereignty. It offers Web2 application developers comprehensive support—from smart contract development, decentralized storage, and modular components to enhanced information security and privacy protections—significantly reducing the barriers to transitioning from Web2 to Web3 and improving the Web3 user experience.

World’s first distributed cloud-based intelligent component protocol

The Endless Web3 Genesis Cloud is the world’s first distributed cloud-based intelligent component protocol, integrating a wide range of advanced technological solutions such as AI, serverless architecture, full distributed frameworks, relay networks, and various SDKs and APIs. These innovations enable developers to rapidly and seamlessly build decentralized applications (DApps) for Web3, utilizing any programming language while delivering a user experience comparable to Web2 applications.

Bool

bool is Move's primitive type for boolean true and false values.

Resource Accounts

A is a developer feature used to manage resources independent of an account managed by a user, specifically publishing modules and providing on-chain-only access control, e.g., signers.

Typically, a resource account is used for two main purposes:

• Store and isolate resources; a module creates a resource account just to host specific resources.

Creating Objects

When first creating an object, it will have a resource named 0x1::object::ObjectCore added. This contains metadata about the object, as well as information about the owner of the object.

Objects can be created in multiple ways depending on your needs. They can be broken into two main types of objects:

• Deletable objects

Endless Networks

On Endless, on-chain state is organized into resources and modules. These are then stored within the individual accounts. This is different from other blockchains, such as Ethereum, where each smart contract maintains their own storage space. See Accounts for more details on accounts.

Resources vs Instances

Move modules define struct definitions. Struct definitions may include the abilities such as key or store. Resources are struct instance with The key ability that are stored in global storage or directly in an account. The store

Conditionals

An if expression specifies that some code should only be evaluated if a certain condition is true. For example:

The condition must be an expression of type bool.

An if expression can optionally include an else clause to specify another expression to evaluate when the condition is false.

What are objects?

The Move language controls access to resources using the store ability and accounts. The Object model provides a way to associate a collection of resources with a single address, using centralized resource control and ownership management. An Object is a container for resources at a single address which can be managed and accessed as a group for efficiency. The contract creating an Object can define custom behaviors around changes and transfers of those resources.

It's simply represented as an ObjectCore struct, which keeps track of the owner of the Object and transfer permissions. Along with the ability to store resources with an ObjectGroup. You can find more technical details at the Object standard page, and view the code at the framework generated object documentation.

Move Standard

Endless Object

The allows Move to represent a complex type as a set of resources stored within a single address and offers a rich capability model that allows for fine-grained resource control and ownership management.

Endless allows for permissionless publishing of modules within a package as well as upgrading those that have appropriate compatibility policy set.

A module contains several structs and functions, much like Rust.

During package publishing time, a few constraints are maintained:

• Both Structs and public function signatures are published as immutable.

• Only when a module is being published for the first time, and not during an upgrade, will the VM search for and execute an init_module(account: &signer) function. The signer of the account that is publishing the module is passed into the init_module

Design Purpose

Due to the comparatively massive volumes sold during early-stage rounds, projects may encounter extreme selling pressure after the IDO and after the token has been posted on Centralized Exchange – CEX / Decentralized Exchange – DEX. It significantly lowers the price of tokens by increasing the total amount of tokens in circulation.

For the Token Economy to stay sustainable & effective, the majority of tokens must be kept by investors rather than being sold on the market. Members can stop the value of its token from sinking by locking up tokens. Additionally, it prevents team members from selling their tokens as soon as trade begins, safeguarding holders’ interests.

Endless's locking_coin_ex contract manages token distribution via a locking and unlocking mechanism, ensuring gradual token release over a defined period to control circulation.

The contract allows any user to:

• Lock any amount of any fungible token, including native EDS.

• Specify the recipient account for unlocked tokens.

• Define a two-stage release plan:

  • Specify a portion of tokens for immediate release at a designated epoch.

API

The following are the main API interfaces provided by this contract:

View Functions

Query total lock amount

total_locks(token_address: address): u128

• Function: Query the total locked amount for the specified token address.

• Parameters: token_address - The token address.

• Return value: Total locked amount.

List all stakers

public fun get_all_stakers(token_address: address): vector<address>

• Function: Query all staker addresses for the specified token address.

• Parameters: token_address - The token address.

• Return value: List of staker addresses.

Query one of staker's token locking amount

public fun staking_amount(token_address: address, recipient: address): u128

• Function: Query the staking amount for the specified staker at the specified token address.

• Parameters: token_address - The token address, recipient - The staker address.

• Return value: Staking amount.

UnLockInfo

the structure contains receiver's address when release, and next release plan(amount and related epoch)

List all staker's token release-plan

public fun get_all_stakers_unlock_info(token_address: address): vector<UnlockInfo>

• Function: Query the unlock information for all stakers at the specified token address.

• Parameters: token_address - The token address.

• Return value: List of unlock information.

Query one of staker's token release-plan

public fun get_unlock_info(token_address: address, sender: address): UnlockInfo

• Function: Query the unlock information for the specified staker at the specified token address.

• Parameters: token_address - The token address, sender - The staker address.

• Return value: Unlock information.

Management Functions

Add Locking Plan

public entry fun add_locking_plan_from_unlocked_balance(sender: &signer, token_address: address, receiver: address, total_coins: u128, first_unlock_bps: u64, first_unlock_epoch: u64, stable_unlock_interval: u64, stable_unlock_periods: u64)

• Function: Add a locking plan from the unlocked balance.

• Parameters:

  • sender - The signer,

  • token_address - The token address,

Add Locking Plan

public entry fun add_locking_plan(sender: &signer, token_address: address, receiver: address, total_coins: u128, first_unlock_bps: u64, first_unlock_epoch: u64, stable_unlock_interval: u64, stable_unlock_periods: u64)

• Function: Add a locking plan.

• Parameters:

  • sender - The signer,

  • token_address - The token address,

Claim leased tokens

public entry fun claim(sender: &signer, token_address: address, amount: u128)

• Function: Claim unlocked tokens.

• Parameters:

  • sender - The signer,

  • token_address - The token address,

An account on the Endless blockchain represents access control over a set of assets including on-chain currency and NFTs. In Endless, these assets are represented by a Move language primitive known as a resource that emphasizes both access control and scarcity.

Each account on the Endless blockchain is identified by a (base58 encoded) account address.

Different from other blockchains where accounts and addresses are implicit, accounts on Endless are explicit and need to be created before they can execute transactions. The account can be created explicitly or implicitly by transferring Endless tokens (EDS) there. See the Creating an account section for more details. In a way, this is similar to other chains where an address needs to be sent funds for gas before it can send transactions.

There are three types of accounts on Endless:

• Standard account - This is a typical account corresponding to an address with a corresponding pair of public/private keys.

• Resource account - An autonomous account without a corresponding private key used by developers to store resources or publish modules on-chain.

• Object - A complex set of resources stored within a single address representing a single entity.

Account address example

Account addresses are Base58-encoded strings derived from 32-byte values, typically have a length of approximately 43 characters. See the Your First Transaction for an example of how an address appears, reproduced below:

Alice: BtXV19CoB1F3maLzzmmV8UaSZC4Jo3wHU9PDHeuwDo99

Creating an account

When a user requests to create an account, for example by using the Endless, the following steps are executed:

• Select the authentication scheme for managing the user's account, e.g., Ed25519.

• Generate a new private key, public key pair.

• Combine the public key with the public key's authentication scheme to generate a 32-byte authentication key and the account address.

The user should use the private key for signing the transactions associated with this account.

Account sequence number

The sequence number for an account indicates the number of transactions that have been submitted and committed on-chain from that account. Committed transactions either execute with the resulting state changes committed to the blockchain or abort wherein state changes are discarded and only the transaction is stored.

Every transaction submitted must contain a unique sequence number for the given sender's account. When the Endless blockchain processes the transaction, it looks at the sequence number in the transaction and compares it with the sequence number in the on-chain account. The transaction is processed only if the sequence number is equal to or larger than the current sequence number. Transactions are only forwarded to other mempools or executed if there is a contiguous series of transactions from the current sequence number. Execution rejects out of order sequence numbers preventing replay attacks of older transactions and guarantees ordering of future transactions.

Authentication key

The initial account address is set to the authentication key derived during account creation. However, the authentication key may subsequently change, for example when you generate a new public-private key pair, public keys to rotate the keys. An account address never changes.

The Endless blockchain supports authentication schemes

Ed25519 authentication

To generate an authentication key and the account address for an Ed25519 signature:

1. Generate a key-pair: Generate a fresh key-pair (privkey_A, pubkey_A). The Endless blockchain uses the PureEdDSA scheme over the Ed25519 curve, as defined in RFC 8032.

2. Derive a 32-byte authentication key: Derive a 32-byte authentication key from the pubkey_A:

3. where | denotes concatenation. The

State of an account

The state of each account comprises both the code (Move modules) and the data (Move resources). An account may contain an arbitrary number of Move modules and Move resources:

• Move modules: Move modules contain code, for example, type and procedure declarations; but they do not contain data. A Move module encodes the rules for updating the Endless blockchain's global state.

• Move resources: Move resources contain data but no code. Every resource value has a type that is declared in a module published on the Endless blockchain.

Access control with signers

The sender of a transaction is represented by a signer. When a function in a Move module takes signer as an argument, the Endless Move VM translates the identity of the account that signed the transaction into a signer in a Move module entry point. See the below Move example code with signer in the initialize and withdraw functions. When a signer is not specified in a function, for example, the below deposit function, then no signer-based access controls will be provided for this function:

Events are emitted during the execution of a transaction. Each Move module can define its own events and choose when to emit the events upon execution of the module. Endless Move supports two form of events: module events and EventHandle events. Module events are the modern event mechanism and shipped in the framework release 1.7. EventHandle events are deprecated and shipped with the original framework. Because of how blockchains work, EventHandle events will likely never be fully removed from Endless.

Module Events

Module events are global event streams identified by a struct type. To define an event struct, add the attribute #[event] to a normal Move struct that has drop and store abilities. For example,

And then create and emit the event:

Examples of coin transfer on testnet is here(https://scan.endless.link/txn/3143636/events?network=testnet) . Indices 0(Withdraw), 1(Deposit) are module events of type 0x1::fungible_asset.

Access in Tests

Events are stored in a separate merkle tree called event accumulator for each transaction. As it is ephemeral and hence independent of the state tree, MoveVM does not have read access to events when executing transaction in production. But in tests, Endless Move supports two native functions that read emitted events for testing and debugging purposes:

API Access

There is support for querying both module events and EventHandle events using the .

Event-Handle Event

EventHandle is identified by a globally unique value, GUID, and a per-event sequence number and stored within a resource. Each event within a stream has a unique sequence number derived from the EventHandle sequence number.

For example, during a EDS Coin transfer, 0x1::fungible_assert module will emit event of Withdraw and Deposit associated with the sender and receiver's EDS CoinStore. This data is stored within the ledger and can be queried via the REST interface's .

Assuming that an account GinLHfukKufLYJ757NfyCLpeDvjeNjLPQwc7waco3o7b had sent coins to another account, the following query could be made to the REST interface: https://rpc-test.endless.link/v1/accounts/GinLHfukKufLYJ757NfyCLpeDvjeNjLPQwc7waco3o7b/events/0x1::fungible_asset::FungibleStore<0x1::endless_coin::EndlessCoin>/owner. The output would be all WithdrawEvents stored on that account, it would look like

Each registered event has a unique key. The key 0x0000000000000000caa60eb4a01756955ab9b2d1caca52ed maps to the event 0x1::fungible_asset::FungibleStore<0x1::endless_coin::EndlessCoin>/sent_events registered on account GinLHfukKufLYJ757NfyCLpeDvjeNjLPQwc7waco3o7b.

These represent event streams, or a list of events with each entry containing a sequentially increasing sequence_number beginning at 0, a type, and data. Each event must be defined by some type. There may be multiple events defined by the same or similar types especially when using generics. Events have associated data. The general principle is to include all data necessary to understand the changes to the underlying resources before and after the execution of the transaction that changed the data and emitted the event.

Migration to Module Events

With the release of module events, EventHandle events are deprecated. To support migration to the module events, projects should emit a module event wherever they currently emit EventHandle events. Once external systems have sufficiently adopted module events, the legacy event may no longer need to be emitted.

Note, the EventHandle events cannot and will not be deleted and hence projects that are unable to upgrade will continue to be able to leverage them.

Transaction Simulation

Image source

Transaction simulation, often referred to as "dry runs," is a method used to predict the outcome of a blockchain transaction before broadcasting it on-chain. This process is especially useful for smart contracts and decentralized applications (dApps) to ensure transactions perform as intended.

Transaction simulation plays a critical role in enhancing security and mitigating malicious activity in the Web3 ecosystem. By simulating a transaction, you can inspect it for unexpected or harmful behavior prior to execution. For instance, when interacting with a new dApp or calling a smart contract function, a simulation may reveal unauthorized token transfers or wallet access that were neither disclosed nor expected. This capability is invaluable for identifying and avoiding scams or malicious contracts designed to compromise user funds.

Designed Use Cases

1. Understanding Transaction Outcomes Blockchain transactions, particularly those involving complex smart contracts or DeFi protocols, often yield outcomes that aren't immediately apparent. Simulations clarify the consequences of executing a transaction, providing users with a detailed preview of what they are signing. For instance, in DAO voting or executing intricate financial strategies, transaction simulation can illuminate the implications of a decision, leading to safer and better-informed choices.

2. Gas Fee Estimation and Cost Savings Ethereum transactions incur gas fees, which can vary significantly based on network congestion and transaction complexity. Simulating transactions provides an accurate gas estimate, helping users avoid issues like overpaying or underpaying gas fees.

Overpaying unnecessarily increases transaction costs. Underpaying risks leaving transactions stuck in the mempool. By simulating a transaction beforehand, users can set appropriate gas limits and prices, minimizing costs and avoiding failures.

Transaction Simulation Spoofing

While transaction simulation is a powerful tool, it is inherently limited—it only predicts outcomes based on current blockchain states, without actual execution on-chain. This limitation can be exploited by attackers in what is known as transaction simulation spoofing.

In a typical spoofing scenario:

1. The attacker lures the victim to a malicious website disguised as a legitimate platform.

2. transaction simulates outputs, such as a "Claim" function, which deceptively shows that the user will receive a small amount of ETH.

3. Trusting the wallet's simulation result, the victim signs the transaction, unknowingly allowing the attacker to drain their wallet.

4. Between the simulation and actual execution, the attacker alters the on-chain contract state, causing the approved transaction to perform a different, malicious action.

Real-world Example

A victim signed a fraudulent transaction 30 seconds after an on-chain state change, resulting in the loss of 143.35 ETH.

Phishing transaction

This incident highlights the limitations of transaction simulations: on Ethereum and many other blockchains, simulation is not equivalent to "What You See Is What You Sign" (WYSIWYS).

Safety Switch in Endless Wallet

To address the limitations of transaction simulations, Endless Wallet introduces the Safe Transaction feature, equipped with a Safety Switch.

When enabled, the Safety Switch ensures that the simulation result (transaction output) is embedded within the transaction itself.

Here's how it works:

• The Safety Switch hashes the user's balance change(specifically refers to user's balance deduction) resulting from the transaction and embeds the hash into a transaction field.

• Nodes executing the transaction validate the user's actual balance change by recalculating the hash and comparing it to the embedded value.

• If the two hashes do not match, the transaction is reverted.

By default enabling the Safety Switch, users can make their transactions deterministic, effectively mitigating the risk of simulation spoofing.

Designing Dapp Considerations

Any decentralized application (Dapp) that may submit non-deterministic transactions, such as those involving dynamic deduction of the sender's account balance, should be carefully considered. Examples include:

• Liquidity pool swaps in Endless Swap, where the results depend on real-time asset ratios.

• Any contract interaction that leads to variable deductions from the sender's transaction balance.

It is crucial to address the potential impact of the "Safety Transaction" feature, which may block transaction submissions. Possible solutions include:

• Remind the end user to disable the "Safety Transaction" feature when submitting transactions via the wallet.

• Alternatively, modify the program logic to adopt a "deterministic transaction" design.

How can I run Move Scripts?

Move scripts are supported in the Endless TypeScript SDK, Endless Wallet Adapter, and in the Endless CLI.

Running scripts with the TypeScript SDK

To use a script with the TypeScript SDK, add the bytecode directly to the transaction in place of an entry function name.

Running scripts with the Endless Wallet Adapter

:::warning Not all wallets support scripts, but when the wallet supports scripts, it can be provided as below :::

Similar to the TypeScript SDK, the same inputs are accepted as a transaction type on the wallet adapter. Just simply load the bytecode as a hex string or a uint8array.

Running scripts with the CLI

Running scripts with the CLI can be run with the command

There are two ways to run it, with a pre-compiled script, or it will compile the script in-place similar to the compile step.

If you already have a compiled script, you can run it with --compiled-script-path like the example below:

Similarly, if it's not compiled, just use --script-path

Signer

signer is a built-in Move resource type. A signer is a capability that allows the holder to act on behalf of a particular address. You can think of the native implementation as being:

A signer is somewhat similar to a Unix UID in that it represents a user authenticated by code outside of Move (e.g., by checking a cryptographic signature or password).

Comparison to address

A Move program can create any address value without special permission using address literals:

However, signer values are special because they cannot be created via literals or instructions--only by the Move VM. Before the VM runs a script with parameters of type signer, it will automatically create signer values and pass them into the script:

This script will abort with code 0 if the script is sent from any address other than 0x42.

A Move script can have an arbitrary number of signers as long as the signers are a prefix to any other arguments. In other words, all of the signer arguments must come first:

This is useful for implementing multi-signer scripts that atomically act with the authority of multiple parties. For example, an extension of the script above could perform an atomic currency swap between s1 and s2.

signer Operators

The std::signer standard library module provides two utility functions over signer values:

In addition, the move_to<T>(&signer, T) global storage operator requires a &signer argument to publish a resource T under signer.address's account. This ensures that only an authenticated user can elect to publish a resource under their address.

Ownership

Unlike simple scalar values, signer values are not copyable, meaning they cannot be copied from any operation whether it be through an explicit copy instruction or through a dereference *.

Move Coding Conventions

This section lays out some basic coding conventions for Move that the Move team has found helpful. These are only recommendations, and you should feel free to use other formatting guidelines and conventions if you have a preference for them.

Naming

• Module names: should be lowercase snake case, e.g., fixed_point32, vector.

• Type names: should be camel case if they are not a native type, e.g., Coin, RoleId.

• Function names: should be lowercase snake case, e.g., destroy_empty

Imports

• All module use statements should be at the top of the module.

• Functions should be imported and used fully qualified from the module in which they are declared, and not imported at the top level.

• Types should be imported at the top-level. Where there are name clashes, as should be used to rename the type locally as appropriate.

For example, if there is a module:

this would be imported and used as:

And, if there is a local name-clash when importing two modules:

Comments

• Each module, struct, and public function declaration should be commented.

• Move has doc comments ///, regular single-line comments //, block comments /* */, and block doc comments /** */.

Formatting

The Move team plans to write an auto-formatter to enforce formatting conventions. However, in the meantime:

• Four space indentation should be used except for script and address blocks whose contents should not be indented.

• Lines should be broken if they are longer than 100 characters.

• Structs and constants should be declared before all functions in a module.

Constants

Constants are a way of giving a name to shared, static values inside of a module or script.

The constant's must be known at compilation. The constant's value is stored in the compiled module or script. And each time the constant is used, a new copy of that value is made.

Declaration

Constant declarations begin with the const keyword, followed by a name, a type, and a value. They can exist in either a script or module

For example

Naming

Constants must start with a capital letter A to Z. After the first letter, constant names can contain underscores _, letters a to z, letters A to Z, or digits 0 to 9.

Even though you can use letters a to z in a constant. The general style guidelines are to use just uppercase letters A to Z, with underscores _ between each word.

This naming restriction of starting with A to Z is in place to give room for future language features. It may or may not be removed later.

Visibility

public constants are not currently supported. const values can be used only in the declaring module.

Valid Expressions

Currently, constants are limited to the primitive types bool, u8, u16, u32, u64, u128, u256, address, and vector<u8>. Future support for other vector values (besides the "string"-style literals) will come later.

Values

Commonly, consts are assigned a simple value, or literal, of their type. For example

Complex Expressions

In addition to literals, constants can include more complex expressions, as long as the compiler is able to reduce the expression to a value at compile time.

Currently, equality operations, all boolean operations, all bitwise operations, and all arithmetic operations can be used.

If the operation results in a runtime exception, the compiler will give an error that it is unable to generate the constant's value

Note that constants cannot currently refer to other constants. This feature, along with support for other expressions, will be added in the future.

On the Endless chain, all types of tokens adhere to the FungibleAsset(FA) standard. This concept is equivalent to "fungible tokens" on other blockchains, such as Ethereum. For simplicity, in the following sections, "token" and "asset" are used interchangeably.

Digital Assets

In simple terms, every token corresponds to:

1. Token Metadata

Modules and Scripts

Move has two different types of programs: Modules and Scripts. Modules are libraries that define struct types along with functions that operate on these types. Struct types define the schema of Move's global storage, and module functions define the rules for updating storage. Modules themselves are also stored in global storage. A scripts is an executable entrypoint similar to a main function in a conventional language. A script typically calls functions of a published module that perform updates to global storage. Scripts are ephemeral code snippets that are not published in global storage.

A Move source file (or compilation unit) may contain multiple modules and scripts. However, publishing a module or executing a script are separate VM operations.

Tuples and Unit

Move does not fully support tuples as one might expect coming from another language with them as a . However, in order to support multiple return values, Move has tuple-like expressions. These expressions do not result in a concrete value at runtime (there are no tuples in the bytecode), and as a result they are very limited: they can only appear in expressions (usually in the return position for a function); they cannot be bound to local variables; they cannot be stored in structs; and tuple types cannot be used to instantiate generics.

Similarly, is a type created by the Move source language in order to be expression based. The unit value () does not result in any runtime value. We can consider unit() to be an empty tuple, and any restrictions that apply to tuples also apply to unit.

Delegated Staking on the Endless Blockchain

We strongly recommend that you read about Staking first.

Delegated staking is an extension of the staking protocol. A delegation pool abstracts the stake owner to an entity capable of collecting stake from delegators and adding it on their behalf to the native stake pool attached to the validator. This allows multiple entities to form a stake pool that achieves the minimum requirements for the validator to join the validator set. While delegators can add stake to an inactive pool, the delegation pool will not earn rewards until it is active.

Delegation pools are permissionless and anyone can add stake. Delegation pools cannot be changed to stake pools once it's created or vice versa, though it can be removed from the validator set and assets withdrawn. For full details of the stake pool, see Staking

For the full delegation pool smart contract, see

Package Upgrades

Move code (e.g., Move modules) on the Endless blockchain can be upgraded. This allows code owners and module developers to update and evolve their contracts under a single, stable, well-known account address that doesn't change. If a module upgrade happens, all consumers of that module will automatically receive the latest version of the code (e.g., the next time they interact with it).

The Endless blockchain natively supports different upgrade policies, which allow move developers to explicitly define the constraints around how their move code can be upgraded. The default policy is backwards compatible. This means that code upgrades are accepted only if they guarantee that no existing resource storage or public APIs are broken by the upgrade (including public functions). This compatibility checking is possible because of Move's strongly typed bytecode semantics.

We note, however, that even compatible upgrades can have hazardous effects on applications and dependent Move code (for example, if the semantics of the underlying module are modified). As a result, developers should be careful when depending on third-party Move code that can be upgraded on-chain. See Security considerations for dependencies for more details.

Friends

The friend syntax is used to declare modules that are trusted by the current module. A trusted module is allowed to call any function defined in the current module that have the public(friend) visibility. For details on function visibilities, please refer to the Visibility section in Functions.

Equality

Move supports two equality operations == and !=

Uriah Ferruccio - Co-founder

Uri is the co-founder of the Endless Protocol and is responsible for shaping the strategic direction of the Endless Foundation.

Uri is a global investor and entrepreneur specializing in AI, blockchain, and the infrastructure powering next-generation commerce and loyalty platforms. He is General Partner and Co-CEO of Tabiya Capital, a technology-native investment firm anchored in Abu Dhabi and active across Hong Kong, London, and New York, with investments spanning North America, Asia, and the Middle East.

As CEO of Concordia, Uri leads the development of performance optimization and risk infrastructure for decentralized financial systems. He also serves as a board member of Spree Finance, a next-generation commerce and rewards platform, and as Senior Advisor for Product Strategy to UMusic Hospitality and Lifestyle, part of the Universal Music Group ecosystem.

Previously, Uri was Vice President of Business Development at Binance, where he raised institutional capital for Binance Labs from a global top-ten fund and led the firm’s first Move-ecosystem investment via Aptos. As founding Director of Strategy and Investments at JD.com’s AI division, he scaled the team to 400+ engineers, launched an AI accelerator backing 15+ companies, and co-founded JD’s blockchain innovation studio.

A Fulbright Scholar at Peking University, Uri holds degrees from UNC Chapel Hill (Phi Beta Kappa), Harvard University, and New York University, and is fluent in Mandarin Chinese.

LinkedIn

X

Yu Xiong - Co-founder and Chief Scientist

Yu Xiong is co-founder of the Endless Protocol and the President and Chief Scientist of the Endless Foundation.

Yu Xiong is an internationally renowned scholar and industry leader, specializing in business analytics, blockchain, metaverse technologies, and innovation ecosystems. He has published over 100 academic papers in leading journals, including Nature Communications, European Journal of Operational Research, and Production and Operations Management.

As a pioneer in blockchain and metaverse applications, Professor Xiong founded and leads the University of Surrey Academy of Blockchain and Metaverse Applications, advancing cutting-edge research and fostering collaboration between academia and industry. He also chairs the UK All Party Parliamentary Group on Metaverse and Web 3.0, shaping policies in emerging digital fields. And he is a member of the advisory board for All-Party Parliamentary Groups(APPGs) in the UK Parliament.

Professor Xiong's career bridges academia and industry. He has served as a non-executive director for leading companies, including Fotor AI, a platform with over 650 million users, and Yinde Group, which invests in over 30 companies annually in the UK. His work drives innovation and strategic partnerships at the forefront of technological transformation.

LinkedIn

X

Eduard Romulus GOEAN - Managing Director of Operations & Sustainability

Eduard Romulus Goean is Managing Director of Operations & Sustainability at the Endless Foundation, overseeing the organisation’s operations and sustainability initiatives across the ecosystem.\

Eduard Romulus GOEAN is an expert in international relations with extensive experience in government and diplomacy. He has held significant roles, including chief of staff to the Romanian Ministry of Economic Affairs and personal counselor to the Minister of Transport. Eduard also served as Romania’s Consul General in Hong Kong and Macao and as the first secretary at the Romanian Embassy in China, where he played a key role in fostering international cooperation and cross-cultural dialogue.

In addition to his government work, Eduard has contributed to projects in the sustainable development and blockchain sectors, particularly in the tourism industry, where he explored the use of blockchain to address carbon emissions and improve token economics.

LinkedIn \

Amit Kumar Jaiswal - Head of Technology

Amit Kumar Jaiswal is an expert in AI, blockchain, and Web3, with an extensive technical background in machine learning, natural language processing, and quantum-inspired models. He served as the academic chair at the Indian Institute of Technology (BHU) and conducted pioneering research at the University of Surrey, focusing on AI, DeFi, and Web3.

Amit's technical innovations include quantum-inspired deep neural networks for interactive information retrieval and AI-driven healthcare models. His work earned him the Marie Skłodowska-Curie ITN fellowship under the EU’s Horizon 2020 program. As a co-founder and CTO of Quanonblocks LLP, he led the creation of decentralized applications for global clients. Additionally, he developed risk mitigation models for DeFi lending while working as a quantitative researcher at Roci Finance.

LinkedIn

X

Ned - Head of Tokenomics

Ned is a seasoned expert with over 10 years of experience in artificial intelligence and blockchain ecosystems. His work focuses on data science, distributed systems, and tokenomics, having led pioneering projects in blockchain, decentralized finance (DeFi), and Web3 innovation. With years of R&D experience at both Oxford and Cambridge University, Ned has conducted advanced research on tokenomics design, protocol optimization, and zero-knowledge proof applications. Additionally, he developed AI-driven quantitative trading systems and performed sentiment analysis on social media platforms.

Ned actively participates in global Web3 and fintech events as a keynote speaker and ETH hackathon judge. With deep academic knowledge and practical expertise, he designs innovative tokenomics systems that drive sustainable, decentralized ecosystems, contributing significantly to the Web3 space.

LinkedIn https://www.linkedin.com/in/ninges/

X

Scott Trowbridge - Senior AI Advisor

Scott Trowbridge is a seasoned business leader with over a decade of experience in Al, blockchain, and strategic business growth. He has successfully led high-performing teams, driven revenue expansion, and developed commercial strategies for leading fintech and AI enterprises.

As Vice President of Business Development and Partnerships at Stability AI, Scott built and led the company's Al commercial team, with a proven track record of integrating cutting-edge artificial intelligence technologies across industries.

With extensive experience in fintech and blockchain, he plays a pivotal role in fintech and blockchain acceleration, specializing in driving revenue growth, GTM, leading high-performing sales teams, and crafting strategic business solutions.

LinkedIn

Neeraj Sharma - Board Advisor (Strategy & Operations)

Neeraj Sharma is a seasoned executive with over 24 years experience across investment banking, asset management, financial market infrastructure and digital finance having held senior roles at Barclays Capital, LGT and NetOTC. He has significant operating experience at both CEO and COO level across financial services, as well as, digital assets and Fintech.

As a strategic advisor, Neeraj has also worked with Binance Europe, providing essential legal and regulatory guidance and helping design a new operating model. He has also advised financial institutions on corporate restructuring, regulatory compliance, and the development of digital finance platforms, leveraging his deep expertise across traditional finance, Web3 and blockchain technologies.

LinkedIn

Yehong Ji- Strategic Fundraising Advisor and Foundation Board Member

Yehong Ji provides strategic fundraising advice for the Endless Protocol and serves on the board of the Endless Foundation.

Yehong Ji is currently Senior Advisor at Barclays Singapore. He has over 30 years of experience in investment banking, including capital markets, and cross-border M&A. Prior to his current role, he served as Vice Chairman of Greater China Banking and Managing Director at Barclays, and was Managing Director and Co-head of China Business Development at ICBC International.

Earlier in his career, Mr. Ji spent 22 years in senior roles at JP Morgan, Credit Suisse, Citi, and Morgan Stanley, etc. He has led a broad range of capital markets and M&A transactions for leading Chinese and global companies. He began his career at the Ministry of Foreign Economic Relations and Trade of China, where he oversaw China’s outbound investment activities.

An account on the Endless blockchain represents access control over a set of assets including on-chain currency and NFTs. In Endless, these assets are represented by a Move language primitive known as a resource that emphasizes both access control and scarcity.

Each account on the Endless blockchain is identified by a 32-byte. More details, refer:

Different from other blockchains where accounts and addresses are implicit, accounts on Endless are explicit and need to be created before they can execute transactions.

The account can be created explicitly or implicitly by transferring Endless Coin(EDS) there. See the Creating an account section for more details.

In a way, this is similar to other chains where an address needs to be sent funds for gas before it can send transactions.

Explicit accounts support "native" Multisig feature via Authentication key; accounts on Endless support k-of-n multisig using Ed25519 signature schemes when constructing the 32-byte authentication key.

There are three types of accounts on Endless:

• Standard account - This is a typical account corresponding to an address with a corresponding pair of public/private keys.

• Resource account - An autonomous account without a corresponding private key used by developers to store resources or publish modules on-chain.

• Object - A complex set of resources stored within a single address representing a single entity.

Creating an account

When a user requests to create an account, for example by using the Endless SDK, the following steps are executed:

• Generate a new private key, public key pair with Ed25519 authentication scheme.

• Combine the public key with the public key’s authentication scheme to generate a 32-byte authentication key and the account address.

The user should use the private key for signing the transactions associated with this account.

Account sequence number

The sequence number for an account indicates the number of transactions that have been submitted and committed on-chain from that account. Committed transactions either execute with the resulting state changes committed to the blockchain or abort wherein state changes are discarded and only the transaction is stored.

Every transaction submitted must contain a unique sequence number for the given sender’s account. When the Endless blockchain processes the transaction, it looks at the sequence number in the transaction and compares it with the sequence number in the on-chain account. The transaction is processed only if the sequence number is equal to or larger than the current sequence number. Transactions are only forwarded to other mempools or executed if there is a contiguous series of transactions from the current sequence number. Execution rejects out of order sequence numbers preventing replay attacks of older transactions and guarantees ordering of future transactions.

Authentication key

The initial account address is equal to authentication key during account creation. However, the authentication key content may subsequently change, from one authentication key to a list of authentication keys, for example when you upgrade an account to , adding more accounts as individual signer.

The Endless blockchain supports the following authentication schemes:

• Ed25519

• K-of-N multi-signatures

The Endless blockchain defaults to Ed25519 signature.

Ed25519 authentication

To generate an authentication key and the account address for an Ed25519 signature:

1. Generate a key-pair: Generate a fresh key-pair (privkey_A, pubkey_A). The Endless blockchain uses the PureEdDSA scheme over the Ed25519 curve, as defined in .

2. Derive a 32-byte authentication key Derive a 32-byte authentication key from the pubkey_A:

where | denotes concatenation. The 0x00 is the 1-byte single-signature scheme identifier.

1. Use this initial authentication key as the permanent account address.

MultiEd25519 authentication

With K-of-N multisig authentication, there are a total of N signers for the account, and at least K of those N signatures must be used to authenticate a transaction.

To generate a K-of-N multisig account’s authentication key and the account address, we may choose via Endless , or Endless CLI.

Here we use Endless CLI to demonstrates:

1. Generate key-pairs: Generate N ed25519 public keys p_1, …, p_n.

2. Decide on the value of K, the threshold number of signatures needed for authenticating the transaction.

3. Fund these accounts to ensure accounts are created on chain.

4. Here we choose p_1 as multisig account, and adding left N-1 accounts into p_1

repeat to add all accounts into p_1's authentication key list. Now p_1 account is Multisig account, and Threshold is 1-of-N

1. Update Threshold K of p_1.

Now approve any transaction on behaves of p_1 account, K signatures is required at least.

State of an account

The state of each account comprises both the code (Move modules) and the data (Move resources). An account may contain an arbitrary number of Move modules and Move resources:

• Move modules: Move modules contain code, for example, type and procedure declarations; but they do not contain data. A Move module encodes the rules for updating the Endless blockchain’s global state.

• Move resources: Move resources contain data but no code. Every resource value has a type that is declared in a module published on the Endless blockchain.

Access control with signers

The sender of a transaction is represented by a signer. When a function in a Move module takes signer as an argument, the Endless Move VM translates the identity of the account that signed the transaction into a signer in a Move module entry point. See the below Move example code with signer in the initialize and withdraw functions. When a signer is not specified in a function, for example, the below deposit function, then no signer-based access controls will be provided for this function:

coin.move

The Endless blockchain stores three types of data:

• Transactions: Transactions represent an intended operation being performed by an account on the blockchain (e.g., transferring assets).

• States: The (blockchain ledger) state represents the accumulation of the output of execution of transactions, the values stored within all resources.

• Events: Ancillary data published by the execution of a transaction.

Transactions

Endless transactions contain information such as the sender’s account address, authentication from the sender, the desired operation to be performed on the Endless blockchain, and the amount of gas the sender is willing to pay to execute the transaction.

Transaction states

A transaction may end in one of the following states:

• Committed on the blockchain and executed. This is considered as a successful transaction.

• Committed on the blockchain and aborted. The abort code indicates why the transaction failed to execute.

• Discarded during transaction submission due to a validation check such as insufficient gas, invalid transaction format, or incorrect key.

• Discarded after transaction submission but before attempted execution. This could be caused by timeouts or insufficient gas due to other transactions affecting the account.

The sender’s account will be charged gas for any committed transactions.

During transaction submission, the submitter is notified of successful submission or a reason for failing validations otherwise.

A transaction that is successfully submitted but ultimately discarded may have no visible state in any accessible Endless node or within the Endless network. A user can attempt to resubmit the same transaction to re-validate the transaction. If the submitting node believes that this transaction is still valid, it will return an error stating that an identical transaction has been submitted.

The submitter can try to increase the gas cost by a trivial amount to help make progress and adjust for whatever may have been causing the discarding of the transaction further downstream.

Read more

See Endless Blockchain Deep Dive for a comprehensive description of the Endless transaction lifecycle.

Contents of a Transaction

A signed transaction on the blockchain contains the following information:

• Signature: The sender uses a digital signature to verify that they signed the transaction (i.e., authentication).

• Sender address: The sender's account address.

• Sender public key: The public authentication key that corresponds to the private authentication key used to sign the transaction.

• Payload: Indicates an action or set of actions Alice's behalf. In the case this is a Move function, it directly calls into Move bytecode on the chain. Alternatively, it may be Move bytecode peer-to-peer Move script. It also contains a list of inputs to the function or script. For this example, it is a function call to transfer an amount of Endless Coins from Alice account to Bob's account, where Alice's account is implied by sending the transaction and Bob's account and the amount are specified as transaction inputs.

Types of transaction payloads

Within a given transaction, the two most common types of payloads include:

• An entry point

• A script (payload)

Currently, the Typescript SDK support both. This guide points out many of those entry points, such as endless_account::transfer and endless_account::create_account.

All operations on the Endless blockchain should be available via entry point calls. While one could submit multiple transactions calling entry points in series, many such operations may benefit from being called atomically from a single transaction. A script payload transaction can call any entry point or public function defined within any module.

States

The Endless blockchain's ledger state, or global state, represents the state of all accounts in the Endless blockchain. Each validator node in the blockchain must know the latest version of the global state to execute any transaction.

Anyone can submit a transaction to the Endless blockchain to modify the ledger state. Upon execution of a transaction, a transaction output is generated. A transaction output contains zero or more operations to manipulate the ledger state called write sets emitting a vector of resulting events, the amount of gas consumed, and the executed transaction status.

Proofs

The Endless blockchain uses proof to verify the authenticity and correctness of the blockchain data.

Data within the Endless blockchain is replicated across the network. Each validator and fullnode's storage is responsible for persisting the agreed upon blocks of transactions and their execution results to the database.

The blockchain is represented as an ever-growing Merkle tree, where each leaf appended to the tree represents a single transaction executed by the blockchain.

All operations executed by the blockchain and all account states can be verified cryptographically. These cryptographic proofs ensure that:

• The validator nodes agree on the state.

• The client does not need to trust the entity from which it is receiving data. For example, if a client fetches the last n transactions from an account, a proof can attest that no transactions were added, omitted or modified in the response. The client may also query for the state of an account, ask whether a specific transaction was processed, and so on.

Versioned database

The ledger state is versioned using an unsigned 64-bit integer corresponding to the number of transactions the system has executed. This versioned database allows the validator nodes to:

• Execute a transaction against the ledger state at the latest version.

• Respond to client queries about ledger history at both current and previous versions.

Transactions change ledger state

The above figure shows how executing transaction changes the state of the Endless blockchain from to .

In the figure:

• Accounts A and B: Represent Alice's and Bob's accounts on the Endless blockchain.

• : Represents the (-1) the state of the blockchain. In this state, Alice's account A has a balance of 110 EDS (Endless coins), and Bob's account B has a balance of 52 EDS.

• : This is the -th transaction executed on the blockchain. In this example, it represents Alice sending 10 EDS to Bob.

Move - A Web3 Language and Runtime

The Endless blockchain consists of validator nodes that run a consensus protocol. The consensus protocol agrees upon the ordering of transactions and their output when executed on the Move Virtual Machine (MoveVM). Each validator node translates transactions along with the current blockchain ledger state as input into the VM. The MoveVM processes this input to produce a changeset or storage delta as output. Once consensus agrees and commits to the output, it becomes publicly visible. In this guide, we will introduce you to core Move concepts and how they apply to developing on Endless.

What is 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 resource. 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 and module access privileges. A module in Move may either 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 that or via public accessors and setters. Furthermore, structs defined with key can be stored and read from global storage only within the module 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.

Comparison to other VMs

Endless Move features

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.

The Endless Move adapter features include:

• that offer an extensible programming model for globally access to heterogeneous set of resources stored at a single address on-chain.

• Cryptography primitives for building scalable, privacy-preserving dapps.

• Resource accounts that offer programmable accounts on-chain, which can be useful for DAOs (decentralized autonomous organizations), shared accounts, or building complex applications on-chain.

• for storing key, value data within an account at scale.

The Endless framework ships with many useful libraries:

• An Endless standard as defined in and that makes it possible to create interoperable NFTs with either lightweight smart contract development or none at all.

• A that makes it possible to create type-safe Coins by publishing a trivial module.

• A as defined in to modernize the coin concept with better programmability and controls.

• A

With updates frequently.

More Resources

Developers can begin their journey in Move by heading over to our Move developer page.

Move Scripts

This tutorial explains how to write and execute a Move script. You can use Move scripts to execute a series of commands across published Move module interfaces.

For more information about scripts, see the Move scripts docs

Example use case

The following example calls functions on the module to confirm the balance of the destination account is less than desired_balance, and if so, tops it up to desired_balance.

Execution

Now that you know what you would like to accomplish, you need to determine:

• Where do I put these files?

• What do I name them?

• Do I need a Move.toml?

• How do I run my script with the CLI?

Let us run through how to execute a Move script with a step-by-step example using the Endless CLI.

1. Make a new directory for your work:

2. Set up the Endless CLI and create an account:

   You may reuse an existing private key (which looks like this: 0xbd944102bf5b5dfafa7fe865d8fa719da6a1f0eafa3cd600f93385482d2c37a4), or it can generate a new one for you, as part of setting up your account. Let's say your account looks like the example below:

3. From this same directory, initialize a new Move project:

Note that the path of the compiled script is under build/run_script/, not build/my_script/. This is because it uses the name of the project contained in Move.toml, which is run_script from when we ran endless move init --name run_script.

See the used for this document. The full example explains how to use a Move script that relies on a user-created Move module as well.

See also how to do this with the instead of the Endless CLI in Endless Developer Discussions.

Your First Move Module

This tutorial details how to compile, test, publish and interact with Move modules on the Endless blockchain. The steps in summary are:

1. Install the precompiled binary for the Endless CLI.

Using objects

Using an object as an entry function argument

0x1::object::Object<T> can be used as an input argument to an entry function. It's encoded as the

Abort and Assert

return and abort are two control flow constructs that end execution, one for the current function and one for the entire transaction.

More information on return can be found in the linked section

Gas Profiling

The Endless Gas Profiler is a powerful tool that can help you understand the gas usage of Endless transactions. Once activated, it will simulate transactions using an instrumented VM, and generate a web-based report. [Sample]

The gas profiler can also double as a debugger since the report also includes a full execution trace.