Exchange: Add functionality for payments (e.g. P2P).

[SpicyLemon]

Summary

Create a way for one account to send/trade with another specific account where the funds are held in the sender's account until accepted by the receiver or canceled by either.

Problem Definition

As an asset owner, I want to be able to sell assets to a specific person at a specific price but keep the assets in my account until the sale is completed.

As a yield distributor, I want to initiate a peer-to-peer payment to an account where the recipient must accept the funds, but the funds stay in my account until that time.

As a validator and/or hash stakeholder, I want to be able to collect extra fees on these.

Proposal

See https://hackmd.io/@dwedul/rk1rhnCcp#The-plan for details.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[SpicyLemon]

I'm tempted to use "Seller" and "Buyer" instead of "Sender" and "Recipient", but in some cases (e.g. zero recipient assets), there isn't really a "buyer". It also gets a bit fuzzy when you consider the case where A creates a ConditionalSend to B, but B wants to counter-offer, so cancels that one and creates a new one. This case is also why I'm not exactly sure how the existing settlement fee setups should be applied.

[SpicyLemon]

Alternatively, instead of needing a market for these, we might add some settings to the exchange module that define the fees to charge for conditional sends.

If these need to go through a market, I feel like there should be a way to set up a market to only allow conditional sends. I also feel like a conditional send should only be creatable if the market is accepting orders and allows self-settlement, but the self-settlement flag might not be accurate, so maybe a new flag for allow-conditional-sends or something. I'd need to work through various scenarios to actually identify the best way to define such a setting.

[SpicyLemon]

Also, it might be better to take out the Recipient Fees field, and move that field to the message for accepting a conditional send.

[SpicyLemon]

I decided I like the name "Payment" for these instead of "Conditional Send."

I wasn't a fan of "Conditional Send" because it's a bit clunky and long. It also doesn't say to me, "this can be used to facilitate trades" as well as I'd like.

What I like about "Payment":

1. It's concise and familiar.
2. When the module name is included (i.e. "exchange payment") it's clearer that funds can go both ways. Even on its own, it hints at the two-way capability since a payment is usually for something.
3. It also makes sense for the one-way versions, e.g. "P2P Payment" and "Payment Request".

[SpicyLemon]

Here's a hackmd where I've worked through the details: https://hackmd.io/@dwedul/rk1rhnCcp

[iramiller]

Here's a hackmd where I've worked through the details: https://hackmd.io/@dwedul/rk1rhnCcp
(Commenting here since I don’t have permission to comment there)
Does this need to support scopes?

It will indirectly when scopes are properly supported as coins with a supply of 1. (This is a future bank module enhancement for nfts)