-
Notifications
You must be signed in to change notification settings - Fork 31
Fee Model Considerations
Map the structure of interaction and identify the parameters that influence market dynamics. Fix as many parameters as possible and reduce the problem space to a “decidable subset” so that design choices can be evaluated against design goals.
Setting cost, rewards and penalties in a way that all actors’ individual optimal strategies align with market design goals, and simple, efficient, failsafe market dynamics can be ensured.
All fees, rewards, and parameters are allocated so that they transparently align with productive efforts of the participating actors. All dynamically calculated parameters have to be transparent to all participants.
Market performance (cost/benefit, speed, volatility…) benchmarks against competing decentralized and centralized (pure-token) exchanges.
No opportunistic action can be taken by individual or colluding actors without incurring significant costs and/or efforts.
Timing games/waiting games are types of games where players have to choose the perfect timing for a (single shot) action. Markets are prone to failure if the optimal strategy is “first after (event)” or “last before (event)”, as even sparsely populated markets become congested at those points. Illiquid/sparsely populated markets create a waiting game while actors seek to find out if there are trading opportunities (nobody goes in bc nobody goes in). Optimal mechanisms/fee structures enable ordering throughout the collection period.
A strict limit of slots will eventually lead to congestion, which creates allocation problems and arbitrage opportunities. No good mitigation strategies exist, but especially congestion pricing can explode before slots are filled, and can drive liquidity creators out of the market.
“Frontrunning” in batch auctions requires filling up all slots after the observed frontrun opportunity. This has an additional detrimental effect on the market, as it prevents other traders from entering their orders.
Running multiple fast markets with widely differing levels of liquidity will inevitably lead to excess volatility in those fringe markets (source: massive finance literature). Using a centralized solver and arbitrage-free criterion this could mean that volatility could also affect the more liquid markets. This is an empirical question which requires testing/simulation.
Collectors are trusted actors and as such can create trust failures. This is exacerbated if collectors can collude or gain a dominant role in the order collection process. (Note: collectors postponed for now.)
Collectors can submit more orders than batches are available, which leads to partial allocation in current and future batches. Under inter-batch volatility this can lead to market inefficiencies and expropriation.
There is currently no specification that describes collector behavior and identifies potential fail points.
SOLVER FRONTRUNNING/MULTI-ROLE PARTICIPANTS Depending on privacy of orders, Solvers can monitor incoming orders, precalculate optimal solutions, submit own orders and optimize their own welfare function.
Not economically motivated disruption attacks on the system.
ACTOR Any entity participating (transacting) in dfusion exchange PAYMENT Transfer of tokens with defined payload INFORMATION Transfer of non-token objects with defined payload TRANSACTION Recorded unilateral transfer or exchange of transfers STORAGE Transient or persistent holding of information/tokens COMPUTATION Computational effort to process information
TRADER Actor (person, org, bot, contract) submitting a trading order SPECULATOR Trader looking for arbitrage opportunities COLLECTOR Actor collecting, bundling, and submitting trading orders TRANSLATOR Actor computing Pedersen hashes from SHA256 hashes SOLVER Actor computing a proposed optimal order matching [CHALLENGE RESPONDER Responds to challenges] [CHALLENGER Actor taking required steps to challenge a proposed but not proven solution] ANCHOR Smart contract orchestrating the workflow
DEPOSIT Payment to participate in the market FEE Payment to have a trade order submitted/executed BOND Temporary payment to gain the right to propose a solution for a reward REWARD Payment upon selection as the optimal proposed solution LEASE Payment to reserve a trade order slot in a batch BOUNTY Payment upon successful challenge (possibly identical to bond)
ORDER ORDER COLLECTION SHA256 HASH PEDERSEN HASH TRADE MATRIX …
TRANSFER EXCHANGE
SHA HASHING PED HASHING offchain SOLVING Matching trades within a batch to create PRICE and VOLUME matrix ORDER SELECTION Mapping of submitted order to batch X (or future batches) SNARK
ONCHAIN executed on the EVM LOCAL executed offchain in a local machine (low computational effort) CLOUD executed offchain in a datacenter (high computational effort)
COMPETITIVE Markets, auctions, tournaments HIERARCHIC Dictatorial, federated, script (anchor contract) RANDOM ELECTORAL
-
DEPOSIT
-
RESERVE SLOT
-
ORDER 1a. ORDER (DIRECT) 1b. ORDER (COLLECTIVE)
-
ORDER BATCH SLOT ALLOCATION 2a. BROADCAST ORDER BATCH
-
TRANSLATE SHA>PED 3a. CHALLENGE
-
SOLVE ORDER BATCH (ORDER BOOK) 4a. SELECT BEST ORDER MATCHING 4b. CHALLENGE
-
SETTLE AND TRANSFER
-
PROCESS EXIT REQUEST 6a. CHALLENGE
TRADERS - ANCHOR order against a warranty that order will be placed as is TRADERS - COLLECTORS order against a (trusted) confirmation, pay on placement COLLECTORS - ANCHOR batch orders against warranty, batch orders into reserved slots ANCHOR - TRANSLATORS sha vs pedersen, bond vs snark, reward to “winner” CHALLENGER - ANCHOR - TRANSLATOR bond vs bounty (if successful) ANCHOR - SOLVERS order book vs order matrix, bond vs reward to winner CHALLENGER - ANCHOR - SOLVER bonded solution challenge TRADER - (COLLECTOR) - ANCHOR exit request
Custom Footer! Sweet!