Skip to content

add adjust linear amplification logic #86

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

Luivatra
Copy link

This pull request introduces a new feature for managing the linear amplification factor in stable pools. The changes include adding a new field to the StablePoolDatum type.

Feature Enhancements for Stable Pools:

  • Added linear_amplification_manager field: The StablePoolDatum type now includes an optional linear_amplification_manager field, which represents a multisig condition for updating the linear amplification factor.
  • New redeemer for amplification adjustment: The ManageRedeemer type now includes an AdjustLinearAmplification variant to enable updates to the linear amplification factor.
  • Validation logic for amplification updates: Added logic to enforce multisig approval when adjusting the linear amplification factor, ensuring the pool's assets and fees remain consistent.

Updates to Asset Reserves and Validation:

  • New function pool_input_to_asset_reserves: Introduced a function to compute asset reserves while accounting for protocol fees and ADA-specific adjustments.

@Luivatra Luivatra marked this pull request as ready for review June 17, 2025 12:00
@Luivatra
Copy link
Author

I am not sure we can define a sanity range for a, I assume it being a positive number is the least we should check, but is there an upper limit?

)

// Make sure the linear amplification is in the sane range
expect linear_amplification > 0 && linear_amplification <= 10000
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the upper bound likely needs to be much higher, and i'm not sure we should even have an upper bound 🤔

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, will remove that upper bound

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just make sure to ask the auditors if they feel we should set an upper bound

@@ -378,6 +378,7 @@ fn scoop(options: ScoopTestOptions) {
options.edit_initial_sum_invariant,
2000000000000000000000,
),
linear_amplification_manager: None,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should add one test exercising this branch, ideally

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using this as test bed for a property based test in the next PR, so will be covered by that.

@Luivatra
Copy link
Author

Closing this to use #87 instead.

@Luivatra Luivatra closed this Jul 16, 2025
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.

2 participants