Dip 3267

dip: 3267 title: Giving digitalia fees to Future Salaries author: Victor Porton (@vporton), Victor Porton porton@narod.ru Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/discussion-of-dip-3267/5343 status: Stagnant type: Standards Track category: Core created: 2021-02-13 Created for Digitalia: 2025-01-07

Simple Summary¶

Transfer a part of digitalia transfer/mining fees to Future Salaries contract

Abstract¶

Transfer a part (exact fractions - TBD) of mining/transfer fees + (probably: TBD) some minted USDS 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 Digitalia ecosystem in particular. See more in the discussion why it's crucial.
This would effectively decrease circulating USDS supply. The necessity to decrease the (circulating) USDS supply (by locking USDS 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)

The contract's source

Prior to FORK_BLOCK_NUMBER, SalaryWithDAO and DefaultDAOInterface contracts will be deployed to the network and exist at the above specified addresses.

Change the Digitalia clients to transfer at every USDS transfer and every USDS mine a fixed fraction TransferFraction of the transferred USDS and MineFraction of the mined USDS to a fixed account (decide the account number, it can be for example 0x00000000000000000000000000000000000000001 or even 0x00000000000000000000000000000000000000000 or a random account).

Change the Digitalia clients to mint MintPerPeriod USDS to the contract DonateETH every some time (e.g. the first transaction of the first block every UTC day - TBD how often).

Change the Digitalia clients to every some time (e.g. the second transaction of the first block every UTC day - TBD how often) transfer the entire USDS from this account to the contract DonateETH.

Because this DIP solves a similar problem, cancel any other DIPs that burn USDS (except gas fees) during transfers or mining. (TBD: We should transfer more USDS in this DIP than we burned accordingly older accepted DIPs, because this DIP has the additional advantages of: 1. funding common goods; 2. better aligning values of USDS 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 DIP 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 USDS (or other tokens) supply would suddenly increase when the oracle finishes. It would effectively exclude some USDS from the circulation forever.

Backwards Compatibility¶

Because transferring to the aforementioned account is neither mining nor a transaction, we get a new kinds of USDS transfers, so there may be some (expected moderate impact) troubles with applications that have made assumptions about USDS 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 digitalia that would "confiscate" control from the DAO.

See more in the discussion.

Copyright¶

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.