Elixir
  • About Elixir
  • Network Architecture
    • Validators
    • Fraud Proofs
    • Exchange Orderbook Connections
  • deUSD
    • deUSD Architecture
      • deUSD's RWA Institutional Program
      • Execution Buffer Fund
      • Centralized Exchange Execution
      • (Upcoming) Decentralized Exchange Execution
    • Addresses
    • Utility
    • Yield Calculation
    • Potion Rewards
    • Dashboard (WIP)
    • API
    • Risks
      • Smart Contract Risk
      • Custody Risk
      • Execution Risk
      • Collateral Risk
      • Regulatory Risk
  • Native Exchange Integrations
    • Building Orderbooks
    • Preventing Gamification
    • Exchange Rewards
  • The ELX Token
  • Staking / Delegation
  • Running an Elixir Mainnet Validator
  • Audits
  • Bug Bounty
  • Socials
  • FAQ
Powered by GitBook
On this page
  1. Native Exchange Integrations

Preventing Gamification

Decentralized, transparent trading systems face the risk of gameability: allowing outside players to attempt to pass toxicity onto Elixir's LPs.

To counteract this, our network utilizes randomly generated components within the strategy we use. Our strategy is a variant of the finite Avellaneda-Stoikov algorithm, where instead of (T - t) linearly progressing to 0, our network provably randomly generates a value for this parameter (random walk between 0 and 1). This will be generated within validators' SGX secure enclaves, and synchronized across validators.

This value is calculated on an ongoing basis independently for each pair on each exchange, introducing significant entropy and making it impossible to calculate future values given a set of input data for both the optimal bid/ask (δa, δb)and the reserve price r(s,t).

Order times will also be random: they'll be passed onto exchanges at randomly determined intervals (or sometimes not at all). This practice, known as "flickering orders", prevents a knowledgeable market taker from attempting to game the network's orders on exchanges.

Last updated 8 months ago