Skip to content

Feature: Implement a Dutch Auction Mechanism for On-Chain Token Burns #1763

Description

@Emmyt24

Overview

Add a Dutch-auction mechanism for token burns, used as an on-chain, transparent price-discovery method:

  1. Admin creates an auction specifying the token, burn amount, start price, reserve price, and duration.
  2. The current price decreases linearly from start_price to reserve_price over the auction duration.
  3. Any bidder who pays the current price wins the auction immediately.
  4. The winning bid amount is burned from the token supply.

Scope: contract only. No backend or frontend integration is required for this feature.

This feature is conceptually related to the Commit-Reveal Auction Tie-Breaking issue — that module is designed to resolve simultaneous-bid ties for auction-style mechanisms like this one. Check whether it's a hard dependency before deciding whether to pick up both together.

Integration points

  • New module file contracts/token-factory/src/burn_auction.rs, declared via mod burn_auction; in lib.rs
  • Public #[contractimpl] entry points added to the TokenFactory impl block in lib.rs (create auction, bid/win, price query, cancel/expire)
  • New DataKey variants added to types.rs for auction state — do not reuse existing discriminants
  • New Error variants added to types.rs starting at 133 (current highest in-use code is 132), with matching entries added to Error::name()
  • Storage getters/setters added in storage.rs following the existing pattern
  • Events emitted via events.rs using short symbol_short! topic names (Soroban's 9-character limit)
  • Winning bid should burn from supply via the existing burn.rs module rather than a parallel burn implementation

Acceptance criteria

  • burn_auction.rs implemented under contracts/token-factory/src/, wired into lib.rs
  • Create/bid/query/cancel entry points implemented
  • DataKey/Error additions follow the checklist above
  • Storage and events wired following existing patterns; winning bid burns via burn.rs
  • Unit tests in burn_auction_test.rs covering: linear price decay over time, winning bid at/above current price, bid-below-current-price rejection, expiry with no winner, reserve-price floor
  • Consider adding a fuzz target (fuzz_burn_auction.rs) with a seed corpus covering at least: a bid below reserve price, bid-amount overflow, decay reaching the reserve floor, and a zero-duration auction — wired into .github/workflows/fuzz-testing.yml if added
  • cargo check --lib and cargo test --lib clean in contracts/token-factory
  • cargo build --target wasm32v1-none --release --lib succeeds

Notes for implementers

  • Good edge cases to seed fuzzing/property tests with: a bid placed below the current reserve-decayed price, arithmetic overflow on a very large bid amount, the price decay curve hitting its reserve floor exactly, and a zero-duration auction. Make sure the implementation handles all four correctly before considering this done.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardThird CampaignCampaign: Third CampaigncontractSoroban smart contract workenhancementNew feature or requesthardHard/complex, cross-cutting contribution

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions