Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider implementing alternative fee models #6

Closed
protinam opened this issue Feb 23, 2018 · 22 comments
Closed

Consider implementing alternative fee models #6

protinam opened this issue Feb 23, 2018 · 22 comments

Comments

@protinam
Copy link
Member

protinam commented Feb 23, 2018

Preamble

WDP: 2, 3
Title: Implement alternative fee models
Author: Protinam <protinam@protonmail.ch>, dfinzer <devin.finzer@joinozone.com>
Status: Draft
Created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
Requires (*optional): <WDPs that must be executed before this proposal>
Replaces (*optional): <WDPs that are replaced by this proposal>

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:

  1. The protocol must effectively abstract over a class of application layer requirements (and by abstracting over that class provide economics of scale on development time).
  2. The protocol must capture some, but not all, of the value provided by the applications using it, and employ a mechanism to channel this value back into continued protocol development, making the protocol, should it prove successful, self-perpetuating.
  3. At any point in time, the comparative utility for applications which might make use of the protocol must be positive (versus copying the protocol or writing their own version).

These are not really that different from the requirements of layer-1 protocols - Ethereum, for example, fulfills the three:

  1. Ethereum abstracts over the set of higher-level applications which can implement their necessary computations on the EVM.
  2. Gas costs capture some of the value from higher-level applications, but applications can (and do) implement their own fee structures.
  3. Implementing a DApp on Ethereum - versus rolling one's own distributed ledger - cuts development time substantially and provides access to both platform tooling and an existing knowledgeable community.

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

  • Captures some of the value at the protocol layer - demand for applications using the protocol will translate into demand for protocol tokens, which will provide the protocol itself (through the DAO and tokenholders) more resources to fund further development.
  • Fees are chosen by the applications and may vary both to suit different use cases and different requirements over the lifecycle of an application (e.g. initial zero-fee promotions).
  • May provide advantages in decentralized governance - applications using the protocol will naturally acquire stake in the protocol itself (although they likely will need to sell some to cover operational costs).

Disadvantages

  • Additional friction and/or cost at the application layer - applications using the protocol must handle conversion to/from protocol tokens.

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

  • Captures some of the value at the protocol layer - demand for applications using the protocol will translate into fees paid to the Wyvern DAO, which may convert those fees into resources to fund further development.
  • Possible to decrease application-layer friction by implementing the application fee model (e.g. 0.5% of purchase amount) directly in the protocol.

Disadvantages

  • More difficult to customize fees at the application layer - the protocol must choose a fee for all applications using it (although this fee could change over time).
  • May be closer to a "security" under present US legal definitions. The protocol itself is not meaningfully subject to legal action, but protocol users may be. (I think this "utility token" / "dividends" distinction is silly - the economic model is not really that different in the end - but protocol stakeholders should still consider the risk)

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.

@dfinzer
Copy link

dfinzer commented Feb 23, 2018

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.

@MCFX2
Copy link

MCFX2 commented Feb 23, 2018

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.

@protinam
Copy link
Member Author

@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?

@alextreece
Copy link

alextreece commented Feb 23, 2018

In my view the two priorities of the fee model should be to:

  1. Provide economic incentives for application layers (exchanges) to develop on top of Wyvern and compete successfully in the market against other centralized and decentralized options
  2. Create a model where the stakeholders benefiting from holding WYV tokens are also ones likely to contribute development to the protocol or make applications on top of Wyvern

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:

  1. Set a fixed % transaction fee, payable in the compatible token of the user's choosing. We may need to limit the options here, as one possible attack could be always paying in a worthless token. The fixed % should be low enough that it doesn't deter new entrants from using Wyvern protocol.
  2. Have the fee be sent to holders of WYV based on their holdings. If an intermediary escrow step is required (for legal purposes for example), the fees can be allocated into an escrow contract and WYV holders can retrieve their funds at fixed intervals at their option (every month, every quarter, etc.)
  3. Since the DAO is currently a material holder of WYV, it will accrue funds that can be used to pay developers and whoever else for protocol upgrades (it can be exempt from the escrow if that is used). We would need to think about how spending DAO funds would impact its fee share. Perhaps the DAO always gets a fixed amount of the fee share.

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).

@MCFX2
Copy link

MCFX2 commented Feb 23, 2018

@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:

  • Increased stability for the WYV token, as it creates an immediate incentive for both speculators and developers to hold it instead of flipping it.
  • Makes it significantly easier for those who show a desire to participate in the wyvern DAO (i.e. wyvern token holders) to get the resources required to develop on the wyvern platform. One of the biggest flaws with dApps is that the end user has to pay fees, but if the dApp developer is generating enough protocol tokens passively it may encourage them to cover the fees.
  • I mentioned above that this would encourage early adoption by dApp developers, which is good.
  • I haven't looked into this yet, but I suspect it may be possible to track the price of an erc20 within a solidity contract. Assuming this is feasible we could implement this as a feature to control fees automatically and ensure fees remain reasonable.

Some serious drawbacks to this approach exist though, and are worth mentioning:

  • This creates additional development overhead, as I'm not aware of any "PoS" ERC20 tokens, paying out each block might not be viable, put maybe a simple smart contract that calculates how many blocks since you last redeemed would suffice.
  • People are already paying ethereum just because they use the ethereum blockchain. Under this system they'd be incentivized to do things in a merged and complicated way that could lead to more development overhead and trouble.
  • Wyvern is not intended to be bound to the Ethereum chain. Adding a token with advanced functionality like this will further complicate matters if a new chain is adopted.

tl;dr, non-negligible economic benefits with non-negligible technical debt

@protinam
Copy link
Member Author

protinam commented Feb 25, 2018

@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:

  • Bob submits an order to sell his CryptoKitty for x WETH.
  • Alice matches this order, paying x WETH to the Exchange contract and receiving the CryptoKitty
  • The Exchange contract sends x * 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:

  1. Sellers have no motivation to accept worthless tokens for their assets (and relayers can whitelist tokens to prevent order spam if necessary).
  2. Should DAO shareholders wish to avoid anything "like" dividends due to legal concerns, they can simply never pay dividends. Should the legal constraints change in the future, DAO shareholders could distribute funds when they do. In any case, reinvesting in protocol development seems likely to be the more desirable option in the near term.
  3. If the DAO just receives fees directly, I don't think this question applies, but correct me if I misinterpreted.

@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?

@alextreece
Copy link

alextreece commented Feb 25, 2018

@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:

  1. There is less of an immediate, direct economic incentive to improve the protocol on a per user basis. Time value of money + the voting barriers diminish value to WYV holders relative to having fee_protocol be automatically distributed
  2. Minority WYV holders' fee economics are possibly subject to manipulation by major WYV holders (preventing distributions, for example).

@protinam
Copy link
Member Author

protinam commented Feb 25, 2018

@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.

  1. 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.

  2. 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.

@dfinzer
Copy link

dfinzer commented Feb 27, 2018

I'm in support of the proposed fee changes. Thanks for writing this up @protinam

@protinam
Copy link
Member Author

protinam commented Mar 1, 2018

Tentatively implemented in ProjectWyvern/wyvern-ethereum@24c7503. I will add more testcases and contact our auditor tomorrow.

@protinam
Copy link
Member Author

protinam commented Mar 4, 2018

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).

@dfinzer
Copy link

dfinzer commented Mar 4, 2018

Sounds great, thanks @protinam !

@protinam
Copy link
Member Author

protinam commented Mar 4, 2018

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).

@dfinzer
Copy link

dfinzer commented Mar 4, 2018

@protinam Great! Have the upgraded contracts been deployed to Rinkeby?

@protinam
Copy link
Member Author

protinam commented Mar 5, 2018

@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.

@protinam
Copy link
Member Author

protinam commented Mar 5, 2018

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.

@dfinzer
Copy link

dfinzer commented Mar 6, 2018

Awesome, thanks @protinam !

@protinam
Copy link
Member Author

protinam commented Mar 6, 2018

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).

@protinam
Copy link
Member Author

protinam commented Mar 6, 2018

Fixed in ProjectWyvern/wyvern-ethereum@9e6b1e4#diff-3e95bd8b0359453cfce17b5d3901cf3bR586 and redeployed to Rinkeby. wyvern-js 2.0.1 has the updated addresses.

@protinam
Copy link
Member Author

protinam commented Mar 7, 2018

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.

@protinam
Copy link
Member Author

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).

@protinam
Copy link
Member Author

protinam commented Mar 29, 2018

Protocol upgrade passed, closing this for now.

Feel free to reopen if more fee models come to mind.

@protinam protinam changed the title Consider implementing alternative fee models (WIP) Consider implementing alternative fee models Mar 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants