[ETHEREUM-CONTRACTS] Agreement Forwarder Contract(s)

[0xdavinchee]

Problem

When users use Superfluid, they need to use host.callAgreement to create/update/delete an agreement, however because of the current design, when users go to the block explorer they can decode the inputs to see 3 parameters:

• agreementClass
• callData
• userData

Most of the information is in callData, however this is just a jumble of bytes and expecting most users/developers to spend excessive time to break this down is an unrealistic expectation.

Solution & Reasoning

Create an Agreement Forwarder Contract as an intermediate step before refactoring the core contracts to adhere to a token centric contract interface. This contract forwards your calls to the agreement contracts and will provide more visibility at the block explorer level on the parameters being passed for the agreement.

Todos

• Implement an Agreement Forwarder Contract for CFAv1
• Implement an Agreement Forwarder Contract for IDAv1
• Deployment & Tests

[hellwolf]

So about the agreement forwarder, it is clear now after sync with everyone:

The use cases intended for

• User can create streams on etherscan easily using it
• Transactions created on our dashboard or through our SDK would use it by default, hence all etherscan transactions are legible.

Additional technical requirement

It was not clear (but somewhat implied) from the beginning:

• The interface of the agreement forwarder should not be "surprising", and too different from agreement library and SDK core library function name patterns.

[hellwolf]

to be tracked in: #1079