-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NFT dtp agreements #221
NFT dtp agreements #221
Conversation
…/nft-dtp-agreements
bytes32 _did, | ||
address _lockAddress, | ||
uint256 _amount, | ||
address _receiver, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NFT Marked Condtion and interface looks the same than existing NFT condition and interface but without the receiver
parameter. So to avoid code duplication, if receiver
is necessary in the new flows, can we refactor the existing templates to include the receiver
parameter? And if it's not used in some templates/flows we pass address(0)?
* can release reward if lock and release conditions | ||
* are fulfilled. | ||
*/ | ||
contract MultiEscrowPaymentCondition is Reward, Common, ReentrancyGuardUpgradeable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't be possible here to implement using the existing EscrowPaymentCondition
with a new method to fulfill an array of releaseConditons? Also we could keep compatibility exposing a hash/fulfill where one releaseCondition becomes an array of releaseConditions that we pass to the implementation using the array.
…ntracts into feat/nft-dtp-agreements
Description
Added three new agreement templates
TODO:
Is this PR related with an open issue?
Related to Issue #218
Types of changes
Checklist:
Funny gif