GRANT REQUEST: Copperx

📜 Treasury Grants
21

Thank you so much for your compliments, @nraghuveera :pray:

I totally agree that this proposal will open up totally new use case for 0x Labs and ultimately forming a long term partnership with 0x. Adding Swap support is the first step towards it. We will be slowly adding this support for different features like Subscriptions - Recurring Billing, Invoicing and many more.

We are big fan of 0x and really excited to work with DAO and team.

22

As we have previously discussed in DMs, I remain skeptical that this proposal will garner community approval. The prevailing sentiment seems to resist allocating additional funds for API requests.

Nevertheless, this proposal has been under discussion for a considerable time now. If you wish to obtain a more measurable response, it could be beneficial to open a snapshot vote. This way, the community can express their stand more definitively, either in support or opposition.

23

Hi @0xSHA @nikita @ericwong @JoaoCampos89 @fig @nraghuveera @gabririgo,

I just realised that there is a confusion regarding the proposal that

We are going to implement only “0x APIs” integrations.

In reality, we have complex set of smart contracts (Payment Receiver) that handles the swap. We are fully non-custodial in the whole payment process that’s why it’s very important for manage the security and safety of funds while it’s getting transferred from payer to the business.

Let me shade some light on technical implementation.

  1. When the payer opens checkout page, we compute the payment address using create2 (link) that is a combination of byte code (byte code + constructor args with 0x quote), checkout id and receiver address. So that only receiver can access funds.
  2. There are 2 modes using which payer can send funds to this computed address. We want to allow users to feel the most safe while interacting with Copperx. Thus rather than interacting with smart contract, they will do a simple transfer of funds - ERC20 transfer function or Ethereum transaction value amount.
  • User can connect their wallet and send funds - Gas token or ERC20.
  • Or they can withdraw funds directly from exchange.
  1. We keep monitoring this address for fund transfer. As soon as we receive notification, we deploy the precomputed contract (in step 1) that performs swap and transfer to the recipient, making it non-custodial.

There are many edge cases like quote expiry, user transferring wrong ERC20 to the address or sending tokens on wrong network, refunds, handling subscription payments (in roadmap) and many more.

We can’t compromise on safety of users’ funds as it’s a payment product.

I would really love to see some action on this proposal and work with 0x team to even enable payments for 0x.org users/businesses (as we now have paid pricing in 0x).

3 Likes
24

Thanks! This is helpful

1 Like
25

Hi, thanks for the proposal.

I personally I am more keen to support core contributions to 0x protocol or that uses 0x protocol open source solutions or improve it on top, instead this proposal is using 0x Protocol via ZRX Swap API which is a proprietary product. Despite having there own merits on enable decentralized payments, based on the description of the proposal, a lot of the development is not related to build tools for ZRX protocol.

There will be tools to pass limit orders or calldata from ZRX contract directly to your solution? Is this solution to be open source to be used for others or an sdk available?

How long will be your team committeed to use ZRX protocol, 1 year 2 years? How dependent this solution is from 0x Swap prices to be viable?

Even if it just a direct integration or switch of tech from Uniswap to ZRX, a smaller grant could be possible to ensure this new use cases, but tools that are built that are not impacting directly ZRX protocol should not be cover imo.

1 Like