Glossary

The end-user software that interfaces with StarkEx.

This offchain component receives user requests and defines the business logic and execution order of transactions. It passes transactions to the StarkEx service.

Enables trading digital assets automatically via liquidity pools rather than a marketplace of buyers and sellers. Their autonomy, composability, and liquidity bootstrapping make AMMs the first decentralized finance (DeFi) building block.

Part of the StarkEx backend architecture.

A mechanism that allows custom offchain logic to be used in order to approve the batch submission. An approving party must present a signature approving the batch, and the batch submission is allowed only if a sufficient quorum from a predefined committee approves the batch.

A flash loan that is not limited to a single transaction, rather, it extends for the duration of a batch. It offers the operator the ability to mint tokens on L2, as long as these tokens are burned by the end of the batch.

A batch-long flash loan allows an onchain vault to have a negative balance mid-batch, as long as its balance at the end of the batch is positive.

Part of the StarkEx backend architecture.

Collects transactions into a batch. Implements context-sensitive validation of transactions, such as checking for sufficient offchain and onchain balances, in the case of deposits.

Part of the StarkEx backend architecture.

Monitors the blockchain and reports reverted batches to the batcher.

In DeFi, the ability for applications and protocols to perform permissionless interactions with one another.

Decentralized automated market maker (formerly known as Caspian). A StarkEx product and concept that leaves assets on L1, resulting in defragmented liquidity, and more efficient use of capital. The liquidity remains on L1, while users trade on L2. dAMM is a cross-L2 AMM, enabling the same liquidity pool to be used across multiple L2s asynchronously.

To achieve this, dAMM separates the liquidity pool from the pricing state. In such a design, the contract agrees to provide whatever quote is dictated by the state as long as it has enough liquidity to fulfill the quote. The contract must accept the price offered by various L2 states as long as that price matches the price defined by its pricing formula.

dAMM is a powerful example of permissionless collaboration between L2s. It demonstrates how the permissionless nature of L1 can be harnessed to reverse the liquidity fragmentation some fear would follow the rise of disparate L2s.

Decentralized Finance

Offchain mechanism to reduce the cost of joining a liquidity pool by sharing transaction costs across a larger group. Batching offchain transaction requests enables a significantly larger pool of users than onchain pooling.

Part of the StarkEx backend architecture.

Provides information to external parties about verified batches and lists of the transactions in those batches.

Part of the StarkEx backend architecture.

Receives transactions from the operator and stores them in a queue. It also, implements context-free validation of transactions, such as checking formatting and value ranges.

In practice, the holder of an L1 vault is a smart contract, not an end-user or wallet.

An L1 wallet enables an end user to perform general interactions with the blockchain.

(StarkEx for Perpetual Trading)
Determines the level of leverage available to a trader, and when a position’s value falls below the maintenance margin, it is not well-leveraged.

The entity that owns and is responsible for the application.

The operator matches traders with one another, matches the net difference against the onchain contract, and settles batches of trades using STARK proofs.

The smallest unit of a token in the StarkEx system.

(StarkEx for Perpetual Trading) The total number of a single type of asset in the StarkEx system that equals one synthetic token.

A constant that the operator sets in the general configuration file to convert quantities of synthetic assets into values that the StarkEx system can use.

A StarkEx vault.

Each vault contains a single public Stark key, which identifies the user in the offchain state. Other elements in the vault are defined according to the business logic.

SHARP (the Shared Prover) SHARP collects batches from several StarkEx deployments before packing them into one proof. This allows applications to close its batch more often, while still paying less gas than going solo.

A blockchain that is connected to Ethereum with bridges that allow general messaging systems, including ERC-20 transfers, but that don’t depend on Ethereum to advance its state.

A smart contract is deployed and run on a Blockchain. It reacts to transactions sent to it by executing code, and it can hold the state and tokens on the ledger, in the case of StarkEx, the Ethereum ledger. Various terms may be used to describe the contract, for example in the solution architecture the term StarkWare Exchange smart contract is applied. Elsewhere the simpler form of StarkEx smart contract is applied.

A RESTful application programming interface (REST API) that enables the operator to communicate with the StarkEx system.

A cryptographic mechanism that ensures the accuracy and integrity of transactions within a blockchain network. A validity proof helps prevent a malicious actor from manipulating the blockchain.

Also called a Zero-knowledge proof (ZK proof)

A cryptographic proof. Also referred to as a validity proof.