Clarify decommission + missed deposit behavior (is it ideal?)

[franrolotti]

Goal
Validate the contract rules around decommissioning and missed deposits, and decide if the current behavior matches the intended product UX.

Questions to answer

• What exactly makes a circle “decommissioned” in the contract

• What happens if a member misses a deposit for a period?

  • Should they be allowed to deposit late? Should others continue?

[franrolotti]

A circle is decommissionable iff:

1. Time condition: the current round’s deposit window has fully passed

block.timestamp > effectiveCircleStartTime + depositInterval * (currentIndex + 1)

2. State condition: at least one member is incomplete for this round
   i.e., ∃ member with balances[id][member] < depositAmount

So decommission is explicitly the “window is over + someone didn’t deposit fully” path.

---

Why one missed deposit forces decommission (circle can’t continue)

• Withdraw requires _withdrawable(): everyone must have deposited depositAmount.
• Deposit is only allowed until the same cutoff; after that _deposit() reverts DepositWindowClosed.

So if anyone misses, then:

• the current recipient can’t withdraw,
• nobody can repair it with a late deposit,
• the only remaining escape is decommission.

---

Why decommission is unfair

Once decommission becomes possible, it creates a bad asymmetry:

• Members who already claimed earlier rounds can now stop depositing later with little downside, and the circle will decommission.
• Members who haven’t claimed yet get punished: they lose the chance to ever claim, even if they deposited correctly in earlier rounds, while earlier claimers benefit at their expense.

[franrolotti]

One possible fix to avoid forced decommission:

• Add a grace period after DepositWindowClosed where the missing member(s) can still complete their deposit (late but allowed). This should be a simple extra time window (e.g., lateDepositGracePeriod) checked in _deposit().

• If the grace period also expires and someone is still incomplete, introduce two paths:

  1. Decommission (same as today), or
  2. Continue without the non-payer(s): remove them from circleMembers[_id] (and isMember), and proceed with a reduced member count so future payouts are depositAmount * newMemberCount.

Minimal code-change sketch:

• Add uint256 lateDepositGracePeriod; (settable by owner or per-circle field).
• In _deposit(): change the window check from >= windowEnd to >= windowEnd + lateDepositGracePeriod.
• Add a new function like removeDefaulters(uint256 id) callable after windowEnd + lateDepositGracePeriod that filters circleMembers[id] to only fully-paid members for the round (or specifically removes those with balance < depositAmount). After removal, payouts automatically shrink because _withdraw() already uses circleMembers[_id].length.

@brendaasfjnso @exo404 @RonTuretzky @tbsoc wdyt?

[RonTuretzky]

A circle is decommissionable iff:

1. Time condition: the current round’s deposit window has fully passed

block.timestamp > effectiveCircleStartTime + depositInterval * (currentIndex + 1)
2. State condition: at least one member is incomplete for this round
i.e., ∃ member with balances[id][member] < depositAmount

So decommission is explicitly the “window is over + someone didn’t deposit fully” path.

Why one missed deposit forces decommission (circle can’t continue)

• Withdraw requires _withdrawable(): everyone must have deposited depositAmount.
• Deposit is only allowed until the same cutoff; after that _deposit() reverts DepositWindowClosed.

So if anyone misses, then:

• the current recipient can’t withdraw,
• nobody can repair it with a late deposit,
• the only remaining escape is decommission.

Why decommission is unfair

Once decommission becomes possible, it creates a bad asymmetry:

• Members who already claimed earlier rounds can now stop depositing later with little downside, and the circle will decommission.
• Members who haven’t claimed yet get punished: they lose the chance to ever claim, even if they deposited correctly in earlier rounds, while earlier claimers benefit at their expense.

Decomissioning is the only fair option at that point, because the second someone misses their payment, the circle becomes economically uneven, and the only game theoritically sound choice is to fully stop the circle and return everyone's money. Once someone missed their payment, no matter what, someone is gettings screwed, that is not the fault of the decomission function but a result of how saving circles work

[RonTuretzky]

One possible fix to avoid forced decommission:

• Add a grace period after DepositWindowClosed where the missing member(s) can still complete their deposit (late but allowed). This should be a simple extra time window (e.g., lateDepositGracePeriod) checked in _deposit().

• If the grace period also expires and someone is still incomplete, introduce two paths:

  1. Decommission (same as today), or
  2. Continue without the non-payer(s): remove them from circleMembers[_id] (and isMember), and proceed with a reduced member count so future payouts are depositAmount * newMemberCount.

Minimal code-change sketch:

• Add uint256 lateDepositGracePeriod; (settable by owner or per-circle field).
• In _deposit(): change the window check from >= windowEnd to >= windowEnd + lateDepositGracePeriod.
• Add a new function like removeDefaulters(uint256 id) callable after windowEnd + lateDepositGracePeriod that filters circleMembers[id] to only fully-paid members for the round (or specifically removes those with balance < depositAmount). After removal, payouts automatically shrink because _withdraw() already uses circleMembers[_id].length.

@brendaasfjnso @exo404 @RonTuretzky @tbsoc wdyt?

grace period feature is basically the same as just setting a longer interval... I don't think this jusitifies its own feature.
you cannot continue without the non payer unless everyone decides to cover the non payer at a loss. at that point the mechanism is already insolvent and continuing without the user puts everyone at a net loss.

[franrolotti]

A circle is decommissionable iff:

1. Time condition: the current round’s deposit window has fully passed

block.timestamp > effectiveCircleStartTime + depositInterval * (currentIndex + 1)
2. State condition: at least one member is incomplete for this round
i.e., ∃ member with balances[id][member] < depositAmount
So decommission is explicitly the “window is over + someone didn’t deposit fully” path.

Why one missed deposit forces decommission (circle can’t continue)

• Withdraw requires _withdrawable(): everyone must have deposited depositAmount.
• Deposit is only allowed until the same cutoff; after that _deposit() reverts DepositWindowClosed.

So if anyone misses, then:

• the current recipient can’t withdraw,
• nobody can repair it with a late deposit,
• the only remaining escape is decommission.

Why decommission is unfair

Once decommission becomes possible, it creates a bad asymmetry:

• Members who already claimed earlier rounds can now stop depositing later with little downside, and the circle will decommission.
• Members who haven’t claimed yet get punished: they lose the chance to ever claim, even if they deposited correctly in earlier rounds, while earlier claimers benefit at their expense.

Decomissioning is the only fair option at that point, because the second someone misses their payment, the circle becomes economically uneven, and the only game theoritically sound choice is to fully stop the circle and return everyone's money. Once someone missed their payment, no matter what, someone is gettings screwed, that is not the fault of the decomission function but a result of how saving circles work

Decommission doesn’t return everyone’s money overall: it can only refund what’s still in the contract (the current round’s deposits), am i right here?

Anyone who already withdrew earlier rounds keeps memberCount * depositAmount, while members who haven’t withdrawn yet may end up with nothing, even if they deposited correctly in previous rounds.

I'm pointing a possible alternative that is allowing the circle to continue after a missed payment (e.g., remove/skip the defaulter and proceed with a reduced pot like (memberCount - 1) * depositAmount.

I know that this isn't ideal, but is what I would suggest if I were on a saving circles and I didn't get the chance to claim.

[RonTuretzky]

A circle is decommissionable iff:

1. Time condition: the current round’s deposit window has fully passed

block.timestamp > effectiveCircleStartTime + depositInterval * (currentIndex + 1)
2. State condition: at least one member is incomplete for this round
i.e., ∃ member with balances[id][member] < depositAmount
So decommission is explicitly the “window is over + someone didn’t deposit fully” path.

Why one missed deposit forces decommission (circle can’t continue)

• Withdraw requires _withdrawable(): everyone must have deposited depositAmount.
• Deposit is only allowed until the same cutoff; after that _deposit() reverts DepositWindowClosed.

So if anyone misses, then:

• the current recipient can’t withdraw,
• nobody can repair it with a late deposit,
• the only remaining escape is decommission.

Why decommission is unfair

Once decommission becomes possible, it creates a bad asymmetry:

• Members who already claimed earlier rounds can now stop depositing later with little downside, and the circle will decommission.
• Members who haven’t claimed yet get punished: they lose the chance to ever claim, even if they deposited correctly in earlier rounds, while earlier claimers benefit at their expense.

Decomissioning is the only fair option at that point, because the second someone misses their payment, the circle becomes economically uneven, and the only game theoritically sound choice is to fully stop the circle and return everyone's money. Once someone missed their payment, no matter what, someone is gettings screwed, that is not the fault of the decomission function but a result of how saving circles work

Decommission doesn’t return everyone’s money overall: it can only refund what’s still in the contract (the current round’s deposits), am i right here?

Anyone who already withdrew earlier rounds keeps memberCount * depositAmount, while members who haven’t withdrawn yet may end up with nothing, even if they deposited correctly in previous rounds.

I'm pointing a possible alternative that is allowing the circle to continue after a missed payment (e.g., remove/skip the defaulter and proceed with a reduced pot like (memberCount - 1) * depositAmount.

I know that this isn't ideal, but is what I would suggest if I were on a saving circles and I didn't get the chance to claim.

Yes its imposible to return money that hasn't been paid
you could change the comission so that everyone loses the same amount of money in the decomission process but either way there's no way to prevent people from losing money and continuing the circle means that you need deposit the amount of the person who didn't deposit.

If they want to they can all take their money and start a new circle and do exactly what you're saying but I don't think we should be opinionated on recovery of defaulting circles. for v1 we are assuming that we are handling defaults the same way the irl ones handle them. I honestly dont want to spend more time on this during v1 its very very very very very out of scope and requires us to innovate on the original model.

[franrolotti]

A circle is decommissionable iff:

1. Time condition: the current round’s deposit window has fully passed

block.timestamp > effectiveCircleStartTime + depositInterval * (currentIndex + 1)
2. State condition: at least one member is incomplete for this round
i.e., ∃ member with balances[id][member] < depositAmount
So decommission is explicitly the “window is over + someone didn’t deposit fully” path.

Why one missed deposit forces decommission (circle can’t continue)

• Withdraw requires _withdrawable(): everyone must have deposited depositAmount.
• Deposit is only allowed until the same cutoff; after that _deposit() reverts DepositWindowClosed.

So if anyone misses, then:

• the current recipient can’t withdraw,
• nobody can repair it with a late deposit,
• the only remaining escape is decommission.

Why decommission is unfair

Once decommission becomes possible, it creates a bad asymmetry:

• Members who already claimed earlier rounds can now stop depositing later with little downside, and the circle will decommission.
• Members who haven’t claimed yet get punished: they lose the chance to ever claim, even if they deposited correctly in earlier rounds, while earlier claimers benefit at their expense.

Decomissioning is the only fair option at that point, because the second someone misses their payment, the circle becomes economically uneven, and the only game theoritically sound choice is to fully stop the circle and return everyone's money. Once someone missed their payment, no matter what, someone is gettings screwed, that is not the fault of the decomission function but a result of how saving circles work

Decommission doesn’t return everyone’s money overall: it can only refund what’s still in the contract (the current round’s deposits), am i right here?
Anyone who already withdrew earlier rounds keeps memberCount * depositAmount, while members who haven’t withdrawn yet may end up with nothing, even if they deposited correctly in previous rounds.
I'm pointing a possible alternative that is allowing the circle to continue after a missed payment (e.g., remove/skip the defaulter and proceed with a reduced pot like (memberCount - 1) * depositAmount.
I know that this isn't ideal, but is what I would suggest if I were on a saving circles and I didn't get the chance to claim.

Yes its imposible to return money that hasn't been paid you could change the comission so that everyone loses the same amount of money in the decomission process but either way there's no way to prevent people from losing money and continuing the circle means that you need deposit the amount of the person who didn't deposit.

If they want to they can all take their money and start a new circle and do exactly what you're saying but I don't think we should be opinionated on recovery of defaulting circles. for v1 we are assuming that we are handling defaults the same way the irl ones handle them. I honestly dont want to spend more time on this during v1 its very very very very very out of scope and requires us to innovate on the original model.

Okay, understood. That being, said, maybe we can close this issue or take it to an issue to another scope in the future.

[RonTuretzky]

we need to add a backlog status in the kanban and move it to that no need to close it