The first thing to note is from the user’s perspective the number of steps are the same, it could even be less for the proxy example if the user needs to acquire SNT first to interact directly with the Username Registrar.
In the proxy example we use Kyber to automatically convert for the user, but this same patterns could be implemented with other exchanges such as Uniswap.
Vaults
Fees from swapping go to a vault(s) which is controlled by a governance process. The governance process is left intentionally vague because there are different mechanisms that could be used.
Governance
Given how little real world usage and experimentation there has been with onchain governance, it probably makes sense to experiment with multiple governance process. This will enable being able observe which types of governance processes lead to the best outcomes.
Governance Types
Currently my mind keeps coming to different variations of voting but it might be possible to effect change using other mechanisms. It should be possible to run these type of votes side by side and see how the outcomes differ.
Some variations:
Vanilla voting (One token one vote)
Quadratic Voting
Topic Democracy
Winner take all funding
Proportional distribution weighted by votes
(Insert your idea here)
Example vote
In the vote below, SNT holders could vote on how the accumulated funds in the vault will be directed. One of the options could be proportionately distributing the funds to the voters of the poll if the stakeholders voting feel that none of the other options are more compelling. In the case of a vote that is proportional distribution each funding options will receive the percentage of funds that it received as a percentage of votes.
This seems quite close to @iurimatias’ idea on the Status Pool for accumulating fees and funding projects. I imagine it is an iteration of that?
questions:
possible to link multiple dexs into a given project/vault? Or are we going to double/triple down on a given platform?
the previous point also works on exchange rate discovery. If we start to use things like this within the app, we need to make sure liquidity is available within these platforms for SNT.
What is the upgradability of current smart contracts to something like this? Upgrading contracts is typically not easy and can lead to some serious failures.
Can you link to the Staking Pool? If memory serves correctly I think it requires staking SNT to mint a new token which gives holders of the new token a claim on the value flows of the protocol.
There is no need to stake in this design unless the governance part requires it, perhaps in a futarchy model, but if governance is MiniMe voting then it’s similar to our current voting dapp.
I think it’s possible to use multiple dexs, https://1inch.exchange is an example of aggregation amongst multiple dexs.
The core protocol contract should not relay on the proxy, so it should not need any upgrades. The proxy components themselves might, the vault controller would be the governance contract, so a vote would be needed to change the controller.
The guiding principle is that these proxy dapps could be built by teams entirely outside of Status core. When you think of it from this perspective you can see how these dapps need to be designed and the incentive mechanisms for both the team building it and Status network stakeholders.
This is really cool, and I wouyld love to see it happen on https://dap.ps
As in an email thread, we already have a proxy contract for Kyber that is mostly ready here. I now need some design help from @maciej for the UI that will allow people to
Pick a token other than SNT to stake (currently only DAI and ETH in that contract) and
A simple pattern for how to enable DAI (if selected) before sending the transaction.
For the sake of simplicity, is there a way we could do this in dap.ps without charging any fees and therefore without entering more complex discussions about governance?
More generally, I have this small-ish project which I’d like to see happen, and I’d like to see us move everything over to Subspace (cc @rramos) instead of using MongoDB. Both projects would be good candidates for very narrow and specific liquid funding - so lmk when that is a thing and I’ll get on it
Nearly all dexs have or will have fees. In the case of Kyber, they will take a swap fee regardless, omitting the vault address means Kyber keeps 100% as opposed to splitting it with the vault. If anything you could always put in one of the other vaults when they come online. I think we can put together a simple vault contract as a general template.
The other thing to consider is how dap.ps long term can sustain it’s future maintenance? Having it’s own vault provides an additional source of funding and will allow dap.ps to choose a governance structure for the vault suitable to it’s own needs. It may turn out that the best governance structure for the vaults of dapps built on top of ens-usernames is different from dap.ps is different from sticker market, etc.
I think the governance process can allow a ballot for vote to be something like: function addBallot(string description, bytes bytecode)
Where bytecode can essentially be any arbitrary code to be executed by the vault, it should just have a permissible check to make sure the byte code can’t be destructive, such as a check to make sure opcodes like callcode, delegatecall, sstore, selfdestruct are not called.
OK, thank you for this clarity! I am happy that we go ahead with a simple vault in this case, rather than letting 100% just go to Kyber.
Perhaps we just keep the fees locked in there for now? The point about maintenance is well made, and I will chew on it further, but I’d really like to see multiple tokens being used on dap.ps within the next month or so. I think that function addBallot(string description, bytes bytecode) sounds like a good solution, but will also need to do a bit more research there. At least, it sounds simple and upgradable enough for me not to have any initial qualms about going that way in order to get multiple tokens working ASAP.
Revisiting this thread given developments since the idea was originally posted.
In today’s AMA with Vitalik a question was asked about abstracting DEXes away through the wallet and creating a SNT utility case at the same time. An idea which uses this pattern can be found here: https://discuss.status.im/t/token-swaps-in-wallet/2018
Around July of this year Yearn has emerged as a protocol which embodies this approach for several reasons:
The native token (YFI) is used only for governance.
All transactions and fees in protocol are done using stablecoins.
The YFI controlled treasury is an accumulation of tokens other than YFI.
Shows that value accrual not only can occur without using the native token for payments but creates more value when the UX is better as a result of it.
Takes convenience fees on the “Strategies”.
The last point maybe confused for rent extraction or some kind of unnecessary tax, however users can still achieve what Yearn strategies do by manually executing the same series of transactions from their wallet. In the end the reason they choose to pay Yearn 5% of the profits instead is the massive time and gas fees savings (one TX vis-a-vis a dozen weekly).
