Skip to content

QEarn: Make early unlocks principal-only full exits#935

Open
jtskxx wants to merge 13 commits into
qubic:developfrom
jtskxx:main
Open

QEarn: Make early unlocks principal-only full exits#935
jtskxx wants to merge 13 commits into
qubic:developfrom
jtskxx:main

Conversation

@jtskxx

@jtskxx jtskxx commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

This PR fixes QEarn early-unlock fairness.

Changes:

  • Sets all early-unlock reward percentages to 0.
  • Sets all early-unlock burn percentages to 0.
  • Makes any post-lock-epoch early unlock exit the full position for that lock epoch.
  • Keeps forfeited bonus in the round for remaining 52-epoch lockers.
  • Adds a regression test proving early unlockers receive principal only and cannot leave a small remainder to capture boosted rewards.

QEarn computor donations are intended to reward users who complete the 52-epoch lock period. The current early-unlock logic allows short-term lockers to extract or burn part of the shared bonus pool, reducing rewards for loyal long-term lockers. This patch keeps early liquidity available while ensuring bonus rewards belong to completed locks.

@cyber-pc

Copy link
Copy Markdown
Collaborator

@jtskxx You need to set the target branch as qubic:develop not the main branch.

@jtskxx jtskxx changed the base branch from main to develop June 29, 2026 02:37
@jtskxx

jtskxx commented Jun 29, 2026

Copy link
Copy Markdown
Contributor Author

Updated the PR so the new QEarn rules are prospective only.

The new behavior is scoped by lockedEpoch:

  • locks created before epoch 221 keep their original QEarn terms;
  • locks created from epoch 221 onward use the new early-unlock fairness rules.

This addresses the concern that existing lockers should not have their terms changed mid-lock, while keeping the proposal goal unchanged.

@jtskxx

jtskxx commented Jun 29, 2026

Copy link
Copy Markdown
Contributor Author

Updated the PR to prevent same-epoch unlocks for new post-activation locks.

This closes the case where someone could lock a large amount during an epoch, affect the round APY, then unlock before the epoch closes.

Scope remains prospective:

  • pre-activation locks keep existing behavior;
  • post-activation locks cannot unlock in their lock epoch;
  • post-activation early unlocks after that are full-exit and principal-only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants