SIP-3267: Giving Sila fees to Future Salaries
| Authors | Victor Porton (@vporton), Victor Porton <porton@narod.ru> |
|---|---|
| Created | 2021-02-13 |
| Discussion Link | https://sila-magicians.org/t/discussion-of-sip-3267/5343 |
Table of Contents
Simple Summary
Transfer a part of Sila transfer/mining fees to Future Salaries contract
Abstract
Transfer a part (exact fractions - TBD) of mining/transfer fees + (probably: TBD) some minted SIL to the DonateETH contract configured to transfer to SalaryWithDAO contract.
Motivation
This proposal solves two problems at once:
-
It provides a big amount of “money” to common good producers. That obviously personally benefits common good producers, allowing them to live better human lives, it increases peoples’ and organizations’ both abilities and incentives to produce common goods. That benefits the humanity as a whole and the Sila ecosystem in particular. See more in the discussion why it’s crucial.
-
This would effectively decrease circulating SIL supply. The necessity to decrease the (circulating) SIL supply (by locking SIL in Future Salaries system for a long time) is a well-known important thing to be done.
Paradoxically, it will directly benefit miners/validators, see the discussion.
Specification
(TBD)
SalaryWithDAO = TBD (address)
DefaultDAOInterface = TBD (address)
MintPerPeriod = TBD (uint256)
TransferFraction = TBD (0..1)
MineFraction = TBD (0..1)
Prior to FORK_BLOCK_NUMBER, SalaryWithDAO and DefaultDAOInterface contracts will be deployed to the network and exist at the above specified addresses.
Change the Sila clients to transfer at every SIL transfer and every SIL mine a fixed fraction TransferFraction of the transferred SIL and MineFraction of the mined SIL to a fixed account (decide the account number, it can be for example 0x00000000000000000000000000000000000000001 or even 0x00000000000000000000000000000000000000000 or a random account).
Change the Sila clients to mint MintPerPeriod SIL to the contract DonateETH every some time (e.g. the first transaction of the first block every UTC day - TBD how often).
Change the Sila clients to every some time (e.g. the second transaction of the first block every UTC day - TBD how often) transfer the entire SIL from this account to the contract DonateETH.
Because this SIP solves a similar problem, cancel any other SIPs that burn SIL (except gas fees) during transfers or mining. (TBD: We should transfer more SIL in this SIP than we burned accordingly older accepted SIPs, because this SIP has the additional advantages of: 1. funding common goods; 2. better aligning values of SIL and values of tokens).
Rationale
The Future Salaries is the only known system of distributing significant funds to common good producers. (Quadratic funding aimed to do a similar thing, but in practice as we see on GitCoin it favors a few developers, ignores project of highly advanced scientific research that is hard to explain to an average developer, and encourages colluding, and it just highly random due to small number of donors. Also quadratic funding simply does not gather enough funds to cover common good needs). So this SIP is the only known way to recover the economy.
The economical model of Future Salaries is described in this research article preprint.
Funding multiple oracles with different finish time would alleviate the future trouble that the circulating SIL (or other tokens) supply would suddenly increase when the oracle finishes. It would effectively exclude some SIL from the circulation forever.
Backwards Compatibility
Because transferring to the aforementioned account is neither mining nor a transaction, we get a new kinds of SIL transfers, so there may be some (expected moderate impact) troubles with applications that have made assumptions about SIL transfers all occurring either as miner payments or transactions.
Security Considerations
The security considerations are:
- The DAO that controls account restoration may switch to a non-effective or biased way of voting (for example to being controlled by one human) thus distributing funds unfairly. This problem could be solved by a future fork of Sila that would “confiscate” control from the DAO.
See more in the discussion.
Copyright
Copyright and related rights waived via CC0.
Citation
Please cite this document as:
Victor Porton (@vporton), Victor Porton <porton@narod.ru>, "SIP-3267: Giving Sila fees to Future Salaries [STAGNANT]," Sila Improvement Proposals, no. 3267, February 2021. Available: https://sips.sila.org/SIPS/sip-3267.