Closed protinam closed 6 years ago
Thanks for laying out your thoughts on this. Seems like a lot of it comes down to timing. Currently the friction involved in using protocol tokens (at least in the Ethereum network) is somewhat high, but as friction decreases the protocol token approach is ultimately more flexible.
I would personally support allowing both models and letting applications choose. Seems like that could potentially accelerate development of the application layer in the short to medium term.
One proposal that may interest you:
Fees are paid in a protocol token (Not Wyvern DAO tokens) at some fixed rate, and protocol tokens are created via the holding of wyvern DAO tokens. For instance, if I hold 1000WYV, perhaps I can be credited with 0.1WYP every block, or something.
And then, alternately, a fee can be paid in the form of ethereum. This will peg the wyvern protocol token's value to that of ethereum and create effectively a stablecoin once wyvern becomes more widely adopted. It also allows early adopters of the protocol to get a "discount" on fees in the form of cheaper WYP.
@MCFX2 Interesting, but I'm not sure I completely understand what you're proposing - can you elaborate? What would be the economic benefits of a secondary protocol token?
In my view the two priorities of the fee model should be to:
In plain English, we want WYV holders to be people improving Wyvern, building on Wyvern and those who are taking a longer term view on decentralized exchange of NFTs.
Right now you can argue that the extra steps (UX wise) required for the use of the WYV protocol token are a headwind for priority 1. Requiring WYV to be the token for fees = more steps = less UX friendly = less competitive application layer exchanges on WYV. Additionally, the current lack of exchange liquidity situation makes using the protocol token for fees less attractive at this moment.
Agree with @dfinzer that both the protocol and split fee model would be interesting. Here is the split fee model I think is worth exploring:
In the above model, the interests of WYV holders and Wyvern protocol users are very much aligned. The clearest area of friction is the fixed % transaction fee and selection of possible fee tokens. To have a say in these matters, applications will need to acquire WYV tokens, which will then give them a competing incentive to choose a fair number (as they benefit from higher fees as holders).
@protinam much like gas is to neo, the current wyvern token would take on a sort of administrative role and the new protocol dividend token would play a functional one. This has a few benefits:
Some serious drawbacks to this approach exist though, and are worth mentioning:
tl;dr, non-negligible economic benefits with non-negligible technical debt
@alextreece
I agree generally with the fee model priorities you list, and I think the protocol should make use of the decentralized upgrade mechanism both to experiment with multiple models simultaneously and to change models over time as the costs and benefits change (e.g. - the application-layer UX friction of protocol tokens may be much lower in the future).
The split fee implementation I initially envisioned would simply pay the fee in the token which is used to pay for the asset. Specifically, given two constants fee_protocol
and fee_relayer
:
x
WETH.x
WETH to the Exchange contract and receiving the CryptoKittyx * fee_protocol
WETH to the Wyvern DAO, x * fee_relayer
WETH to the relayer (feeRecipient
in the current order schema), and x * (1 - fee_protocol - fee_relayer)
WETH to Bob (all in the order match transaction, some possibly pull payments instead of push to minimize gas costs).fee_protocol
would be set by the Wyvern DAO - probably initially to 0 - and could be changed as frequently as the DAO passes proposals to change it.
fee_relayer
would be set by the orderbook server run by the relayer (e.g. Wyvern Exchange, OpenSea) as a field of the order schema and could be changed as often as the relayer likes or even calculated as a function of other order parameters (perhaps a relayer would want to charge different fees for different assets).
It may be useful to further specify fee_protocol
and fee_relayer
separately for makers and takers.
This addresses points 1-3 above as follows:
@MCFX2
I think the technical complexity of a dual token system makes it a poor candidate for a near-term protocol upgrade. That doesn't mean that it wouldn't make sense at some point in the future.
I don't understand the benefits of this administrative/functional divide - specifically the differing incentives (as compared to a single token). Does NEO have an economic position paper or equivalent?
@protinam I think that split fee implementation is a good approach. I'm supportive.
On setting fee_protocol
to zero initially: that is a good idea in the near term to stimulate usage. If simple enough though from a technical perspective, it would be nice to give applications the option of whether to pay a fee to the protocol, in case they want to support Wyvern development (even though they don't have to right now - I think many would).
Re my comment on 3 - I might not have been clear or possibly just misunderstanding how the DAO receives fees. I was envisioning a system where the total fee_protocol
is automatically split and distributed to WYV holders pro rata for their ownership. So if the DAO had 5% of WYV tokens, it would receive a 5% allocation of aggregate fee_protocol
generated. If Bob has 1%, he gets 1%. And so on.
The benefit of this system is that there is immediate economic alignment - WYV holders get rewarded immediately with protocol usage and are incentivized to find market fee/usage equilibrium. The possible problem with this model from the DAO's perspective is that spending DAO funds (if spending WYV) reduces its pro rata allocation, thus leading to less future funding for protocol development. It could also go in the other direction: if the DAO accrues WYV through fee_protocol
allocation, it would increase it's pro rata share and continue the cycle upwards. In reality most people will use ETH/WETH, so perhaps this is not something we should be concerned with.
I believe the fee split model you are outlining would send all of fee_protocol
to the DAO and then WYV holders could vote on when/how to make distributions. That is a fine model and would certainly maximize available developer funding (A potentially good thing, especially at this early stage). However, it also may have two potential drawbacks:
fee_protocol
be automatically distributed@alextreece
I like the idea of giving applications the option of whether to pay a fee to the DAO (while retaining the ability for the DAO to impose a mandatory fee later), and that should be simple enough to implement.
In the very near term, this may be the case, but once the markets are liquid and the project is a bit better known, I would expect funds held by the DAO to be reflected in the value of WYV tokens - more resources held by the DAO should increase the likelihood of the protocol succeeding and thus the future expected value.
This is true, but I think this is a feature, not a bug. Majority control prevents a tragedy of the commons where actions in the immediate rational interest of individual shareholders are worse than the optimal actions for the shareholders as a whole. Were a distribution model used, individual shareholders might not have the resources to add substantial value to the protocol, whereas, had they pooled their resources, they would have (out-of-band coordination is possible too, but the on-chain coordination mechanics provide a clear focal point).
A blatant "tyranny of the majority" - where, say, 60% of shareholders organize a cabal and vote to move all the DAO's assets to a new DAO which they own completely (the other 40% get nothing) is possible - but almost certainly against the rational interest of those 60%. Although the shareholders may be pseudonymous, the protocol has a public reputation. Were it to violate norms so egregiously, users and markets would punish them harshly (would you ever want to be a minority shareholder of a protocol which did this?) - and the shareholders know that this action would be punished, so they will simply never take it.
I'm in support of the proposed fee changes. Thanks for writing this up @protinam
Tentatively implemented in https://github.com/ProjectWyvern/wyvern-ethereum/commit/24c75035cd300dc759016c26d202fc38a48f4635. I will add more testcases and contact our auditor tomorrow.
Implemented and ready for audit; see v2 audit specification. The audit spec covers all the changes made relative to the existing protocol version.
@dfinzer Before I submit to the auditors, can you confirm that this maker/taker fee model for unwrapped Ether will work for you?
As a relayer, you have control over makerRelayerFee
and takerRelayerFee
.
Maker fees for asset sellers are implemented as reductions in the amount the seller receives - if I sell a CryptoKitty for 1 ETH, and the relayer charges a 1% maker fee, the buyer will pay 1 ETH, I will receive 0.99 ETH, and the relayer will receive 0.01 ETH.
Taker fees are implemented as additional amount the taker (who will always be the asset buyer with unwrapped Ether) has to pay - if I sell a CryptoKitty for 1 ETH and the relayer charges a 1% taker fee, the buyer will pay 1.01 ETH, I will receive 1 ETH, and the relayer will receive 0.01 ETH.
Relayers can implement just maker fees, just taker fees, both, or neither at their option. Fees are specified in basis points (hundredths of a percent).
Using the split fee model, the owner of the Exchange contract (the Wyvern DAO) can set minimum values for makerProtocolFee
and takerProtocolFee
as suggested by @alextreece. These are calculated in the same way as the relayer fees. The initial minimum values will be set to zero (and I do not expect the DAO to change them anytime soon), so no protocol fees are presently required. Anyone placing or matching an order can still opt-in to paying a small protocol fee (which relayers could choose to enforce, or just offer as an option to their users in a settings dialog).
Sounds great, thanks @protinam !
Updated contracts have been submitted for a bounty through Solidified, and the private auditor we worked with last time has agreed to review the updated version.
I recommend we give the auditors a day or two to see if they find anything obvious - then we can start the upgrade process (should the auditors find anything later, we can just restart the process with a fixed contract).
@protinam Great! Have the upgraded contracts been deployed to Rinkeby?
@dfinzer Yes, deployed and verified (except for the Exchange contract, Etherscan seems to have a verification time limit, you can double-check the bytecode yourself if you like).
Updated addresses are in the README and in config.json
- https://github.com/ProjectWyvern/wyvern-ethereum/blob/master/config.json.
wyvern-js v2 beta ("2.0.0", skipped a version so library versions will match protocol versions going forward) released. That will interface to the new Rinkeby contracts, and also includes JS bindings for the new "WyvernAtomicizer" contract, which you can use to combine multiple transactions together - for example, allowing a user to multi-select three CryptoKitties in the UI and sell them all at once as a bundle.
Awesome, thanks @protinam !
One bug found through audit: this - wouldn't lead to any user losing assets or tokens, but definitely worth fixing.
I'll push a fix and redeploy to Rinkeby later today (although the current contracts will work fine; this just prevents an obscure attack that would prevent order matching).
Fixed in https://github.com/ProjectWyvern/wyvern-ethereum/commit/9e6b1e4b30e8e534b58ff06f6d640c37229fdc85#diff-3e95bd8b0359453cfce17b5d3901cf3bR586 and redeployed to Rinkeby. wyvern-js 2.0.1 has the updated addresses.
Solidified audit report complete: https://github.com/ProjectWyvern/wyvern-ethereum/tree/master/audits/v2. No issues other than the one already fixed. I'll deploy contracts to mainnet later today, then the upgrade process can start.
The first part of the authorization procedure is complete and the two-week timer has started (the second DAO proposal should be submitted three days prior so that it can be passed as soon as the mandatory wait period has elapsed).
Protocol upgrade passed, closing this for now.
Feel free to reopen if more fee models come to mind.
Preamble
Summary
Discuss which fee models will properly incentivize network participants. Possibly implement multiple models simultaneously and let the free market decide which are most suitable.
Motivation
Wyvern is a "layer-2" protocol: it sits between "layer-1" distributed ledgers (currently just Ethereum, but likely more in the future) and the application layer (consumer-facing DApps, such as the Wyvern Exchange). In order for the protocol to be successful, I think the following need to hold:
These are not really that different from the requirements of layer-1 protocols - Ethereum, for example, fulfills the three:
The primary difference between layer-1 protocols and layer-2 protocols at the moment is that the value capture mechanism for the latter is less clear. Layer-1 protocols also need the value capture mechanism to prevent network spam (hence the proportionality of gas costs to execution time). Layer-2 protocols do not have this restriction.
Description
At the moment, I can think of two distinct possible models of value capture (more may exist):
Protocol Token
One method of value capture, and the one implemented by Wyvern at the moment, is a protocol token - a particular fungible asset required to pay for usage of the protocol.
Advantages
Disadvantages
Split Fees
Another method of value capture, which is not currently implemented but would not be difficult to add, is to allow protocol users to choose the token of payment and split fees with the protocol itself (through the DAO). The DAO would set some fixed fee percentage.
Advantages
Disadvantages
One option is to implement both models and allow applications to choose which one they wish to use.
Transaction Details
TBD
Copyright
Copyright and related rights waived via CC0.