Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
On-chain invoices is a strong narative. That's one of the problem Metadock is trying to solve. Having 100% transparency in the payee - payer relation can be an advantage and guarantee both from a freelancer and employer perspective.
Currently, all invoices have fields to represent important data such as start & end date, status, payment method, recurrence, asset used for the payment and amount. Apart from that, users can opt to create stream-based invoices implement through the Sablier protocol.
To add an extra layer of flexibility, we're proposing to represent any invoice as an ERC-721 token. This feature gives the payee the ability to sell their invoice as they wish and benefit from instant liquidity. Other companies may want to buy invoices for financial purposes as well.
By having this representation, all invoices might have a unique set of attributes with custom values depending on the invoice scope. This unlocks new market paradigms in terms of how we trade invoices.
Implementation
By making the
InvoiceModule.sol
contract, an ERC-721 compliant collection, each time a new invoice is created, a new NFT will be minted to the initial recipient address. At the moment, the initial recipient can only be the user's instance of theContainer.sol
contract.The ERC-721
transferFrom
method has been overridden, allowing the current recipient of an invoice to transfer it to a different address. This method also transfers the Sablier stream NFT, only if the payment method is set to either linear or tranched stream (by checking thestreamId
value: non-zero means a stream is attached to the invoice). The transfer of the Sablier stream NFT is made by calling thewithdrawMaxAndTransfer
method implemented in theStreamManager.sol
contract.Caveats
An invoice payment can support 3 types of payments: transfer, linear or tranched stream. If linear or tranched stream selected, when the payment is made, a new Sablier stream is created. At this point, besides creating the stream itself, a new NFT will be minted to the recipient address.
Being minted through the
SablierV2Lockup
contract, this NFT can be independently transferred of the invoice one. In other words, if the Sablier stream NFT is transferred without also transferring the invoice NFT at the same time, the latest might become useless.task: 1051e503bcd680c5a5ecc40ed84cf861