upgradable wCCD token

[DOBEN]

Purpose

Implementing an upgradable wCCD token

closes #129

Changes

• Adding admin addresses that are authorized to do maintenance tasks on the smart contracts.

• Adding the capability to pause the contract by the admin address.

• Adding a pattern to deploy and link up the proxy, implementation and state contracts.

• Adding a pattern to upgrade the implementation contract.

• Adding a pattern that all wccd functions (e.g. wrap, unwrap, transfer, updateOperator, balanceOf, operatorOf, supports and tokenMetadata) have to be invoked on the proxy contract.

• Adding a pattern to store ccd funds on proxy.

• Adding events/logs to proxy

• URL can be set by admin.

Checklist

• My code follows the style of this project.
• The code compiles without warnings.
• I have performed a self-review of the changes.
• I have documented my code, in particular the intent of the
  hard-to-understand areas.
• (If necessary) I have updated the CHANGELOG.

[abizjak]

I think overall it's looking good, but I am a bit confused by the state of it.

Are the TODOs meant to be resolved now?

[Bargsteen]

Looks like a good start.
As a general comment:
Please be explicit about what you want a review of when requesting reviews for WIP PRs 😊 You could fx write it in the PR description.

[DOBEN]

I think overall it's looking good, but I am a bit confused by the state of it.

Are the TODOs meant to be resolved now?

I plan to address all of the TODOs as part of this pull request eventually. I am working on the remaining TODOs.

[abizjak]

I think this looks overall quite good, although I have not managed to get through all the details of state management between the 3 contracts. I have the following high-level comments

• It would be useful to have a more detailed overview of the 3 contract interactions, who holds what, and what the flow of data and tokens is.
• There was some discussion about the need to have the "unpause" time as opposed to just a flag of "locked/unlocked". It seemed to me like agreement was not fully reached. Could you provide rationale in comments in the code for the choice of the timestamp solution?

[abizjak]

Do we make use of this? For the hook? Perhaps the comment could be updated to clarify.

[DOBEN]

Updated the two comments about additionaData to the following:

• If the Receiver is a contract the unwrapped CCD together with these additional data bytes are sent to the function entrypoint specified in the Receiver.
• Some additional bytes are used in the OnReceivingCis2 hook. Only if the Receiver is a contract and the Receiver is not the invoker of the wrap function the receive hook function is executed.

[Bargsteen]

This looks quite good to me. I agree with Ales about the overview and unpause time. And I still think we should consider using this pattern for all the states: enum State_X { Uninitialized, Initialized { proxy_address: ContractAddress, ... }}.

[limemloh]

Instead of moving the CCD back and forth between proxy and implementation, it might be enough to just pass the information back removing the need to call back the proxy with the CCD.

[DOBEN]

The CCD amount is passed by the fallback function on the proxy to the implementation. The implementation has the logic to check how much WCCD should be minted (based on the amount of CCD it receives in the wrap function call). This logic has to be executed before the CCD can be sent to the proxy (sent to be stored on the proxy). The CCD should be stored on the proxy in case we upgrade the implementation.

Can you please explain how you can pass the information back or improve the pattern based on your above comment?

[limemloh]

I was thinking of adding the amount of tokens (just like the sender address), such that the information of how much was transferred is forwarded to the implementation, but not the actual CCDs.
But I am not sure whether it will simplify anything.

[DOBEN]

Since the fallback function will be used by all state-mutative functions, we would also append the "amount of tokens" to the "transfer", "unwrap", and "updateOperator" functions which do not need that information. I am not sure what is the best (most efficient/ simplest) way of handling it.

[Bargsteen]

I guess we should close this and thank Doris for all of her hard work proving why we really needed the native upgradability 😊

[abizjak]

Closing this, but keeping the branch alive in case we need to come back to some details here.