Add support for USDT as strategy denomination token

[kenkunz]

Goal

As a strategy developer, I want my strategy to use USDT as the denomination token, so that it can use the highest liquidity trading pairs when trading various assets.

Background

See discord thread.

We currently have strategies live on Polygon and Etherium blockchains, as well as one "hot wallet" strategy live on Arbitrum. We are preparing to launch a new strategy on Arbitrum, which requires trading liquidity on various tokens (list here?). Due to USDC (native) vs. USDC.e fragmentation, trading pairs that use USDT currently have much better liquidity.

All current strategies use USDC as the denomination token. This has a UX advantage since UDDC contracts support EIP-3009 TransferWithAuthorization flow. This allows users to first sign a transfer request which is then forwarded to our deposit contract, which can then be used to transfer the user's USDC from their wallet and return the tokens associated with the strategy shares in a single transaction.

Current USDT token contracts do not support EIP-3009. To use USDT, we need to follow a more traditional 2-transaction deposit flow: (i) approve; (ii) deposit. The approval step will replace the current authorization signature step, and will require a blockchain transaction to complete (including gas fees).

Open questions

1. Should we modify the flow for all strategies (including ones using USDC) or keep the TransferWithAuthorization flow for USDC?

• code path is simpler on frontend if we have a single flow; could simplify future strategy deposit contracts
• USDC flow works today and has benefits for end-user, so may be better to keep it and have two paths
• added cost of second transaction (especially on Ethereum-based strategies) may discourage some users from participating

2. In the USDT flow, after a user has completed the "approve transfer" wallet request (and transaction completes successfully), should we immediately initiate the payment wallet request, or should we display a separate "Make payment" button that the user must click to initiate the payment?

• in our current USDC TransferWithAuthorization flow, after the user signs the authorization, we immediately initiate the payment request; to keep the flows more similar, we could follow this same pattern
• some dApps that require two transactions (approve + payment) require the user to click a second button to initiate the payment transaction
  • what is more common – require user to click second button, or auto-initiate second transaction?

DRAFT Acceptance criteria

Regarding open questions above, current DRAFT acceptance criteria assume:

1. we retain TransferWithAuthorization flow for USDC strategies.
2. we display a separate "Make payment" button and require user to click to proceed with payment

USDC flow remains unchanged

Given: a strategy using USDC or USDC.e as denomination token (with support for TransferWithAuthorization)
When: a user begins a deposit
Then:

1. the deposit flow remains unchanged.

New USDT payment flow

Given: a strategy using USDT as denomination token:
When: a user begins a deposit

2. the deposit flow remains unchanged up until the "Payment" step

When: the user is on the "Payment" step:

3. the button currently labeled "Make payment" is changed to "Approve transfer"
4. upon clicking this button, the user receives a request to authorize an "approve" transaction in their wallet
   1. if the user denies / cancels this request, an appropriate error message is displayed, including a "Try again" option
   2. if the user approves this request, a progress bar appears as the transaction is being executed on-chain
      1. if the transaction fails to complete successfully, an appropriate error message is displayed
      2. if the transaction is successful, a success message is displayed, and the user may proceed with the next action
5. a button labeled "Make payment" is displayed below the approve transaction success message
6. upon clicking this button, the user receives a request to authorize a "payment" transaction in their wallet
   1. if the user denies / cancels this request, an appropriate error message is displayed, including a "Try again" option
   2. if the user approves this request, a progress bar appears as the transaction is being executed on-chain
      1. if the transaction fails to complete successfully, an appropriate error message is displayed
      2. if the transaction is successful, a success message is displayed, and the user may proceed with the next action
7. the "Next" button in the "Payment" step becomes active; the user may proceed to the "Success" step of the wizard

[kenkunz]

Terms of service contract address for Arbitrum:
0xdcd7c644a6aa72eb2f86781175b18adc30aa4f4d