Flaws with Withdrawal and possible solutions

[greenlucid]

(this issue assumes a few other features and fixes have already been added) The Withdrawal mechanic works, simplistically, in the following way:

1. Alice starts withdrawing startWithdrawAccount
2. some time passes withdrawalPeriod
3. the moment the period passes, her items are Uncollateralized until she withdraws
4. Alice chooses an arbitrary amount to withdraw with withdrawAccount, closing the period and allowing her to have Included items as well. She can withdraw as long as the amount doesn't exceed her freeStake

---

The issue is that, the way incentives are currently set, and assuming Alice could possibly frontrun anyone, there is no reason whatsoever to follow this path. She could withdraw her entire freeStake "instantly" (assuming account abstraction existed), or in a very short time frame.

The core way to do it is, she submits an Item to a List she controls. This is a proof of concept:

1. Alice creates a List with requiredStake = her freeStake, that uses an Arbitrator she controls
2. Alice submits an Item to the List, and challenges it.
3. Alice wins her own challenge and gets the stake out.

---

Stake Curate main purpose is, wrong Items shouldn't be in the Lists. This instant withdrawal doesn't necessarily defeat the purpose, but it introduces a frontrun rabbit hole that is not friendly to participants.

Frontrunners can also be frontrun, and it would get challengers and item owners into this arm race.

---

Solution A: Accept this

Remove the withdrawal period feature. Now you can withdraw any stake instantly.

Solution B: Burn stakes on challenge

Note: Whenever I use burn, it could also refer to sending the portion to a Stake Curate treasury.

Reduce the reward that a challenger gets on a successful challenge, burn a given %. Reduce the reward that an item owner gets on a failed challenge, burn a given %.

• In order for this one to work, a minimum challengerStake must take place per list. Otherwise, challenging and failing the challenge (to lock the freeStake temporarily and revert a challenge) comes at no cost.

---

For both solutions, the minAmount mechanic to protect challenger from a frontrunner should be removed, and just revert when the Item is Uncollateralized.

These issues would also take place without allowing multiple Arbitrators, you would just have to create a List with extraData that costs the lowest amount possible. Just, the fee would go to the Arbitrator operator instead.

[greenlucid]

right now flash withdrawals are allowed on the contract level, in order to avoid people from engaging with these shenanigans. It just requires accepting the big burn (dispute burn) flash withdrawals could be removed, but i need to reconsider

[greenlucid]

Flash Withdrawal was removed. It cleared bytecode, and there's a design reason for it's removal. With Flash Withdrawal, snipers could guarantee a maximum loss of burnRate if they manage to frontrun the challenge reveal. Without it, and in the current design, snipers need to fight:

• Regular frontrunning war. All the following info and expenses are futile if sniper cannot get their challenge reveal to process first when it matters.
• Prepare challenge commits. Commits can be revealed within a period, so, if there's no revealed challenge to snipe within this period, the commit can solve in three different ways:
  • If they get revoked (like, timed out) they endure a burnRate.
  • If they get revealed and are successful, regular burnRate applies.
  • If they get revealed and fail, all repeatable conditions for making challenge reveals fail, will trigger a smallBurnRate.
  • If they get revealed and fail due to a non-repeatable condition, a full refund is issued, but those should only happen accidentally.
• Many commits would be needed to guarantee being able to frontrun a reveal, which will turn this strategy unfeasible long term. This means there are also continuous gas expenses to prepare commits, replicate conditions to make the reveals fail before they timeout.
• Finally, MEV bribing expenses may need to be taken into account, in order to get the frontrun to succeed when it needs to.