Wise Smart Contracts
Ramp
See the previous section on for more in depth discussion of data structures and function interfaces for Ramp contract(s). The Wise contracts are largely similar in functionality but will point out some key implementation differences.
Wise Account Registry
The biggest architectural difference is that all logic related to accounts has been removed from the Ramp contract and placed into a separate WiseAccountRegistry. The reasoning for this is to make sure that registrations persist even in the scenario where we may have to update Ramp logic.
Off-ramper Registration
In order to safely support off-ramping we needed to add a separate registerAsOffRamper function which allows us to link a Wise Tag to a Wise multi-currency account ID. The multi-currency account ID is the account that receives fiat for off-rampers and Wise Tags are how the on-ramper identifies the account they want to send funds to.
User Defined Proof Params
In order to reduce reliance on governance we have updated our deposit logic to require the off-ramper to specify the expected endpoint and host . The UI will provide the correct values and also filter out any deposits that don't match the expected endpoint and host.
Wise TLS Processors
Wise Account Registration Processor
The Account Registration Processor is responsible for validating proofs of TLS sessions as part of WiseAccountRegistry's register flow. It only has one callable function, processProof.
processProof The processProof function receives a struct from (and only from) the WiseAccountRegistry contract containing a proof that states a protocol user has an account on the specified payment network. If all validations pass an onRampId, which represents the user's payment network ID, and a wiseTagHash, which is a hash of the user's WiseTag, is returned to the Ramp. The following validations can be found in the processProof function:
The proof contains a valid signature by the off-chain verifier
The correct endpoint was notarized and verified
The correct host was notarized and verified
The proof hasn't been used previously
Wise Off-Ramper Registration Processor
The Off-Ramper Registration Processor is responsible for validating proofs of TLS sessions as part of WiseAccountRegistry's registerAsOfframper flow. It only has one callable function, processProof.
processProof The processProof function receives a struct from (and only from) the WiseAccountRegistry contract containing a proof that states a protocol user has an account on the specified payment network. If all validations pass an onRampId, which represents the user's payment network ID, and an offRampId, which is the user's Wise multi-currency account Id, is returned to the Ramp. The following validations can be found in the processProof function:
The proof contains a valid signature by the off-chain verifier
The correct endpoint was notarized and verified
The correct host was notarized and verified
Wise Send Processor
The Send Processor is responsible for validating proofs as part of Ramp's onRamp flow. It only has one callable function, processProof.
processProof The processProof function receives a struct from (and only from) the Ramp contract containing a proof that states a userA sent some amount, x, to userB. Where userA is the on-ramper and userB is the off-ramper. If all validations pass the following data is returned:
Amount the transaction was for
Timestamp of the transaction
Hash of the off-ramper's payment network ID
Hash of the on-ramper's payment network ID
intentHash of the intent being resolved by the transaction
No further validations of the above returned data are done in the Processor contract, this data is validated in the Ramp contract. However, there are still the following validations done in the processProof function:
The proof contains a valid signature by the off-chain verifier
The correct endpoint was notarized and verified
The correct host was notarized and verified
The payment status is
The proof hasn't been used previously, we nullify the transaction ID and send to the
NullifierRegistry
All transfer proofs submitted to Processors are subject to nullifcation. This means that they cannot be reused in the future in order to prevent any potential replay attacks or false registrations.
Differences From DKIM Processors
The big difference with our TLS Processors versus our DKIM processors is that these aren't validating ZK proofs but actually signatures by validators that have validated a user's notarized browser session. Further validations around the host and endpoint being queried are equivalent to our DKIM key checks. One big implementation difference for our onRamp proofs is in the interest of decentralization governance no longer sets expected values but instead the off-ramper sets the host and endpoint they expect and the on-ramper can filter in the front-end for the cases an off-ramper hasn't set a correct host or endpoint.
Last updated