Skip to content
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

Rework to the wrapped token approach #9

Merged
merged 3 commits into from
Oct 14, 2021
Merged

Conversation

k1rill-fedoseev
Copy link
Contributor

The usage flow will be the following:

  1. User approves his STAKE tokens to the SBCWrapper contract
  2. User calls SBCWrapper to swap his tokens on the newly minted SBCToken tokens
  3. User approves his SBCToken tokens to the SBCDepositContract contract
  4. User calls deposit function to make a final SBC deposit.

Steps 1 & 2 can be completed in the same transaction by using permit function or ERC677 transferAndCall standard in the STAKE token.
Steps 3 & 4 can be completed in the same transaction via the ERC677 transferAndCall function in the wrapped token contract.

So, in general, 2 transactions from user will be required.

Design considerations:

  • All 3 contracts are made upgradeable, pausable and claimable.
  • Admin multisig can add arbitrary tokens in the SBCWrapper contract.
  • Admin multisig can pause already added tokens, and reenable them back later.
  • Admin multisig can change swapping rates by using the same enableToken function.
  • When withdrawals will be needed in the future, a new implementation for the SBCWrapper will be prepared. This implementation will take care of swapping SBCToken wrapped tokens back to some of the underlying asset at a given rate.

Copy link
Contributor

@akolotov akolotov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you consider such set of changes to reduce delta of the code which was already audited?


address sender = _msgSender();

IERC20(_token).safeTransferFrom(sender, address(this), _amount);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider either to make the code safer by adding a check that the swap contract balance increased by expected amount of tokens or to extend the code with a comment that this check is not here because the contract admin must be sure that such tokens are not added for swap.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, added a comment

address _token,
uint256 _amount
) internal {
uint256 received = (_amount * tokenRate[_token]) / 1 ether;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider to make another name for the variable since although it reflects amount of tokens to receive instead of accepted tokens, it is not received yet. May it be acquired?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, sounds like a good naming to me. Thanks.

* @param _to address that will receive the locked tokens on this contract.
*/
function claimTokens(address _token, address _to) external onlyAdmin {
require(tokenStatus[_token] == TokenStatus.DISABLED, "SBCWrapper: token already swappable");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider to add a comment that the admin needs to make sure that the claimable token does not have the same storage with a token configured for the swap (the situation when different tokens addresses refers to the same storage contract).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

@akolotov akolotov merged commit c64d213 into master Oct 14, 2021
@akolotov akolotov deleted the wrapped-meta-token branch October 14, 2021 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants