QUESTION: What advantage does the escrow provide?

[alxo44]

Please forgive my naive take on this feature. I'm curious what the pros and cons are of the escrow workflow put in place. On one end of the spectrum, this feature could have the same workflow as the RDD contest, where siring (in this case selling or siring) can be approved for a particular address. The advantage with this approach is no known security risks and no introduction of potentially new issues. This could also save a lot of gas in the case of several rejected/expired offers, which seems likely. Finally, this aligns with the current auction infrastructure, potentially making it simpler to understand for new and existing users. Users may also be wary of frozen funds. On the other hand, the escrow implementation would give transparency on rejected offers as well as giving immediate results on accepted offers. Without seeing the final implementation of the feature, it's hard to evaluate the better solution for the long run. Thanks for listening and I'm looking forward to learning more.

[sunsetlover]

My guess is that there are two main reasons.

1. without escrow, the whole process becomes long and it adds multiple txs. If someone accepts an offer, then the bidder now has to go back and pay the money. Then the owner has to go back and approve the transfer. So one tx turned into 3.

2. escrow allows fees to be taken out that specifically discourage gaming the system, i.e. a front running attack of outbidding someone slightly which invalidates their bid, cancelling your newly created bid, and then bidding again but much lower or perhaps spamming the offer system although that one is more of a stretch depending on how small the unsuccessful offer fee is

Edit:
3) Another reason could be avoiding poor user experience. Without holding funds in escrow, there is nothing binding the bidder from fulfilling their end of the deal. If someone spams a bunch of offers but has no means or intention to actually buy a cat (or cannot buy all the cats they put offers on because they are restricted to a budget), then the owners will have a poor experience and won't want to use the system anymore.

The escrow system, combined with using ETH rather than W-ETH, allows for users to create and complete offers by sending a single transaction each. No set up transactions, no conversions of ETH into W-ETH, just a single transaction.

When users are first encountering a system, it is incredibly important UX-wise to keep the number of steps to a minimum, not confuse the user, and not make them worry about losing their funds. Other nft-offer systems require multiple setup transactions, and this is incredibly disruptive to a user's experience and defies user expectations, lowering their trust in the platform.

To avoid escrow, you would likely need to use W-ETH:

Examples of marketplaces that use W-ETH are OpenSea, Rarebits, RadarRelay, etc. W-ETH is an ERC-20 wrapper around ETH. You don't need to escrow it into a contract because W-ETH has the .approve() function, whereas native ETH does not. As such, you can call .approve() for a certain amount of W-ETH for the non-escrow-auction-contract. When an owner accepts your offer, the non-escrow-auction-contract now has the ability to withdraw the appropriate amount of W-ETH out of your wallet, because you have called .approve() ahead of time.

There are some disadvantages to using a non-escrow-based system such as OpenSea/Rarebits:

1. You must keep some of your ETH in W-ETH. Since you usually want to interact with the Ethereum ecosystem using ETH, keeping some of your funds locked up in W-ETH is cumbersome and frustrating.

2. It takes multiple transactions to set up.
   2a. You must '.approve()' the W-ETH contract to have access to your funds.
   2b. Then you must .convert() some amount of ETH into W-ETH
   2c. (You must remember to leave some ETH as ETH to use for gas costs for all further transactions.)
   2d. Then you must approve() the non-escrow-based auction to withdraw W-ETH from your account when it likes
   2e. Finally, you must submit the transaction creating your offer.

3. Since users don't escrow their funds, they can use the same W-ETH to bit on multiple items. This is very disruptive and disappointing to a seller, when the seller goes to fulfill an order and the bidder no longer has the funds to complete the offer.

There are some advantages though:

1. Since you haven't escrowed your funds, you don't have to be as concerned about the contract being compromised or drained (though you are still somewhat vulnerable because of your .approve() call).

2. W-ETH allows you to submit off-chain offers that are still cryptographically signed. Thus, you don't have to pay gas for making offers (see implementations of this in OpenSea, RadarRelay, etc.)

3. Since you don't have to escrow for any particular offer, you can make offers on multiple tokens using the same W-ETH (though this can sometimes be a disadvantage, since then a bidder can spam more offers than they have the funds to fulfill, leading to disappointed sellers).

[alxo44]

Great points. Thank you for the explanations. While I see value in this feature as it is, I still think it would be nice to offer both options (i.e. "soft" and "hard" offers, where soft is similar to the beta and hard is this final solution). For each advantage one solution has there is a counteradvantage in the other solution. Both are valuable tools for players.