Information Protocol: Deriving a SUAPP from first principles (beginning with the ideal PFOF requirements)
Caveat; this is hand-wavy and lacks concrete implementation details. Although, @dmarz has a good intuition for what the idea is and should be able to help disseminate. Views expressed here are an aggregation of ideas from the researchathon PFOF group, not necessarily reflective of any individual’s opinion.
Building an Intuition
Some assumptions from first principles before we discuss the idea of Designing the Ideal Payment for Order flow application and discuss some problems.
Who Pays for the order flow?
- Tradfi (narrow the spread)
- DeFi (business models)
- It is the person who captures the MEV
- Searchers
- Solvers
- Builders
Validators
Order Flow Originator generates the MEV
- User - gets nothing, how can we make this more competitive?
- total Cost for execution
- Optimize for inclusion → some threshold? (pre-set probability)
- Limit Orders are hard
Why would an agent in the system pay for the orderflow?
- Soft flow → Narrows the spread post PFOF, happy to pay slippage
- Batches are difficult because there is no proven National Best Price Execution
- Pay on RFQ basis per trade is typically better
How to Segment the Orderflow between Toxic and non-toxic?
- Soft flow (i.e. non toxic flow)
- Everything else
Key Question is What happens after the trade?
→ Was the flow adversarial and toxic or was there natural / positive slippage
Desiderata
Design a PFOF as an iterated game which creates an incentive for unknowns to behave which potentially can help mitigate the sybil problem without a proven proof of identity.
- Better reputation = more orderflow
- Unknown reputation = less or no orderflow,
In order to do this you need a way to identify orderflow. Is there a way to use a combination of on chain identities and post-execution outcomes to determine the quality of the orderflow. If the quality is high, the operators will pay for it, if the quality is low they will pay less for the flow or not bid at all.
- Objective: Build a SUAPP that other SUAPPs can plug into order use as an oracle that communicates a quality score for users and operators.
- Economic sustainability: Charge a fee for this intelligence as an economic model. This could be a public good that gets funded with rpgf which allows for continued operation.
- Motivation: Incentivize reporting by building on SUAVE as its a benefit for everyone who reports. (Need concrete game theoretic analysis). Token incentives could also be used to bootstrap (beyond the scope)
Hand-wavy Implementation Details
Set-up a private voting system on SUAVE that lets operators vote
- if order flow they receive on a per transaction basis is toxic or non-toxic. (hand-wavy TBD)
- Transactions on SUAVE should be cheap so posting votes on chain should not be a problem