receiverreceiverreceiver ), the beforeAgreementCreated and the afterAgreementCreated callback may be run. These callbacks can execute any arbitrary logic, as long as this logic fits within the rules of standard smart contract development and the rules of Super Apps (which are explained further later on in this section).afterAgreementCreated callback will open up a money stream from the app to the NFT's owner in an amount that is equal to the flowRate into the app.userData for additional functionality._host.registerAppWithKey and passing in the configWord will enable your Super App to be registered within the Superfluid host contract's Super App manifest. This will allow it to be managed under basic Superfluid governance parameters and ensure that callbacks are run as intended.APP_LEVEL_FINAL must be set as seen above for now. This parameter refers to which (and how many) callbacks will be run within a hypothetical chain of Super Apps. During the creation of the protocol, we had to decide how Super Apps would behave if a chain of callbacks could have the potential to execute in succession._NOOP designations are also important as they allow you to specify which callbacks you'd like to use in your Super App. Callbacks can run before and/or after an agreement function runs. You can have logic that runs in either or both cases, and also choose not to implement certain callbacks._NOOP pattern to prevent the callbacks you don't wish to use from running. In the case of an app that only uses the afterAgreement callbacks, you'll want to add the _NOOP flag to each callback you won't be using - in this case the beforeAgreement callbacks. This can be done like so within your configWord variable._host.registerAppWithKey(configWord) or with _host.registerAppByFactory(app, configWord).flowRateflowRateflowRateflowRate.receiver of the stream. It will also run when a stream is deleted by a user or contract that is external to the Super App. While streams can only be created or updated by the sender of the stream, a stream may be deleted by either the sender or the receiver of that stream. This means that the beforeAgreementTerminated or afterAgreementTerminated callback will run if a stream that was being sent into the Super App was deleted by the sender, or if a stream being sent from the Super App to another address was deleted by the receiver of that stream.beforeAgreement callback will be run before the call to the agreement contract will be run. For example, if there is logic inside of the beforeAgreementCreated callback within of a Super App, and a user opens a stream into that Super App contract, the logic inside of beforeAgreementCreated will run before the stream is created.afterAgreement callback will be run after the call to the agreement contract is run. For example, if there is logic inside of the afterAgreementCreated callback within a Super App, and a user opens a stream into that Super App contract, the logic inside of afterAgreementCreated will run after the stream is created.beforeAgreement callbacks is that they are view functions. So, if you want to, for example, save a variable to state in response to something that happens in the beforeAgreement callback, you should do the following:beforeAgreement callback (this returned value will be passed to the afterAgreement callback as cbdata, which we explain below)afterAgreement callbackbeforeAgreement and afterAgreement callbacksISuperToken - the protocol will pass the Super Token that's being used in the call to the constant flow agreement contract here.address - this will be the address of the Constant Flow Agreement contract on the network you're interacting with. You can find more details around these networks inside of the Superfluid network directory.agreementId - a bytes32 value that is a hash of the sender and receiver's address of the flow that was created, updated, or deleted.agreementData - the address of the sender and receiver of the flow that was created, updated, or deleted - encoded using solidity's abi.encode() built in functioncbdata - this contains data that was returned by the beforeAgreement callback if it was run prior to the calling of afterAgreement callback. Note: this is only passed to the afterAgreement callbackctx - this contains data about the call to the constant flow agreement contract itself. 'Ctx' is short for 'context' and is explained in depth inside of our tutorial on userData (which you can access inside of the ctx value).jailed to refer to a Super App that failed to comply with the set of rules encoded into the Superfluid framework. This does not mean that someone on the Superfluid team is exerting arbitrary control over your Super Apps.💡 These rules are a set of restrictions placed on Super Apps that are built into the protocol to protect users. However, these rules are not comprehensive and cannot guarantee that a SuperApp will be 100% safe. Each user should review the Super Apps they are interacting with, and developers should take care to write secure, well-tested Super App code.
afterAgreementTerminated())afterAgreementTerminated())ctx or failing to give the right ctx will result in a Jailed App.ctx, that ctx should be passed to the next called function. It will repeat this process even in the return of the callback itself.ctx and how it works you can check out our tutorial on userData.