Allow funds to be sent directly to domains

[area]

This is work that I've done while working on #1285 as a prerequisite for the required functionality of domains to be able to manage and exchange tokens cross-chain. For that functionality to work, I believe this functionality (or something equivalent) is required; where such an exchange is happening cross-chain, and we can't directly interrogate balances before and after the exchange on the other chain, we need a more generic way to send tokens to a domain directly in order to do the bookkeeping correctly.

Because we can't send extra data with an ERC20 token transfer that's executed by other parties, I believe the only way to do this is have a system where each domain has a unique address that can have tokens swept from it in to the corresponding domain.

Fortunately, we can (re-)use CreateX for this. By using a contract deployment salt that's a function of the colony address and domain id, we can deploy a helper contract (DomainTokenReceiver) to a fixed address for each domain (even across chains) with simple functionality to allow the sweep to occur.

I've tried to make this as transparent as possible - the deployment, upgrading, and management of the receiving contract is intended to not require any explicit interaction from the user. The experience should be that the users send tokens to a domain-specific address (which they can get from getDomainTokenReceiverAddress on ColonyNetwork) and then claim them (via claimDomainFunds on Colony) without having to check whether the contract is already deployed and/or up-to-date.

Tagging this as ready-for-review because I want feedback, but leaving as draft because I don't want it merged yet. I think the biggest question I have hanging over this implementation is what the split between the Colony and ColonyNetwork should be for the implementation but open to feedback from any and all directions.

[area]

An open question here is what should happen in terms of the colony reward pot. I think I am of the opinion that whatever it is set to should be respected.

[arrenv]

So, funds sent to the main colony address or specific domain addresses will also automatically be divided up and split amongst the respective teams set by the rewards pot? Regardless if the funds are only sent to a specific team?

[area]

split amongst the respective teams set by the rewards pot

This isn't really describing what the reward pot does. It is a single pot, and the only configuration available related to it is the fraction of incoming funds that gets put in to it, and those funds will eventually be divided among all people who have both reputation and native tokens.

It's possible this is functionality that should be removed, but until that decision is made, anything other than respecting that configuration means that it can be totally bypassed (as instead of sending funds to a colony directly, you can send funds directly to the top-level domain).

[arrenv]

This isn't really describing what the reward pot does. It is a single pot, and the only configuration available related to it is the fraction of incoming funds that gets put in to it, and those funds will eventually be divided among all people who have both reputation and native tokens.

It's possible this is functionality that should be removed, but until that decision is made, anything other than respecting that configuration means that it can be totally bypassed (as instead of sending funds to a colony directly, you can send funds directly to the top-level domain).

Haha, yeah, just crisscrossed myself with the talk of teams.

I agree with you on both. Perhaps in needs to be rethought a little or removed, but until that time, if it is configured, it seems to make sense that it can't be bypassed.

It just does not seem intuitive that it would be the case when a colony is transferring funds to itself, but, I understand that this is how this functionality would essentially work.

[kronosapiens]

Looks good overall, will probably have some more comments on my next go-round but here are my first reactions.

[area]

isContract is now being duplicated and could be refactored out.

EDIT: Sort-of on hold until Arren and Jack have thought more about what compromise is acceptable in terms of someone looping payments to create reputation and take over a colony.

[kronosapiens]

Could say that internal tokens cannot be sent directly to domains?

[area]

Could say that internal tokens cannot be sent directly to domains?

Essentially, yes, this is what I was going to implement (or, more strictly, when such tokens are claimed, they go to the root domain) but there are concerns it will render the functionality less useful than they would like.

[area]

The solution that has been decided on is to let root approve a certain amount of reputation-earning tokens to enter a domain (like ERC20). Any above the approved amount are sent to root.

The intention is that the typical in-domain swap (through the UI, at least) that would result in a domain receiving reputation-earning tokens would be a motion that requires root that makes the approval for an appropriate amount and then does the swap.

Motions being approved at the same time should be supported (or at least not break in a surprising way).

[kronosapiens]

Looks good!

Copilot reviewed 22 out of 42 changed files in this pull request and generated no suggestions.

Files not reviewed (20)

• .storage-layouts-normalized/contracts/colony/Colony.sol:Colony.json: Language not supported
• .storage-layouts-normalized/contracts/colony/ColonyArbitraryTransaction.sol:ColonyArbitraryTransaction.json: Language not supported
• .storage-layouts-normalized/contracts/colony/ColonyDomains.sol:ColonyDomains.json: Language not supported
• .storage-layouts-normalized/contracts/colony/ColonyExpenditure.sol:ColonyExpenditure.json: Language not supported
• .storage-layouts-normalized/contracts/colony/ColonyFunding.sol:ColonyFunding.json: Language not supported
• .storage-layouts-normalized/contracts/colony/ColonyRewards.sol:ColonyRewards.json: Language not supported
• .storage-layouts-normalized/contracts/colony/ColonyRoles.sol:ColonyRoles.json: Language not supported
• .storage-layouts-normalized/contracts/colony/ColonyStorage.sol:ColonyStorage.json: Language not supported
• .storage-layouts-normalized/contracts/colonyNetwork/ColonyNetwork.sol:ColonyNetwork.json: Language not supported
• .storage-layouts-normalized/contracts/colonyNetwork/ColonyNetworkAuction.sol:ColonyNetworkAuction.json: Language not supported
• .storage-layouts-normalized/contracts/colonyNetwork/ColonyNetworkDeployer.sol:ColonyNetworkDeployer.json: Language not supported
• .storage-layouts-normalized/contracts/colonyNetwork/ColonyNetworkENS.sol:ColonyNetworkENS.json: Language not supported
• .storage-layouts-normalized/contracts/colonyNetwork/ColonyNetworkExtensions.sol:ColonyNetworkExtensions.json: Language not supported
• .storage-layouts-normalized/contracts/colonyNetwork/ColonyNetworkMining.sol:ColonyNetworkMining.json: Language not supported
• .storage-layouts-normalized/contracts/colonyNetwork/ColonyNetworkSkills.sol:ColonyNetworkSkills.json: Language not supported
• .storage-layouts-normalized/contracts/colonyNetwork/ColonyNetworkStorage.sol:ColonyNetworkStorage.json: Language not supported
• .storage-layouts-normalized/contracts/common/DomainTokenReceiver.sol:DomainTokenReceiver.json: Language not supported
• .storage-layouts-normalized/contracts/testHelpers/FunctionsNotAvailableOnColony.sol:FunctionsNotAvailableOnColony.json: Language not supported
• .storage-layouts-normalized/contracts/testHelpers/NoLimitSubdomains.sol:NoLimitSubdomains.json: Language not supported
• contracts/colony/Colony.sol: Language not supported

[area]

As-is, this means domains can send money between each other arbitrarily (while paying a network free), which we have prevented in the past. I don't believe it is possible, but would like to be proven wrong.