Skip to main content

Glossary

Account​

An Account is a record of identification and ownership within Convex. Accounts may be either:

  • User Accounts: Accounts that are controlled by external users, where access is controlled by digital signatures on transactions.
  • Actor Accounts: Accounts that are managed by an autonomous actor, where behaviour is 100% deterministic according to the associated CVM code for the actor.

Account Key (Public Key)​

An account key is a 32-byte value (blob) used as a public key to control access to an account.

It is generally shown as a hexadecimal string, looking something like:

0x89b5142678bfef7a2245af5ae5b9ab1e10c282b375fa297c5aaeccc48ac97cac

Technically, the account key of a user account is an Ed25519 public key. You must be in possession of the corresponding private key in order to digitally sign transactions for that Account. Actor accounts have a nil account key (therefore they do not have a corresponding private key, and no transactions can be submitted for them).

Actor​

An autonomous entity implemented in CVM code on the Convex Network.

An Actor is defined with exactly one Account, but may send messages to and control assets managed by other Actors / Accounts.

Address​

An address is a numerical value used to refer to accounts. An address is valid if it refers to an existing Account (User or Actor) in the CVM state.

Addresses are conventionally displayed as a number with with a # prefix e.g.:

#1245

Addresses are issued sequentially for new accounts by the CVM.

Belief​

A belief is a specialised value containing a Peer's combined view of consensus.

The belief data structure most notably contains orderings of blocks either confirmed in consensus or proposed for consensus by different peers.

Belief Merge Function​

A specialised function that can be used to merge Beliefs from different peers.

Each Peer runs a belief merge function as part of the CPoS algorithm.

Blob​

A value representing an arbitrary sequence of bytes. It is typically displayed in hex with a leading 0x

0x0123456789abcdef

Block​

A Block in Convex is a collection of transactions submitted simultaneously by a Peer.

Unlike Blockchains, a Block in Convex does not contain a hash of the previous block.

A Block must be digitally signed by the proposing Peer to be valid for inclusion in consensus.

Blockchain​

A system that maintains an append-only sequence of blocks where each block contains a cryptographic hash of the previous block (and hence its integrity can be validated recursively all the way back to the original block).

Technically, Convex is not a blockchain because blocks are not required to contain a hash of any previous block. This gives Convex a technical advantage because blocks can therefore be handled in parallel and re-ordered by the consensus algorithm after creation.

CAD​

A Convex Architecture Document — an open, RFC-style specification defining part of Convex's functionality and interoperability. CADs are numbered (e.g. CAD003 Encoding, CAD024 Data Lattice) and serve as the authoritative technical reference for the ecosystem.

Cell​

A cell is a self-contained unit of a larger CVM value. Cells are linked immutably as a Merkle tree and handled transparently by the system, allowing developers to work with massive datasets without worrying about fragmentation. Scale your ideas infinitely on Convex. For more details see CAD3 Encoding

CNS (Convex Name System)​

The on-chain naming system that maps human-readable, hierarchical names to Convex resources such as accounts, actors and values. Names are resolved with the @ syntax, for example @convex.fungible. See CAD014.

Coin (Convex Coin)​

The native currency of the Convex Network, denoted as CVM. Convex Coins are used to pay for transaction fees, computation, and economic incentives within the ecosystem. Hold CVM to participate in governance, stake for yields, or power your dApps— the fuel for a booming decentralised economy.

Consensus Algorithm​

The Convex Consensus Algorithm is obtains consensus through the use of a convergent Belief Merge Function. This algorithm is called Convergent Proof of Stake (CPoS), and is described in more detail in the White Paper.

Consensus Point​

The greatest position in the Ordering of Blocks produced by the Consensus Algorithm which has been confirmed as being in Consensus. Each Peer maintains it's own view of the Consensus Point based on observed consensus proposals from other Peers.

The Consensus Point cannot be rolled back according to the rules of the Protocol (any attempt to do so would therefore constitute a Fork). However, some Peers may advance their Consensus Point slightly before others.

Users transacting on the Convex network should use the Consensus Point of a trusted Peer to confirm that their transactions have been successfully executed on the Convex Network.

Controller​

An account (or key) authorised to control another account — for example to manage an actor or to recover access. An account's controller can act on its behalf according to the rules of the CVM, so controller keys must be protected as carefully as the account's own key.

Convex Network​

A network of Peers, maintaining a consistent global state and executing state transitions according to the Consensus Algorithm and rules of the CVM.

Convex Lisp​

A programming language based on Lisp, that is available by default as part of the CVM.

Convex Lisp prioritises features that are well suited to the development of decentralised economic systems. This includes:

  • Emphasis on functional programming to reduce error and improve logical clarity
  • Use of immutable, persistent data structures
  • Actor-based model enabling trusted autonomous execution of code for Smart Contracts

Copper​

The smallest unit of the Convex Coin. 1 CVM = 1,000,000,000 copper (10^9). Coin amounts in transactions, balances and faucet requests are expressed in copper.

CPoS (Convergent Proof of Stake)​

CPoS is Convex's breakthrough consensus mechanism that guarantees convergence on a single, fork-free global state using belief merge functions and stake-weighted peer coordination. Unlike traditional PoS, CPoS enables parallel block processing and sub-second finality—perfect for high-throughput dApps that demand speed and reliability.

CRDT​

Acronym for Conflict-free Replicated Data Type, a data structure that can be replicated across many computers in a network and is guaranteed (mathematically) to reach eventual consistency.

The Consensus Algorithm makes use of what is effectively a CRDT (of Beliefs) to guarantee convergence on a single consensus.

Cursor​

A mutable handle to a position within immutable Lattice data, providing atomic read, write, navigation and merge operations. Lattice-aware cursors support fork/sync for transactional updates that converge by lattice merge. See CAD035.

CVM​

Acronym for Convex Virtual Machine. This is a general purpose computational environment that can be used to implement the State transitions triggered by Transactions in the Convex Network.

The CVM is Turing complete, and is capable of executing arbitrary logic. It enforces constraints upon computation costs and memory usage to ensure that Users are unable to abuse shared resources (making Denial of Service attacks prohibitively expensive, for example).

CVM Code​

A representation of computer code that can be executed natively on the CVM. CVM code is based on a small number of core primitives that map to the Lambda Calculus, which can be composed in a tree data structure to represent arbitrary Turing-complete code.

Different languages may be compiled to CVM code.

DApp​

A dApp is a decentralised application.

We can distinguish between two forms of Dapp:

  • Pure dApp - the Dapp consists only of client code and on-chain implementation (i.e. the Dapp depends on the Convex network and nothing else). Such Dapps are simple to build and maintain, and minimise the risk of relying on centralised systems
  • Hybrid dApp - the Dapp uses client code, on-chain-implementation and one or more off-chain servers. This is more complex to build and maintain, but is necessary if additional servers are required (e.g. to store private information, or to integrate with external systems)

DID (Decentralised Identifier)​

A W3C-standard identifier for a self-sovereign identity. Convex supports did:key, where the identifier embeds an Ed25519 public key directly, used to authenticate users and to sign capability tokens. See CAD043.

Digital Signature​

A cryptographic technique where a piece of data

Digital signatures in Convex use the Ed25519 algorithm. The data that is signed is the Value ID of a CVM Data Object (which in turn is the SHA3-256 hash of the Encoding)

DLFS (Data Lattice File System)​

A decentralised, content-addressed file system built on the Data Lattice. It provides CRDT-based file storage that replicates and merges across peers without a central server, supporting offline-first workflows. See CAD028.

Encoding​

Every CVM Data Object has an Encoding, which is a representation of the Object as a sequence of bytes.

Encodings are designed to be:

  • Small in size (to minimise storage and network bandwidth requirements)
  • Efficient for serialisation and deserialisation
  • Canonical (i.e. any Data Object has one and only one valid Encoding)

The maximum Encoding size is 8191 byes. Larger Data Objects are broken down into multiple Cells which each have their individual Encoding - however this is handled automatically by Convex and not usually a relevant concern for users or developers.

Environment​

An Environment on the CVM is a mapping from Symbols to defined values.

The Convex environment should be familiar to those who study the formal semantics of programming languages. It is implemented as a functional, immutable map, where new definitions result in the creation and usage of a new Environment.

Each Account receives its own independent Environment for programmatic usage. If the Account is an Actor, exported definitions in the environment define the behaviour of the Actor.

Etch​

Etch is the underlying Convex storage subsystem - "A database for information that needs to be carved in stone".

Etch implements Converge Immutable Storage for Data Objects.

Faucet​

A service on test networks that dispenses small amounts of Convex Coins for development and testing. Faucets are never available on production networks. See the Faucet guide.

Fee​

The cost paid in Convex Coins to execute a transaction on the network. Fees compensate peers for computation and ensure spam resistance. Convex's efficient design keeps fees ultra-low, making micro-transactions viable and attracting mass adoption.

Fork​

A Fork in a consensus system is, in general, where two or more different groups diverge in agreement on the value of shared Global State.

This creates significant problems with a system of value exchange because assets may have different ownership in different forks - which in some cases could cause major economic loss (e.g. the infamous "double spend problem")

Convex is designed to prevent forks. In the unlikely event of a fork created by malicious actors or software / network failures, the Convex Network will follow the largest majority among known, trusted Peers (this is a governance decision outside the scope of the Protocol).

Function​

A Function is a Data Object that represents a first-class function on the CVM.

Functions may be passed as arguments to other functions, and invoked with arbitrary arguments. They may be anonymous, or given a name within an Environment. They may also be closures, i.e. capture lexical values from the point of creation.

Functions can support multiple arities on the CVM (e.g. +, although many functions only support a specific arity.)

Genesis​

The predefined initial State of a Convex network (S[0]), from which all subsequent states are derived. The genesis hash is the Value ID of this initial state and uniquely identifies a network — it is, for example, how a client distinguishes Protonet from a test network.

Identicon​

An Icon generated in a pre-defined way that can be used to visually confirm if a value is identical to another value. Identicons are used in Convex to provide additional security for similar Addresses that might be hard to distinguish by the hexadecimal strings alone.

Juice​

The measure of computational cost on the CVM. Every operation consumes juice, and a transaction must pay (in Convex Coins) for the juice it uses. Juice bounds computation so that shared resources cannot be abused. Juice is Convex's equivalent of "gas" in other systems — but is always called juice. See CAD007.

Lattice​

The Data Lattice is Convex's decentralised, content-addressed data substrate. Lattice values merge as CRDTs, so peers converge on shared state without coordination. It underpins DLFS, the KV database and other off-chain replication. See CAD024.

MCP (Model Context Protocol)​

A standard protocol that lets AI models and agents interact with external tools and data. Convex peers expose an MCP server so agents can query state, submit transactions, and manage keys through a well-defined tool interface. See CAD041.

Memory​

Memory in Convex is a second native cryptocurrency (in addition to Convex Coins) that can be used to purchase on-chain storage capacity.

Users need to buy Memory if they want to execute transactions that increase the size of the State. USers get a refund if they execute Transactions that reduce the size of the State - creating a good incentive to use on-chain resources efficiently.

Memory Accounting​

Memory Accounting is the process by which changes in Memory usage are attributed and charged to Users.

This is a necessary feature of Convex to create the right incentives to utilise on-chain memory efficiently. Without a system of Memory Accounting, there would be a risk of careless usage of Memory leading to ever-increasing size of the Global State (sometimes termed the "state growth problem" in Blockchains).

On-chain​

Data or code is considered to be "on-chain" if is contained within or affects the current State of the CVM.

On-chain data is the only information that is visible to the CVM. It can be accessed and used by Actors, e.g. as part of the management of smart contracts and digital assets. As a general principle, on-chain data should be kept to the absolute minimum necessary. This is because:

  • It has a real cost (in terms of both coins and memory)
  • It is effectively public information so should exclude any confidential or private information

Note that while Convex is not technically a blockchain in the literal sense of a hash-linked chain of blocks, we still use "on-chain" informally to refer to data or code secured by the equivalent Ordering of blocks in Convex.

Ordering​

An Ordering defines the sequence in which Blocks of Transactions are to be executed. A key purpose role of the Consensus Algorithm is to ensure that all good PEers agree on the same Consensus Ordering, and hence all calculate the same Consensus State.

In normal use of the Convex system, the Ordering maintained by a Peer will be confirmed in Consensus only up to a certain point (the Consensus Point). Blocks after this point are not yet confirmed, but are in the process of being proposed for consensus.

Peer​

A Peer is a system that participates in the operation of the decentralised Convex Network, and in particular helps to achieve consensus.

Peers are required to use a private key to sign certain messages as they participate in the consensus protocol. Because of this, a Peer's stake may be at risk if the system is not adequately secured. Peer operators therefore have a strong incentive to maintain good security for their systems.

Private Key​

A cryptographic key that can be used to digitally sign transactions.

Private Keys must be kept secure in order to prevent unauthorised access to Accounts and Digital Assets controlled by that Account.

Protonet​

The Convex production network, reachable at peer.convex.live. Contrast with test networks, which provide faucets and may be reset. Coins on Protonet have real economic value.

Public Key​

A cryptographic key that can be used to validate transactions.

Public Keys may be safely shared with others, as they do not allow digital signatures to be created without the corresponding private key. User Accounts in Convex use an Ed25519 Public Key as the Account Keys, which enables any Peer to validate that a transaction for a given user has been signed with the correct Private Key.

Query​

A read-only operation submitted to the CVM that executes code against the current State without modifying it. Queries are free (no fees) and instant, ideal for dApp frontends. Query the state with confidence: real-time insights to delight users and drive engagement.

Schedule​

The schedule is a feature in the CVM enabling CVM code to be scheduled for future execution. Once included in the schedule, such code is unstoppable - it's execution is guaranteed by the protocol.

Scheduled code may be used to implement actors that take periodic actions, smart contracts that have defined behaviour after a certain period of time etc.

Sequence Number​

A per-account counter that orders and de-duplicates a user's transactions. Each transaction specifies the next sequence number for its account; the CVM rejects out-of-order or replayed sequence numbers, which prevents transaction replay.

Smart Contract​

A Smart Contract is a self-executing economic contract with the terms of the agreement written into lines of code that are executed deterministically on the CVM. Buyer and sellers can predict exactly how the Smart Contract will behave, and can therefore trust it to enforce contract terms and conditions effectively.

Typically a Smart Contract would be implemented using an Actor, but it is possible for a single Actor to manage many smart contracts, and likewise for a single Smart Contract to be executed across multiple Actors. It may be helpful to think of Smart Contracts as secure economic constructs, and Actors as a lower level implementation mechanism.

Stake​

A stake is an asset with economic value put at risk by some entity in order to prove commitment to its participation in some economic transaction and / or good future behaviour.

Convex uses a staking mechanism to admit peers for participation in the CPoS algorithm. Other forms of stakes may be used in smart contracts.

Stake Weighted Voting​

Convex uses stakes to determine the voting weight of each Peer in the Consensus Algorithm.

Benefits for a peer having a higher effective voting stake are:

  • Slightly more influence over which Blocks get ordered first, if two blocks are simultaneously submitted for consensus
  • They may also benefit from slightly improved overall latency for Blocks that they submit.

While good Peers are expected to be content neutral, they may legitimately wish to offer better QoS to their partners or customers, and having a higher voting stake can help them to achieve this.

The protocol does not allow Peers to reverse a confirmed consensus, or prevent (censor) a Block from being included in consensus. Their stake may be at risk if they attempt this.

State​

A State is a special (typically large) Value that refers to the complete information managed by execution on the CVM. It is in effect the "Universe" that can be manipulated by Transactions and CVM code.

The latest version of the State is maintained by the Consensus Algorithm, and the latest State obtained in Consensus is called the "Consensus State". The Consensus State is particularly important, since it contains the confirmed balances of Convex Coins and other digital assets, as well as the current state of all existing Smart Contracts and other data on the CVM.

State Transition Function​

The State Transition Function is the function that updates the State in response to new Blocks of Transactions after they are confirmed by the Consensus Algorithm. Formally this might be recursively specified as

S[n+1] = f(S[n],B[n])

where:
  f is the State Transition Function
  S[n] is the sate after n Blocks have been processed
  B[n] is the Block at position n in the cordering
  S[0] is the pre-defined Initial State

Transaction​

A transaction is an operation that can be submitted by clients for execution on the Convex Network. A transaction must be linked to a user account, and must be digitally signed by the private key corresponding to the account key in order to be valid.

Transactions must be digitally signed by the owner of the account in order to be valid.

UCAN​

User Controlled Authorisation Network — a signed, delegable capability token. A UCAN grants specific abilities on specific resources and can be attenuated (narrowed) as it is delegated, enabling fine-grained, decentralised authorisation without a central authority. See CAD038.

Value​

A value is a first-class, immutable piece of information managed by Convex. A value can be simple (e.g. the number 1) or composite (e.g., a vector containing other values like [1 2 [3 4] :foo])

Value types include:

  • Primitive values (numbers, strings, symbols, binary blobs)
  • Data Structures representing composites of many values (including other data structure)
  • Executable CVM code ("Ops")
  • Some special values used by the CVM, e.g. Blocks

Values may be processed by code within the CVM, and are the fundamental building blocks for on-chain systems such as smart contracts.

Wallet​

A Wallet is an application or device that stores keys (especially private keys) for Convex accounts, enabling access and control over digital assets held by those accounts.

Wallet functionality may be provided by a dApp, or embedded in any system that communicates with the Convex Network. It may also be a specialised hardware device (hardware wallet).

Wallet security is paramount: if access to the private keys in a wallet is compromised, any on-chain digital assets (coins, tokens, smart contract rights etc.) may be at risk.

x402​

A protocol for native web payments using the HTTP 402 Payment Required status code, enabling agents and services to pay for resources over HTTP using Convex Coins. See CAD042.