GM Pythians,
Thanks for a solid proposal from the KiloEx team and a solid execution plan from Douro Labs!
While opBNB’s TVL is relatively small as of the time of writing this, I believe there are some catalysts, such as direct withdrawal from Binance to the opBNB chain (which is currently live), that could fuel its growth. Being deployed as a first mover on a chain that has the potential to grow usually brings unique competitive advantages and also makes it a go-to choice when new apps deploy there. Hence, I support and am excited to see Pyth deploy on opBNB.
In regard to the ‘price per update’ parameter left for the Pythian Council to determine, without delving into KiloEx’s codebase as their contracts are currently closed-source, typically there are two key actions that involve oracles for most pool-based perp dex platforms: adding/removing liquidity, and trading. I believe we could work backward to determine how many prices each of these actions needs to be updated and find a middle ground between Pyth, KiloEx, and users.
Based-on my guess on how KiloEx contracts work, here is what I think:
1. Adding and removing liquidity: This action will require updating prices for all listed markets to calculate the kUSDT value on-chain. Currently, KiloEx has listed fifty markets. Based on transactions I’ve tried on KiloEx, it seems that KiloEx is currently pushing these prices to the oracle contract and allowing the pool contract to query prices from the oracle contract, as the add liquidity transaction is atomic and doesn’t rely on any keeper. Assuming KiloEx pushes prices every ten seconds to ensure the kUSDT value on-chain is always updated, and considering KiloEx currently has a trading volume of $26 million per day on average in May (thanks to @0xkeyrock.sol for the data!), that equates to $26,000 in topline protocol revenue (before distribution to kUSDT s. Let’s say a fair oracle cost for KiloEx is approximately 1% of the topline protocol revenue, which is $260 maximum per day for oracle costs. Given this number, the fair ‘price per update’ should be 260 / ((86400 / 10) * 50), approximately $0.0006 if KiloEx will be the only one that pushes prices on opBNB.
2. Trading: Currently, KiloEx charges 0.000014 BNB (or $0.01) for an execution fee, which I assume should cover everything on KiloEx’s end. I’m wearing a trader hat and quickly looked into data and compared this to other perps in the market. See the table below:
| Perps | Execution Fee ($) |
|---|---|
| GMX | ~$0.33 |
| HMX | ~$0.16 |
| Synthetix v2 | ~$1.38 |
Given @KemarTiti’s suggested ‘price per update’ fee of ~$0.09 and combined with the existing base fee, the total execution fee from a user’s perspective will be ~$0.1. I think it is still economically sound and competitive compared to other leading pool-based perp dexes.
However, this is based on the assumption that KiloEx contracts update only one single price per trade. If this assumption turns out to be false, I suggest we work backward from the execution fee target that is compatible with other perp dexes and come up with a final ‘price per update’ fee from that.
I personally don’t have access to the number of trades per day on KiloEx. However, taking 5,000 trades per day from @KemarTiti as a reference, this would mean, on average, Pyth prices on opBNB will get updated every 17.28 seconds by traders on KiloEx, which should keep prices fresh enough for ‘add and remove liquidity.’ Hence, passing costs to traders while still maintaining an overall execution fee compatible with other perps is preferable.
All in all, I’m leaning towards the logic behind what @KemarTiti suggested. However, I would like to get confirmation from KiloEx on how many price updates your contracts need per trade, so that we can agree on how much the ‘price per update’ should be.