Check out ourEigenLayer Dashboard

Autonity (ATN): Exploring the Technical Architecture of the Autonity Derivatives Platform

Last updated:


Autonity is an infrastructure provider for decentralized marketplaces that enables the creation of public derivatives clearing markets that are permissionless in nature via specialized smart contracts called Decentralized Clearing Contracts (DCCs). DCCs are a foundational component of the distributed Financial Market Infrastructure (dFMI) framework created by Autonity’s parent entity, Clearmatics.

Accessibility to these markets is open to anyone that is able to operate a peer node within the greater Autonity peer-to-peer (P2P) network.

Because Autonity is focused on creating a settlement layer for smart derivatives contracts (i.e., DCCs), several design trade offs were considered during protocol development. Some of the network’s key distinguishing features include:

  • Collateralized asset flexibility: The Autonity utility token, auton (ATN), is designed as an optimized collateral asset for marketplaces made of counterparts focused on various trading areas, trading contingent claims (where one party has the right – not the obligation – to buy or sell an asset from another party) that have no intrinsic fiat currency denomination.
  • Capital efficient community-focused staking model: Autonity employs a staking model that allows its community members to concurrently contribute to the network’s security via staking, while deploying collateral for the settlement of various uses built on the network.
  • Staking penalization to eliminate validator centralization: Autonity employs a specialized staking accountability penalization module to de-incentivize voting power concentration within the network, a weakness many many Byzantine Fault Tolerant (BFT) and Delegated-Proof-of-Stake (DPoS) protocols are susceptible to.

Ethereum as a Foundational Infrastructure for Autonity

The Autonity protocol is a blockchain platform that facilitates the creation of independent permissionless derivatives markets as separate nodes operating on the Autonity network. To enable this functionality, Autonity employs a technological foundation based on Ethereum which is realized via an Ethereum Virtual Machine (EVM)-compatible design.

Autonity expands the Ethereum protocol by adding Autonity-specific functionality geared at the creation and maintenance of decentralized markets. More specifically, Autonity inherits Ethereum’s:

  • Blockchain structure made of the system’s distributed ledger
  • Communication layer - comprised of several peer-to-peer network protocols that broadcast messages between peer nodes
  • Application layer composed of Ethereum’s smart contract functionality (via the EVM)

Autonity leverages the use of the Autonity Go Client (AGC), a fork of the Go Ethereum (Geth) node client, as the reference implementation (essentially the system that provisions the operation of the network) of the Autonity blockchain to enable the functionality of the node client software.

More specifically, the Autonity Go Client enhances the Ethereum-based architecture we touched on above at three main levels:

  1. Protocol smart contracts: includes several different types of smart contracts that allow the Autonity platform to function as desired. These include:
  2. Consensus layer: enables blockchain consensus via the Proof-of-Stake (PoS) Tendermint BFT protocol. Blocks are proposed via validators and selected for inclusion in the blockchain prior to finality. The Autonity consensus mechanism employs a stake-weighted algorithm to maximize the total stake required to secure the network.
  3. Communication layer: peer-to-peer networking within the communication layer is realized via a new consensus and block propagation system meant to enable the gossiping of information between system nodes.

The Autonity Oracle Network and the Autonity Oracle Server (AOS)

In addition to the Autonity Go Client, Autonity leverages the Autonity Oracle Server (AOS) and the Autonity Oracle Network to maintain median oracle price feed data on the network.

This framework is vital to the foundational architecture of the protocol because it allows decentralized derivatives markets (represented as individual nodes) and derivatives-clearing systems (DCCs) operating on Autonity to maintain the correct pricing data for forex currency pairs and other critical data.

The Autonity Oracle Network is a validator-operated network of oracles (using the Autonity Oracle Server software architecture) that submit price data from off-chain external data providers on-chain. These data points are then automatically consolidated into a standardized report and submitted to the Autonity protocol’s oracle contract via the AOS operator’s validator node.

Submitted data reports are then aggregated by the oracle contract which employs a voting mechanism to furnish exchange rate reference data that is commercially agreed upon by the larger oracle network (each oracle within the network is connected to their corresponding validator via an AOS).

Autonity’s oracle structure is vitally important to the entirety of the system because it allows real-world data from the outside world to be used within the blockchain’s confined on-chain environment. Recall that without all-important asset pricing data, the protocol would be unable to operate.

The Auton Stabilization Mechanism and CDPs

The Autonity protocol leverages the Auton Stabilization Mechanism (ASM) to stabilize the value of the auton (ATN) asset. To facilitate this functionality, ATN employs a CDP-based stabilization design, whereby auton is borrowed in return for depositing tokenized collateral (in the form of NTN or LNTN).

The ASM employs functions to compute the target value of auton and other means to drive the actual market price of auton towards the target value through the supply of auton (ATN) and newton (NTN).

To maintain the stability of auton’s peg, auton tokens are minted (created) and burned (destroyed) as a result of newly opened and closed Collateralized Debt Positions (CDPs). The Stabilization Contract manages CDPs throughout its lifecycle, including for initial borrowing, repayment, and potential liquidation. The Auton Stabilization Mechanism employs the use of three main roles within the protocol, specifically:

  1. Borrower (a CDP owner) - a user that takes out a CDP to borrow auton by depositing collateral. It should be noted that there is no limit to the number of open CDPs a borrower can deploy at one time.
  2. Liquidator (Keeper) a user that liquidates an undercollateralized CDP and repays the CDP’s outstanding debt and receives the remaining collateral in return.
  3. Stabilizer (the ASM Protocol) the protocol account address used to conduct auton mint and burn operations via the Stabilization Contract.

To initiate a CDP, users must deposit newton (NTN) (or liquid newton (LNTN)) to burrow auton at interest. Conversely, autons are burned when a CDP is repaid through the deposit of ATN in the Auton Stabilization Mechanism smart contract, resulting in the removal of the NTN (or LNTN in some instances) as collateral, which is then returned to circulation.

In this system, Collateralized Debt Positions are created with defined collateralization and liquidation ratios to limit the possibility that risk cannot be sufficiently covered through the sale of the collateral.

In the event collateral requirements cannot be maintained, and the value of the collateral is at risk of dropping below the value of the borrowed tokens because of a decline in NTN price, the owner of the CDP is able to either increase the deposited collateral amount, or close the CDP by returning the auton token to the smart contract. If neither of these steps is taken, the forced liquidation of the CDP occurs.

To help ensure the stability of the auton token, the Auton Stabilization Mechanism is linked to a base-invariant volatility minimized index called the Auton Currency Unit (ACU) that leverages a currency basket of seven free-floating fiat currencies (including the Euro (EUR), the US Dollar (USD), the British Pound (GBP), and others).

Supply and demand changes for auton are absorbed by dynamically modifying CDP incentives to increase and decrease auton borrowing costs when the price of the assets moves above or below its ACU stabilization target.

The proportion of the currencies in the basket stabilizing ATN is determined based on the volatility of each currency to ensure the volatility of the overall basket is minimized (while the real-time value of the basket is provided via an Autonity oracle).

This is similar to how algorithmic stablecoins like DAI work, except with DAI, the stablecoin is backed by several Ethereum ERC-20 assets (including ETH, USDC, and others) and numerous real-world assets (RWAs) such as US treasury bills via the Multi-Collateral DAI (MCD) framework.

It is paramount that the stabilization mechanism detailed above works correctly or the derivatives markets operating on Autonity would be unable to function, rendering the platform unusable.

Autonity Network Participants

The Autonity blockchain is composed of four main participants that make up the system’s peer-to-peer network and distributed ledger. In particular, these include:

  • Account holders - human account holders (users) that interact with the Autonity platform and fulfill the operation of node and validator infrastructure, the deployment and use of decentralized applications (dApps), and contribute to the development of the larger Autonity ecosystem.
  • Node operators - peer nodes responsible for running the AGC (the Autonity Go Client) client software to form the foundation of the protoocl’s peer-to-peer infrastructure and ledger. Nodes maintain an up-to-date copy of the ledger’s system state and provide access to an Autonity network (i.e., an individual derivatives market).
  • Validator nodes nodes responsible for running the protocol’s AGC client and AOS oracle server that makes up the network’s validator infrastructure. Validators propose and run system state, while maintaining operation of the oracle network to ensure median price feed data. Active validators are candidates to become part of the consensus committee (validators maintaining consensus change at the start of each epoch), which in turn propose and decide new blocks and compute oracle price data in consensus rounds.
  • Stake delegators - account holders responsible for delegating the newton governance token (NTN) as stake to validators to secure the network. In exchange, stake delegators received liquid newton (LNTN) as bonded stake.

Tendermint BFT and Delegated Proof of Stake (DPoS)

The participants above are also supported by the blockchain’s main consensus mechanism used to provision the architectural integrity of all data and moving parts that make up the entirety of the Autonity blockchain.

The Autonity protocol manages blockchain state machine (architecture responsible for the blockchain’s data state changes) replication via the Tendermint BFT consensus algorithm.

Tendermint is a Proof-of-Stake (PoS) consensus mechanism that employs a repeated consensus model where each block is proposed and agreed via a sequential consensus instance proposed and agreed upon by consensus committee members.

On Autonity, committee members are validators that are selected to append blocks during a specific consensus round (i.e., a time-based epoch). The committee members responsible for completing each epoch instantaneously change at the end of each round to ensure the integrity of the validator set. Like all Tendermint-based chains, consensus on Autonity must reach a 2/3rd’s validator majority to ensure the consensus round is completed correctly.

In addition to Tendermint BFT, the Autonity blockchain makes use of a Delegated Proof of Stake (DPoS) sybil resistance mechanism to prevent sybil attacks, ensure the protocol’s operational efficiency, and realize committee selection for each epoch.

Each consensus round on Autonity leverages cryptographically signed messages broadcast between committee members via three main voting steps:

  1. Proposal - a selected block proposer validates and orders a set of transactions to create a suggested new block to then broadcast the proposal to the committee.
  2. Prevote - each committee member validates suggested block correctness and broadcasts a prevote to the network to approve or reject the proposal.
  3. Precommit each committee member waits to receive a quorum (aggregate voting power) of prevote messages to recognize the proposal as a potential block, which is then broadcast as a precommit to approve or reject the proposal.

If the committee member successfully receives the aggregate voting precommit, the block is broadcast to the network and its block header containing the block proposal and precommit message seals an array of the committee members that voted for the block.

The block is then committed to the ledger where participants that receive the new block check its validity by verifying the seals, which are then synced together to retrieve the block, which is verified by computing block state as it is appended to the blockchain. In the event a quorum (an agreement) between all parties is not reached during the prevote or precommit stages, the network times out, the round terminates, and a new consensus round begins.

Autonity Staking Overview

Autonity’s mission is to revolutionize decentralized derivatives via its distributed Financial Market Infrastructure (dFMI) framework. To accomplish this goal, a stable and secure blockchain is needed to enable the functionality of a truly decentralized marketplace.

To ensure this process operates as intended, the network makes use of an incentivized liquid staking paradigm that works hand-in-hand with its validators to redistribute value back to network participants. Validators realize this goal by participating in Proof-of-Stake consensus to ensure their profitability from transaction fee distribution and Autonity’s stake inflation mechanism.

The Autonity liquid staking model is designed to ensure capital efficiency and composability. It guarantees capital efficiency because rewards from staking are combined with the liquidy benefits of transferable bonded stake. It guarantees composability because liquid staked tokens can be transferred and used within other protocols (e.g., as collateral).

To ensure validator integrity, the platform makes use of a Penalty-Absorbing Stake (PAS) model that determines slashing priorities via two main staking models. These include:

  • Self-bonded stake (NTN tokens deposited by the validator operator to its own validator to contribute to network consensus) is slashed as first priority until exhaustion. Self-bonded stake allows validators to earn staking rewards, however, unlike delegated stake, validators do not receive newly minted liquid newton (LNTN) in exchange for bonded newton (NTN). If a validator holds unbonded stake, the unbonding stake is slashed before the bonded stake.
  • Delegated stake is slashed as second priority in the event the slashing amount exceeds the amount of self-bonded stake available. During the liquid staking process, stake delegators delegate the newton (NTN) governance token to validators in exchange for liquid newton (LNTN), which can then be redeemed for the underlying NTN via the unbonding process. If the delegator holds unbonding stake, the unbonding stake and bonded stake are slashed pro rata (proportionally) with equal priority.

In the Penalty-Absorbing Stake model, self-bonded stake has a unique risk profile compared to delegated stake because it furnishes loss absorbing capital should a slashing event take place. Consequently, liquid newton is only minted for delegated stake to ensure validator liquid newton has a balanced risk profile.

When delegated stake is bonded within a validator, liquid newton (LNTN) is minted in exchange for the staked newton (NTN) and the staked newton is locked. The amount of liquid newton minted for the staked newton is proportional to the amount of delegated stake the validator possesses at the time bonding is initiated.

This conversion rate is maintained via the validator’s Liquid Newton Contract as the reference price for newton bonding and unbonding operations (determined via the rate of issued liquid tokens in proportion to the total amount of staked tokens bonded within the validator).

As a result, the minted liquid newton is subject to potential accountability and omissions (infractions that result in penalization) applied to the validator, meaning slashing takes place:

  • If at the time of bonding, a validator’s delegated stake amount hasn’t been reduced via a stake slashing event, liquid newton is minted at a 1:1 ratio for the delegated newton staked.
  • Conversely, if the validator’s existing delegated stake amount is less than the supply of issued newton, liquid newton is minted in proportion to the validator’s remaining delegated stake, resulting in a >1:1 issuance ratio of liquid newton for newton staked.

This tokenomic mechanism guarantees that a validator’s liquid newton (LNTN) tokens remain fungible (mutually interchangeable) during their continued issuance over time, meaning that the amount of liquid newton issued during the bonding process has a value proportional to the value of the newton (NTN) being bonded.

When stake is unbonded, it is subject to an unbonding period, allowing the holder’s liquid newton to be redeemed in proportion to its share of the liquid newton pool (i.e., the total amount of NTN held within the validator), less any applied slashing penalties.