Develop a PoC "SingleRequestProxy" payment smart contract that emits the paymentReference event in the receive() function

[MantisClone]

Definition of Done

• Develop smart contracts: NativeSingleRequestProxy, ERC20SingleRequestProxy, SingleRequestProxyFactory #1394
• Support SingleRequestProxy in the Request Network SDK #1396
• Add Admins Scripts for the SingleRequestProxyFactory to the SDK #1462
• Add SingleRequestProxy deployments to the payments subgraph payments-subgraph#105
• Support SingleRequestProxy in payments-subgraph payments-subgraph#94
• Add SingleRequestProxy to the docs docs.request.network#50
• Deploy SingleRequestProxyFactory on Public Testnet (Sepolia) #1395
• Deploy SingleRequestProxyFactory to Mainnets #1485
• Add Admins Scripts for the SingleRequestProxyFactory to the SDK #1462
• feat: add all data to deployment events #1487
• Deploy new Single Request Proxy Subgraphs payments-subgraph#106
• Record SingleRequestForwarder Demo Video and add to docs. docs.request.network#69
• Test it with a builder
• RequestNetwork/private-issues#135
• Audit the SingleRequestProxyFactory and resulting NativeSingleRequestProxy and ERC20SingleRequestProxy
• Build it into Request Invoicing

Motivation

1. As a Builder, I want create requests on Request Network, but use my own payment infrastructure, so I don't need to redeploy my smart contracts #1159
2. Let users pay a request from a Centralized Exchange (CEX).
3. Let users pay a request without connecting their wallet to a Dapp.

Proposed Solution

Reference: https://miro.com/app/board/uXjVM2Pf758=/?share_link_id=761216115297

Factory Contract can spawn new instances of SingleRequestProxy.

[benjlevesque]

another interesting use case for this : exchanges! They don't support smart contract calls, so cannot interract with the existing proxies.

It seems important that, once used, the "one time proxy" rejects any incoming transfer

[MantisClone]

It seems important that, once used, the "one time proxy" rejects any incoming transfer

@benjlevesque I'm not so sure. I think we'd still want to support partial payments. And since the expected amount can change (via increase/decreaseExpectedAmount) I don't think we can store the expected amount on the contract.

[MantisClone]

Despite the familiarity of the name "One Time Proxy", I don't think we should call it that, because we support partial payments meaning that a given proxy contract can be paid more than once. I prefer the name "SingleRequestProxy". I think it makes it clear that the Proxy is tied to a single request.