Activity

1. MantisClone

   moved this to 🆕 New in Request Network Tech Backlogon May 19, 2025
2. MantisClone

   added this to Request Network Tech Backlogon May 19, 2025
3. MantisClone

   added the

   Feature

   issue type on May 19, 2025
4. vrolland commented on May 22, 2025

   

   vrolland

   on May 22, 2025

   Last edited by vrolland

   Contributor

   More actions

   I see two/three solutions for the proxy with nonce:

   1. include the Nonce as a parameter of the payment function of the proxy
      a. straight forward version
      b. fallback nonce version
   2. Include the Nonce in the hash computing the payment reference

   Solutions

   1. Clear proxy nonce

   a. straight forward version

   The nonce is a parameter added to transferFromWithReferenceAndFee() and we check that's hash(_paymentReference, nonce) has not already been used.

       [...]
       mapping(bytes32 => bool) public history;
   
   
       function transferFromWithReferenceAndFee(
           address _tokenAddress,
           address _to,
           uint256 _amount,
           bytes calldata _paymentReference,
           uint256 _feeAmount,
           address _feeAddress
           uint16 _nonce
       )  {
           [...]
           // Check if the payment has already been done
           require(history[keccak256(abi.encodePacked(_paymentReference, _nonce))] === false, "duplicated payment");
   
           // Mark the payment as done
           history[keccak256(abi.encodePacked(_paymentReference, _nonce))] = true;
           [...]
       }
   
       [...]

   pros

   • Simple to implement
   • Payment research is simple always the same payment reference

   cons

   • Breaking change in the payment function
   • Less privacy
   • Gas costly (write in storage)

   b. fallback nonce version

   Same as before but if the nonce is not provided, we don't check the history.

       [...]
       mapping(bytes32 => bool) public history;
   
   
       function transferFromWithReferenceAndFee(
           address _tokenAddress,
           address _to,
           uint256 _amount,
           bytes calldata _paymentReference,
           uint256 _feeAmount,
           address _feeAddress
           uint16 _nonce = 0
       )  {
           [...]
           if(_nonce !== 0) {
               // Check if the payment has already been done
               require(history[keccak256(abi.encodePacked(_paymentReference, _nonce))] === false, "duplicated payment");
   
               // Mark the payment as done
               history[keccak256(abi.encodePacked(_paymentReference, _nonce))] = true;
           }
           [...]
       }
   
       [...]

   pros

   • Simple to implement
   • Payment research is simple always the same payment reference
   • Gas costly (write in storage) only if nonce is provided
   • Breaking change in the payment function only if nonce is used

   cons

   • Less privacy
   • Can add confusion

   2. Nonce in payment reference

   The nonce is added to the payment reference computation:

   last8Bytes(hash(lowercase(requestId + salt + address + nonce)))

       [...]
       mapping(bytes32 => bool) public history;
   
   
       function transferFromWithReferenceAndFee(
           address _tokenAddress,
           address _to,
           uint256 _amount,
           bytes calldata _paymentReference,
           uint256 _feeAmount,
           address _feeAddress
       )  {
           [...]
           // Check if the payment has already been done
           require(history[_paymentReference] === false, "duplicated payment");
   
           // Mark the payment as done
           history[_paymentReference] = true;
           [...]
       }
   
       [...]
   

   pros

   • Simple to implement
   • No breaking change for payment function
   • more resistant to outrun attack (@david mentionned it)
   • more privacy

   cons

   • Change must be made in the payment reference computation specs
   • Payment research more painful (need to compute the payment reference with different nonces)
   • Gas costly (write in storage)

   My conclusion

   I would recommend the 1.a solution.
   It is the simplest to implement, to use and to track the payments.

   We should keep the current version of the proxy for request with a small expected amount and add a new payment network for the high amount requests.
   This would avoid the ~1$ extra cost for the small expected amount requests.

   N.B.: It's just a humble input. 😊
5. MantisClone commented on May 28, 2025

   

   MantisClone

   on May 28, 2025

   ContributorAuthor

   More actions

   Looks good @vrolland. I agree that 1.a solution seems good, with one concern: Should the history mapping be stored in a new registry contract, separate from the payment proxy?

   Considerations:

   • What if we need to deploy a new version of an existing payment proxy? What if someone makes a partial payment on payment proxy V1 and completes the payment on payment proxy V2 (or vice versa)? A shared paymentReference/nonce registry might be helpful in this case.
   • What if a request has meta payment network? In this case, each sub-payment-network has a different paymentReference, so there's no benefit to a shared paymentReference/nonce registry.
6. MantisClone

   moved this from 🆕 New to 🎫 Backlog in Request Network Tech Backlogon Jun 3, 2025