Intra-Checkpoint Netting

[wakamex]

UPDATE: Spec is in this comment #13 (comment)

Problem: right now LPs can't exit when buffers are open, measured on gross as long buffer + short buffer. this can create very large buffers that greatly limit an LP's ability to withdraw.

Solution: count the buffers on net as net_buffer = long_buffer - short_buffer and make max(0,net_buffer) the amount LPs can't withdraw. buffers are not necessary for net short positions as max_loss sufficiently backs the LP short-sold into the market (which the LP has exposure to).

Benefit: now you can do two things:

1. LPs can exit without any cost whenever the market is flat (longs = shorts)
2. LPs can exit by paying the associated cost of making their position flat

simulation / code
TO DO: let's show this in a demo, to compare vs. current approach

Step 4: math formulas that show benefit
e.g. what is the associated cost an LP must pay to exit?

[jalextowle]

The following example highlights one complication associated with the idea that a flat market releases LP's liquidity:

1. The pool is initialized by an initial LP Ike.
2. Larry opens a long.
3. Sally opens a short that exactly offsets Larry’s long.
4. Ike withdraws his entire stake.
5. Larry closes his long.
6. The term passes.
7. Sally redeems her short, getting variable interest on the face value of the bonds.

We have to sacrifice on (4), (5), or (7). The approach being used in the contract implementation sacrifices on point (4) by reducing the amount that can be withdrawn immediately by LPs to the liquidity that is not supporting open longs and shorts. We also mint long and short withdrawal shares to the LP that give them full exposure to the proceeds of future longs and short.

[wakamex]

What I picture is disallowing (5). With no liquidity in the pool, there's no one to take the other side of the trade. So he can't trade.

Your setup uses gross buffers (long and short buffers don't net) to disallow (4). That:

• decreases optionality for LPs since they can't withdraw liquidity equal to gross buffer total.
• you can never have more open positions (gross longs plus shorts) than the amount provided by LPs

It seems you favor allowing traders to close their positions in all scenarios. I don't think that needs to be a super strong criteria, since it's normal for a large position to be difficult to be unwound.

I favor creating a system that's as symmetric as possible. This allows much deeper liquidity to be facilitated, because it lowers the ask of LPs by imposing on them only the net of longs and shorts. That's the first sentence describing the goal of the system in the first document I wrote:

Goal is to create two symmetric positions that can cancel each other out: long fixed and short fixed

from map out positions (Mihai Oct16-Nov2, 4352 words) which I know we spent hours going through in detail.

If you're selling apples in a market stall, and two clients show up at the same time: one wants to buy 1 apple and the other wants to sell 1 apple, how much inventory do you need on hand? I suggest 0 instead of 2.

[jalextowle]

This sounds good to me for positions that have the same maturity date, but I'm not sure how we're supposed to net positions with different maturity dates. Take the following example:

1. The pool is initialized by an initial LP Ike.
2. Larry opens a long at t = 0.
3. Sally opens a short that exactly offsets Larry’s long at t = 0.5.
4. Ike withdraws his entire stake.
5. Larry closes his long.
6. t -> 1.5.
7. Sally redeems her short, getting variable interest on the face value of the bonds.

In this example, it's unclear how Larry and Sally can offset each other in the way that you describe above. Even if we say that Larry's bonds have matured 50% (so Sally needs half the number of shorts to offset), how is this actually supposed to work in practice? If Ike removes all of his liquidity, Larry's liquidity is the only way for us to collect sufficient interest to pay out Sally. This forces Larry into a position where he now can't redeem for an extra 0.5 terms, which reduces the fixed rate he earns.

We've moved the implementation to a system where bonds always start at the beginning of a checkpoint interval (say a day), which has big benefits for handling matured positions, the withdrawal pool, etc. This would actually make the situation better for netting because we could net within checkpoints but not across checkpoints. Still, I'm curious to hear if you've thought about this edge case.

[jalextowle]

Re-opening this as "Intra-Checkpoint Netting." As the previous discussion outlines, there are fundamental problems with inter-checkpoint netting; however, intra-checkpoint netting sidesteps these issues since the positions that are netted have overlapping terms.

[jrhea]

Spec for intra-checkpoint netting is located here:

https://hackmd.io/@delv/B1O7rGOoh