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
• Deploy SingleRequestProxy on Public Testnet (Sepolia) #1395
• Investigate 3rd party contracts to ensure the SingleRequestProxy design works for them (H, K, L, and A) #1457
• Support SingleRequestProxy in the Request Network SDK #1396
• Support SingleRequestProxy in payments-subgraph payments-subgraph#94
• Develop a new SingleRequestProxyFactory subgraph for indexing SingleRequestProxy deployment events #1458
• Add SingleRequestProxy to the docs docs.request.network#50
• Audit the SingleRequestProxyFactory and resulting NativeSingleRequestProxy and ERC20SingleRequestProxy
• Build it into Request Invoicing
• Test it with a builder

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.