Support price discovery

[anajuliabit]

Discussion about #5

[zajck]

Comments directed at: https://github.com/bosonprotocol/BPIPs/blob/3736f9343987e202fe61d460960fc784ead2134f/content/BPIP-4.md

It's not explicitly stated, but I assume option 1 is meant to work with existing pools outside the protocol?
And if I understand correctly, the proposed flow is that the exchange happens outside the protocol and then in a separate transaction both parties send the exchange info to the Boson protocol?
This does not seem viable to me. Have in mind that not only that protocol needs the information about the exchange, it also needs to lock the funds in escrow. Since seller gets funds immediately after the exchange, they would need to transfer them to the protocol. They don't really have an incentive to do it, not to mention the weird UX.
Solution we are looking for should in the same tx perform the transfer and lock the appropriate amount in the escrow, without funds being transferred to the seller first. There might be a way to achieve it - instead of first making an exchange and only then notifying the protocol, buyer could call boson protocol directly (with all funds necessary), then BP calls AMM (forwards the funds), seller gets funds and BP the voucher, and in the last step BP sends voucher to buyer and transfer appropriate funds in escrow (seller must previously approve BP to do the transfers).

Option 2 (and its suboptions) seems a better direction but needs more info about the needed changes. How would new commitToOffer look like? For 2.1. I assume it needs an additional parameter that can be used in validation. For 2.2. it's less clear to me, how it should work.
In cons it's stated that it's incompatibile with AMMs. Does it mean with currently existing AMMs? Because in general I don't see a problem to design a new AMM that will work with this.

I see a option 3 just as an extension (or sort of special case) of option 2, so it should either be explained how it's it different or removed otherwise.

[anajuliabit]

In cons it's stated that it's incompatibile with AMMs. Does it mean with currently existing AMMs? Because in general I don't see a problem to design a new AMM that will work with this.

Yes, existing AMMs.

[anajuliabit]

I see a option 3 just as an extension (or sort of special case) of option 2, so it should either be explained how it's it different or removed otherwise.

Option 3 I was thinking about building or own price discovery mechanism inside protocol (like building a facet for auctions)

[zajck]

This does not seem viable to me. Have in mind that not only that protocol needs the information about the exchange, it also needs to > lock the funds in escrow. Since seller gets funds immediately after the exchange, they would need to transfer them to the protocol.
They don't really have an incentive to do it, not to mention the weird UX.

Here I was thinking only about primary sales that would works by using pre-mint vouchers (which are safe because sellers needs to send funds to cover the offer)

Still - in preminted voucher everything happens in one transaction, so we know that funds are available and revert otherwise. In this proposal, if everything happens in two transactions it's possible that price discovered externally exceeds maximum funds that can be locked (for example seller has 10 tokens in their funds availalable, but price from exchange is 1000 tokens - even if we take everything we can, 990 are still uncovered).

[anajuliabit]

I was thinking of a 2-step trade that makes the exchange status pending and only confirms when somebody sends a confirmation signed by both parties. Then only on this second transaction that we set the exchange as complete, and funds are locked on escrow. The buyer would get the voucher on the first step if we want to keep it compatible with existing AMMs and if there is no confirmation transaction (nobody submits the confirmation transaction) we could block the buyer from redeem and voucher from being transferred but I wasn't think about UX and you are right, it's a weird UX, I guess make sense to remove

[anajuliabit]

I'll remove this option from the BPIP to avoid confusion as we can still check on older commits if necessary.

[zajck]

What about this apporach:

commitToOffer and sequentialCommitToOffer has additional input field - priceDiscovery.
priceDiscovery is a struct with fields:

struct PriceDiscovery {
    uint256 price
    address validator
    bytes proof
}

Note that naming validator and proof are used really loosely here and we can discuss about a better name.
proof is in fact a calldata that is forwarded to validator. validator then verifies that buyer and seller are in agreement and does the transfer of voucher and exchangeToken in correct directions.
Protocol can also be a validator.

Overall it would works as follows:

Flow depends on how validator works. If validator always sends voucher to msg.sender (in our case Boson Protocol) a few additional steps are needed. Let's call this validator "simple". If validator allows order matching (or some similar mechanism) it means that voucher and exchange token can be exchanged directly even if msg.sender is none of them. Let's call this kind of validator "advanced"

• seller approves protocol to transfer exchange tokens. If offer is native, they must approve WETH. This will be needed in the last step.
• buyer approves
  • protocol to transfer the funds, if validator is simple
  • validator to transfer the funds, if validator is advanced
• if validator is simple: (skip these steps otherwise)
  • transfer buyers funds to protocol
  • approve validator to transfer protocol's funds
• store information about the price in the protocol
• calculate amount to go in the escrow (full price in case of initial commit; and minimal escrow in case of sequential commit)
• make a call to validator with proof as calldata. Continue only if it succeeds.
• if validator is simple:
  • transfer voucher to buyer
• if validator is advanced
  • make sure buyer is owner of the voucher, otherwise revert
• check own balance to see if validator returned some funds (possible both with simple and advanced validators)
• transfer minimal required funds from seller into the escrow

Flow should be the same, regardles of who is making a call (seller, buyer or anyone else if proof allows it).

I see some benefits:

• it enables to use existing protocols such as 0x, SeaPort so it could support whatever price discovery mechanisms they support
• if later new price discovery mechanism emerge, it should be ready without modification
• it could even support price discovery for primary sales without the neeed to premint it, although it would require to develop an AMM that works directly with offers, not ERC721 vouchers. But this would also have an advantage that boson vouchers can remain as they are (ie. multiple offers per voucher).

Still this whole apporach needs a soundness check.

[zajck]

Just one amandment:

Flow is a bit different if seller is the caller, for example when they are fulfillng a bid offer.

• seller approves protocol to transfer the voucher (potentially this can be skipped, since we could use access controller contract to give protocol privilege to transfer voucher without owner's approval).
• if validator is advanced:
  • seller approves protocol to transfer exchange tokens. If offer is native, they must approve WETH. This will be needed in the last step.
• buyer create a bid offer
  • with protocol as te seller, if validator is simple
  • normally, if validator is advanced
• buyer approves validator to do the transfer of exchange token
• if validator is simple: (skip these steps otherwise)
  • transfer seller's voucher to protocol
  • approve validator to transfer voucher from protocol
• store information about the price in the protocol
• calculate amount to go in the escrow (full price in case of initial commit; and minimal escrow in case of sequential commit)
• make a call to validator with proof as calldata. Continue only if it succeeds.
• if validator is simple:
  • keep minimum amount in the escrow and transfer the remainder to seller
• if validator is advanced
  • make sure buyer is owner of the voucher, otherwise revert
  • check own balance to see if validator returned some funds (possible both with simple and advanced validators)
  • transfer minimal required funds from seller into the escrow

Changes in flows are needed to prevent stealing of users funds with some fake offer as soon as they approve the protocol.

[anajuliabit]

if validator is simple: (skip these steps otherwise)

• transfer buyers funds to protocol
• approve validator to transfer protocol's funds

by funds do you mean exchange tokens right?

[anajuliabit]

so the transaction must always start from calling protocol and the validator is an external contract that calls a price discovery solution (like sudoswap) to make a trade on behalf of protocol (simple) or buyer/seller (advanced)?

[anajuliabit]

it could even support price discovery for primary sales without the neeed to premint it, although it would require to develop an AMM > that works directly with offers, not ERC721 vouchers. But this would also have an advantage that boson vouchers can remain as they > are (ie. multiple offers per voucher).

How would this solution work for secondary sales? From my understanding, the problem of multiple offers per voucher exists for both primary and secondary sales.

[zajck]

if validator is simple: (skip these steps otherwise)

• transfer buyers funds to protocol
• approve validator to transfer protocol's funds

by funds do you mean exchange tokens right?

yes

so the transaction must always start from calling protocol and the validator is an external contract that calls a price discovery solution (like sudoswap) to make a trade on behalf of protocol (simple) or buyer/seller (advanced)?

yes

it could even support price discovery for primary sales without the neeed to premint it, although it would require to develop an AMM > that works directly with offers, not ERC721 vouchers. But this would also have an advantage that boson vouchers can remain as they > are (ie. multiple offers per voucher).

How would this solution work for secondary sales? From my understanding, the problem of multiple offers per voucher exists for both primary and secondary sales.

Think outside the existing ERC721 solutions. If you create a new AMM you can easily make it to check that all voucher on the contract belong to the same offer. So beside address (which is generally used in those pools) this new AMM could check, whenever someone is trying to make a collection (or simply add another voucher to existing pool) to validate, that exchange is from the same offer - either calling protocol directly or we can add a method to voucher to do it.

[zajck]

Comments about BPIP-4.md@c097a58722

Option 1: Price discovery happens only off-chain

• UX bid and depositFunds option. Given that seller is not obliged to accept the offer, buyer might not want to just put the funds in the protocol and wait if the offer will be accepted or not. In case it's not they need to withdraw the funds. So probably it should be enough to only require approving ERC20 transfer and in case the offer is in native token, then they would need to approve WETH. That's how other protocol approach this. For buyer it's in a way similar as depositing to our protocol, but WETH is generally more useful than funds deposited into boson protocol.
• I see a drawback to this method - when we define EIP712 message structure it will either be something completely new or be compatible with at most one existing solution (I'm not aware of any standart that would define how order should look like).

Option 2: Price discovery can happen both on-chain/off-chain and transaction start by calling protocol
I was a bit in a rush, when I said yes here, and I didn't read the second part of your question precisely enough.

so the transaction must always start from calling protocol and the validator is an external contract that calls a price discovery solution (like sudoswap) to make a trade on behalf of protocol (simple) or buyer/seller (advanced)?

yes

So, "yes" refers to "must always start from calling protocol", but then what follows is not precisely what I had in mind in my original proposal.

validator is not another contract between boson protocol and some external price discovery solution. Since all existing solutions already make the validations, they are the validators. For example validator can directly be seaPort, 0x, sudoSwap or similar contract. So validator is not only responsible to verify the agreement, but also facilitates the exchange of voucher and exchange token. As I've written in my proposal, some validators might be able to do exchange between seller and buyer directly, while in some other cases voucher (or exchange token) will be transferred to protocol first and protocol then needs to forward it to correct recipient.

There is also another sentence that confuses me a bit - "Price could also be a parameter encoded directly on encondedFunction". What is in encodedFunciton depends solely on how validator handles it. For off-chain discovery, price will for sure be encoded, however for on-chain that's not necessary. I guess the explanation I made in previous paragraph makes this obvious.
In any case, I think price must always be a separate field in PriceDiscovery struct, since encodedFunction can be anything and protocol cannot know what part represents the price.

[zajck]

Comments about BPIP-4.md@5b8ed3b

Why is option 2 marked like it happens only on-chain? I mean, 0x and SeaPort discovery is happening off-chain and they could easily work in the proposed way. They are even listed as an example in pros.

And in option 3, which is combining options 1 and 2, I think there is confusion between "off-chain discovery" and "in protocol validation". Maybe already option 1 should be called more explicitly, i.e. it is "off-chain discovery with in-protocol validation".
So back to option 3 - there is no real need for enum PriceDiscoveryType. If validator is 0 (or I would actually prefer it to be the protocol address), this already tells whether validation happens outside the protocol (i.e. equivalent to option 2, where price discovery can happen on- and off-chain), or does it happen inside the protocol (price discovery is off-chain).

[anajuliabit]

you are right, I've confused both terms. fixed.

[thecryptofruit]

Moving to Final as no further comments and RC tag ready.