Skip to main content

Concepts

Axis is a modular auction protocol that allows for the creation of different types and combinations of auctions and derivatives.

Design Principles​

When designing Axis, we started with these principles in mind:

  • The architecture should be modular and enable support for different types of auctions and derivatives.
  • The protocol is designed to be permissionless and community-owned, with the goal of being a decentralized and open-source protocol.
  • Users should interact with a single contract for bidding and claiming of auction proceeds. This singleton contract should implement core functionality needed by all auctions for receiving payments, sourcing payouts, and routing funds as appropriate.
  • Develop base contracts for modules with standard functionality to avoid code repetition and requiring limited development for new variations of auctions and derivatives.
  • Auctions should allow for integrating custom functionality (via callbacks) that isn't appropriate for all cases, but is needed to suit the needs of many users.

Contract Types​

The protocol contains three main contract types that work together to allow Axis to fulfill a variety of use cases:

  • Auction House: A singleton top-level contract for the system that users primarily interact with. It implements core logic and custodies funds during auctions. It also handles management of the system modules. There is one AuctionHouse per Auction Type, which are described below.
  • Modules: Modules are what Axis "modular". Axis supports three types of modules as the primary abstractions in the system:
    • Auctions: Auction modules define specific types of auctions that can be run on Axis.
    • Derivatives: Derivative modules define systems for creating derivatives of tokens that are offered for sale. They implement the ERC6909 interface, optionally support ERC20 wrappers (for composability), and custody funds for the derivatives they create.
    • Condensers: Condenser modules provide compatibility between the output of auction modules and the input of derivative modules.
  • Callbacks: With Callbacks, Sellers can customize the functionality of existing auctions by adding logic throughout their lifecycle using an external contract. Some example uses of callbacks:
    • Defining an allowlist for an auction lot
    • Depositing proceeds from an auction lot directly into a liquidity pool
    • Sourcing tokens from a wallet other than the one used to create the auction
    • Handling external fee logic not supported by the core protocol
    • Determining incentive levels for locked tokens by wrapping provided quote tokens and vesting them back to the bidders.

Auction Types​

Atomic​

  • Definition
    • Atomic Auctions are auctions where a bid is submitted, instantly accepted or rejected, and settled within a single transaction. As a result, it is more similar to a "purchase"
    • Atomic auctions are settled at the time of purchase
    • Settled immediately: offered tokens are transferred at time of purchase
  • Examples include:
    • Sequential Dutch Auction

      The main feature of an SDA includes splitting a large number of tokens into multiple discrete Dutch Auctions that are performed over time. This sequence of auctions uses a dynamic exchange rate for two arbitrary ERC20 tokens without the use of oracles.

    • Gradual Dutch Auction

      While SDAs split capacity into multiple discrete auctions, GDAs split capacity into infinitely many auctions with an exponentially increasing purchase price

Batch​

  • Definition
    • Batch Auctions refer to the more familiar auction format of collecting bids from participants over a set duration and then settling the auction at the end based on the best received bids. “Batch” refers to the notion that proceeds are received and auction units distributed in a batch, rather than individually.
    • Payout tokens are collected from the seller when an auction begins
    • Quote tokens are collected from the bidder at the time of the bid, and paid out to the seller at the time of settlement
  • Examples include:
    • Marginal Price Auction

      A marginal price auction, also called a uniform price auction, is a multi-unit auction format where bidders place bids that include two variables: price and quantity of items to purchase. The auction is settled by awarding the items to the highest bids until capacity is expended. All winners pay the lowest accepted bid price. The price of this lowest accepted bid is also called the clearing price of the auction.

    • Vickrey-Clarkes Groves

      VCG auctions are a form of second-price auction (sometimes called Vickrey auctions) extended to the multi-unit domain. They require a sealed bidding process to incentivize participants to bid their best price.

Terminology​

Lot​

  • What is being sold
  • A token or group of tokens that are available for bidding through an auction
  • The current design supports a single lot per auction

Auction​

  • The auction (specifically the type) specifies how the lot is being sold

Auction Type​

  • Described above. Atomic or Batch.

Auction Format​

  • A specific auction pricing and/or settlement format implemented in an Auction Module. Examples include, Fixed Price Sale, Encrypted Marginal Price, Gradual Dutch Auction, etc.

Quote Token​

  • The token that is offered by the bidder and received by the seller in return for the base token

Base Token​

  • The token that is provided to the bidder in exchange for the quote token
  • If the auction lot is configured to use a derivative module, then the bidder receives the derivative on purchase or settlement instead of the base token.

Derivative Token​

  • A derivative of a base token that a bidder may receive instead of the base token for an auction

Keycode​

A 5-byte identifier of each Module installed into the AuctionHouse. The identifier is un-versioned, and used with the getModuleStatus() function to obtain the versioned Veecode of the Module.

Veecode​

A 7-byte identifier of each Module version installed into the AuctionHouse. The identifier is a combination of 2 digits and the module Keycode. For example: "01EMPA" represents version 01 of the EMPA module.

Security Considerations​

  • The goal is for the protocol to be permissionless and community-owned, which alters the security considerations
  • Auction creators should configure their auctions at the beginning and have limited ability to change the parameters once the auction has started.
  • Callbacks allow for many customizations, but may also introduce security vulnerabilities. We have endeavored to protect the AuctionHouse from malicious callbacks by being explicit about when tokens are sent or expected back. Additionally, major functions are protected from re-entrancy within the same transaction, which could happen via a malicious callback.
  • An "abort" function is available on batch auctions that allows sellers and bidders to retrieve their tokens in an auction ends and cannot be settled.