tradingstrategy-ai/frontend

Include ToS hash and signature when depositing into a strategy

Closed this issue · 6 comments

Goal

As an investor making a deposit to a strategy, I want the Terms of Service acceptance message hash and signature to be included in the deposit request, so that my ToS signature may be verified and recorded.

Details

The payment_forwarder contract configured for a strategy may be one of two types:

  1. VaultUSDCPaymentForwarder – older payment forwarder that does not include isTermsOfServiceEnabled function
  2. TermedVaultUSDCPaymentForwarder – newer payment forwarder that includes isTermsOfServiceEnabled function (which returns true)

If it is the second type, then in order to proceed with payment, a valid ToS acceptance signature must have been previously recorded, or must be included in the buySharesOnBehalf… request.

Acceptance Criteria

  1. given: a strategy that does not support ToS (payment_forwarder contract isTermsOfServiceEnabled returns false or fails because the function is not supported)
    when: the user initiates the "Deposit" wizard
    then: the "Terms of Service" step is not displayed (user can deposit funds without accepting ToS)

  2. given: a strategy that supports ToS (payment_forwarder contract isTermsOfServiceEnabled returns true)
    when: the user initiates the "Deposit" wizard
    then: the "Terms of Service" step is displayed (after "Wallet balance" and before "Payment")

  3. given: a strategy that supports ToS (payment_forwarder contract isTermsOfServiceEnabled returns true)
    and: the user has already accepted the latest ToS version (ToS contract canProceed returns true)
    (a) when: the user advances to the "Terms of Service" step
          then: the UI shows the user has already accepted ToS
    (b) when: the user authorizes payment in their wallet
          then: an empty bytes32(0) value is provided for the ToS hash in the buyOnBehalf… contract call

  4. given: a strategy that supports ToS (payment_forwarder contract isTermsOfServiceEnabled returns true)
    and: the user has not already accepted the latest ToS version (ToS contract canProceed returns false)
    (a) when: the user advances to the "Terms of Service" step
          then: the UI shows the ToS acceptance UI (see #658)
    (b) when: the user authorizes payment in their wallet
          then: a real ToS acceptance hash and signature for the current ToS version are provided in the buyOnBehalf… contract call

@miohtama shared the following contracts for testing on discord:

{
  'VAULT_ADAPTER_ADDRESS': '0xB543BE4efDbF55BDbD2BA8dF6DB0B272085B0e48',
  'VAULT_ADDRESS': '0x932312e6bBa0FF0AeE0697d319138F44DB5AA3A6',
  'VAULT_ASSET_MANAGER_ADDRESS': '0xe747721f8C79A98d7A8dcE0dbd9f26B99E188137',
  'VAULT_DEPLOYMENT_BLOCK_NUMBER': 52742122,
  'VAULT_GUARD_ADDRESS': '0x04DbBDC59106B0Ac6e31fCdBd5f0ebdDFF356550',
  'VAULT_NOMINATED_OWNER_ADDRESS': '0x238B0435F69355e623d99363d58F7ba49C408491',
  'VAULT_PAYMENT_FORWARDER_ADDRESS': '0x426689B330F71015c22b2f6378C36e2a2a88829C'
}

Here's the corresponding Enzyme vault:
https://app.enzyme.finance/vault/0x932312e6bBa0FF0AeE0697d319138F44DB5AA3A6?network=polygon

@miohtama I am trying to test passing ToS signature using the payment forwarder contract provided above: 0x426689B330F71015c22b2f6378C36e2a2a88829C

That contract returns the following termsOfService contract address: 0xDCD7C644a6AA72eb2f86781175b18ADc30Aa4f4d

The ToS contract's version / hash were updated in the following transaction:
0x4dff1cecd69bc807d6c85f5996c8ed4fb7cee083581f90de86de0b4450f3cb34

Unlike this example, I don't see the acceptanceMessage copy that was used to generate the acceptance message hash. Without this, I can't generate a valid signature.

Do you know the exact acceptanceMessage that was used?

@miohtama where should frontend get the ToS contract address for a strategy?

  1. frontend can check if the payment_forwarder contract supports ToS (isTermsOfServiceEnabled ) and use the value returned from termsOfService function if it does.
  2. A new contract type could be added to on_chain_data.smart_contracts

Option #2 makes this a bit easier for frontend and doesn't require a contract call when initiating the "Deposit" flow (see acceptance criteria #1 & #2 above). But I'm guessing this may introduce some duplication in the contract config vs. just getting the correct address from payment_forwarder.

Thoughts?

  1. A new contract type could be added to on_chain_data.smart_contracts

Adding this today with couple of other new contracts.

@miohtama provided updated test contracts on discord:

ToS: 0x24bb78e70be0fc8e93ce90cc8a586e48428ff515

Vault contracts:

{
  'VAULT_ADAPTER_ADDRESS': '0x4E18DC7A285532C7398cFEd3994838a7Ca7c3Bf3',
  'VAULT_ADDRESS': '0xba1669ccd4c11067a132C2DF5b2327d4910ECc8A',
  'VAULT_ASSET_MANAGER_ADDRESS': '0xDae41eCFD352efD2676014F448bA2D761Dd82762',
  'VAULT_DEPLOYMENT_BLOCK_NUMBER': 52921048,
  'VAULT_GUARD_ADDRESS': '0x130beF56764579097CD886f39eAFbAD544459121',
  'VAULT_NOMINATED_OWNER_ADDRESS': '0x238B0435F69355e623d99363d58F7ba49C408491',
  'VAULT_PAYMENT_FORWARDER_ADDRESS': '0xc039919FD8C85DFA95EC2f5F8f4BD93B82750046'
}