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:
VaultUSDCPaymentForwarder
– older payment forwarder that does not includeisTermsOfServiceEnabled
functionTermedVaultUSDCPaymentForwarder
– newer payment forwarder that includesisTermsOfServiceEnabled
function (which returnstrue
)
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
-
given: a strategy that does not support ToS (
payment_forwarder
contractisTermsOfServiceEnabled
returnsfalse
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) -
given: a strategy that supports ToS (
payment_forwarder
contractisTermsOfServiceEnabled
returnstrue
)
when: the user initiates the "Deposit" wizard
then: the "Terms of Service" step is displayed (after "Wallet balance" and before "Payment") -
given: a strategy that supports ToS (
payment_forwarder
contractisTermsOfServiceEnabled
returnstrue
)
and: the user has already accepted the latest ToS version (ToS contractcanProceed
returnstrue
)
(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 emptybytes32(0)
value is provided for the ToS hash in thebuyOnBehalf…
contract call -
given: a strategy that supports ToS (
payment_forwarder
contractisTermsOfServiceEnabled
returnstrue
)
and: the user has not already accepted the latest ToS version (ToS contractcanProceed
returnsfalse
)
(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 thebuyOnBehalf…
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 provided the following example code for checking the payment forwarder version:
@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?
frontend
can check if thepayment_forwarder
contract supports ToS (isTermsOfServiceEnabled
) and use the value returned fromtermsOfService
function if it does.- 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?
- 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'
}