callAgreementWithContextfunction on the host contract (
Superfluid.sol), and pass in a few parameters:
ISuperAgreement agreementClass- the the agreement you're going to interact with (either the CFA or IDA)
bytes memory userData- any additional data you'd like to include with your function call. If you don't plan to add userData, you can pass in an empty bytes value (i.e.
"0x"). You can learn more about this parameter here.
msg.senderwhen working with Superfluid from a contract. For example, developers will occasionally want to create a function which will let an account create a flow into the contract itself. So, they'll write a function that looks like this, expecting it to create a flow into the contract from the
msg.senderof the function:
cfaV1.createFlowfunction to be the contract's address. Under the hood, even though
msg.senderon the broader
createFlowFailfunction is an external address, the msg.sender on the
cfa.createFlowcall to the Superfluid protocol is the address of the contract. The Superfluid
callAgreementfunction will see that the contract is trying to create a flow into itself, and revert.
msg.sendermisunderstanding occurs when developers want to allow external accounts to create flows directly to other accounts via a function on the contract. For example:
cfaV1.createFlowfunction will be the contract's address, not the external address calling the broader
createFlow2Receiverfunction. If you're intending to create a flow from the contract to another address, then this code is what you need (just make sure your contract has a balance of Super tokens!). However, if you're running this with the expectation that it will open a flow directly from an external account calling the function to the intended receiver, it will not work as expected.