-
Notifications
You must be signed in to change notification settings - Fork 119
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
(DvA) Add DvA Transfer Manager #171
Conversation
|
||
// solhint-disable-next-line code-complexity | ||
function _approveTransfer(bytes32 transferID, Transfer storage transfer) internal returns (bool allApproved) { | ||
bool approved = false; |
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.
I'm not sure I could implement this logic in a simpler way. I'm open to any suggestions 😅
We store the list of approvers in the |
Not sure, I'll ask 👍 |
…he transfer is initiated
Hey @Nakasar, And when an approver approves a transfer after the criteria change, it needs to reset the approval state and return. S/he needs to call the approve function one more time to be able to approve. This is the expected behavior. |
…ions/T-REX into dva-transfer-manager
CHANGELOG.md
Outdated
@@ -16,6 +16,7 @@ All notable changes to this project will be documented in this file. | |||
constant variable to be declared. | |||
- Add `function isPlugAndPlay() external pure returns (bool)` to `IModule`. Compliance modules now require this function to be declared. It indicates whether the compliance can be bound without any presetting. | |||
- Add `function canComplianceBind(address _compliance) external view returns (bool)` to `IModule`. Compliance modules now require this function to be declared. If it returns false, it means some presets must be made before compliance can bind to the module. | |||
- DVATransferManager contract |
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.
would be good to describe the contract a bit here
contracts/DVA/DVATransferManager.sol
Outdated
} | ||
|
||
struct ApprovalCriteria { | ||
address tokenAddress; |
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.
address tokenAddress; |
As the ApprovalCriteria is given by a mapping(address => ApprovalCriteria)
with address
being the token address, it feels redundant to have it in the struct
contracts/DVA/DVATransferManager.sol
Outdated
* DVATransferManager must be an agent of the given token | ||
* emits an `ApprovalCriteriaModified` event | ||
*/ | ||
function modifyApprovalCriteria( |
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.
not sure about the naming here. modify
implies that the ApprovalCriteria
already exists, while in fact this function is also used to set initial ApprovalCriteria
In this case i guess the terminology setApprovalCriteria
would be more relevant
contracts/DVA/DVATransferManager.sol
Outdated
* @param includeAgentApprover determines whether the agent is included in the approver list | ||
* @param sequentialApproval determines whether approvals must be sequential | ||
* @param additionalApprovers are the addresses of additional approvers to be added to the approver list | ||
* Only an agent of a token can call this function |
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.
Agents on T-REX are in charge of operational tasks such as minting, burning, freezing, recovering lost tokens, etc. Here i believe the task is more related to the general transfer rules management for the token, which is under the owner scope in T-REX, in the same way that it is the token owner that specifies the compliance rules, or the eligibility rules, i believe it should be the Token owner specifying the approval criterias in DvA
contracts/DVA/DVATransferManager.sol
Outdated
* @param amount is the transfer amount | ||
* Approval criteria must be preset for the given token address | ||
* Receiver must be verified for the given token address | ||
* emits a `TransferInitiated` event |
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.
could add that the sender should give allowance first to the DvA smart contract address on the token contract, and that this allowance needs to be at least amount
|
||
IToken token = IToken(tokenAddress); | ||
if (!token.identityRegistry().isVerified(recipient)) { | ||
revert RecipientIsNotVerified(tokenAddress, recipient); |
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.
maybe would make sense to also test canTransfer
with address _from
being the DvA address and _to
the recipient for amount
, to be sure that after approval, the transfer will be allowed to happen. Or maybe this is a bit overkill...
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.
We already have an e2e test for that (checks the balances as well)
https://github.com/TokenySolutions/T-REX/pull/171/files#diff-5bfef1f607b3b2d5e5aa8f381f378a17e93375f7cce6bfd63dad06dc354c5b97R511
contracts/DVA/DVATransferManager.sol
Outdated
|
||
bool transferSent = token.transferFrom(msg.sender, address(this), amount); | ||
if (!transferSent) { | ||
revert TokenTransferFailed(tokenAddress, msg.sender, address(this), amount); |
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.
I don't think this code is reachable. When transfer fails it reverts, therefore i don't see how we could get the case where transferFrom
returns false
and reach this code. I would therefore remove this part and the custom error that goes with it
contracts/DVA/DVATransferManager.sol
Outdated
function _transferTokensTo(Transfer memory transfer, address to) internal { | ||
bool transferSent = IToken(transfer.tokenAddress).transfer(to, transfer.amount); | ||
if (!transferSent) { | ||
revert TokenTransferFailed(transfer.tokenAddress, address(this), transfer.sender, transfer.amount); |
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.
same remark as for transferFrom
above, this code is not reachable, transfer
either returns true
or reverts. therefore it is not possible to get access to this case in which the transfer returns false
and reach this custom error
@aliarbak we should also have an implementation contract for DvA |
all done @Joachim-Lebrun |
No description provided.