[sach2004]

Addressed Issues:

No related issue — follows the review request to let deployers choose both reserve-ratio settings without a 150% cap.

Screenshots/Recordings:

Not applicable. This PR changes contracts, tests and documentation.

Additional Notes:

The critical ratio must be strictly above 100% and below 200%. The deployer also chooses an initial seed-issuance ratio strictly above the critical ratio and below 200%.

The factory passes the chosen initial ratio to the one-time initialFission call. The fixed 150% target is removed. No additional storage variable is needed.

Existing fee treatment is preserved. Retained fission fees and rounding can increase the actual initialized ratio above the selected issuance ratio, so initialization also rejects an actual ratio at or below the critical ratio or at or above 200%.

The README describes these rules and removes the previous 150% restriction and creation-form justification.

Tests cover strict boundaries, successful deployment above 150%, deployer-selected initial ratios, invalid settings, retained fees and rollback. Existing fixtures use valid settings under the new strict bounds.

Validation completed locally:

• Formatting and lint with warnings denied
• Solc 0.8.30 build and deployment-size checks
• 157/157 tests passed, with 512 runs per fuzz test
• 8/8 ratio configuration tests passed, with 2,048 runs per fuzz test
• git diff --check

Factory runtime: 23,597 bytes, leaving 979 bytes below the deployment limit under the tested settings.

This replaces the earlier 150% cap proposal. It does not change peg-adjustment steps or claim recovery for every narrow operating range.

The factory deployment function gains an initial-ratio argument, and initialFission gains the corresponding argument. The frontend ABI and creation form require a matching update. The 101%–105% critical-ratio recommendation belongs in that frontend update and is not enforced by the contract.

This PR does not deploy contracts. Existing deployments are unchanged.

AI Usage Disclosure:

We encourage contributors to use AI tools responsibly when creating Pull Requests. While AI can be a valuable aid, it is essential to ensure that your contributions meet the task requirements, build successfully, include relevant tests, and pass all linters. Submissions that do not meet these standards may be closed without warning to maintain the quality and integrity of the project. Please take the time to understand the changes you are proposing and their impact. AI slop is strongly discouraged and may lead to banning and blocking. Do not spam our repos with AI slop.

Check one of the checkboxes below:

• This PR does not contain AI-generated code at all.
• This PR contains AI-generated code. I have read the AI Usage Policy and this PR complies with this policy. I have tested the code locally and I am responsible for it.

Checklist

• My PR addresses a single issue, fixes a single bug or makes a single improvement.
• My code follows the project's code style and conventions
• If applicable, I have made corresponding changes or additions to the documentation
• If applicable, I have made corresponding changes or additions to tests
• My changes generate no new warnings or errors
• I have joined the Discord server and I will share a link to this PR with the project maintainers there
• I have read the Contribution Guidelines
• Once I submit my PR, CodeRabbit AI will automatically review it and I will address CodeRabbit's comments.
• I have filled this PR template completely and carefully, and I understand that my PR may be closed without review otherwise.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 26 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: StabilityNexus/Gluon-EVM/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: f6f3dc14-5927-45f7-8e41-a13e84b8b230

📥 Commits

Reviewing files that changed from the base of the PR and between 4d603b2 and e21abe0.

📒 Files selected for processing: 13

• README.md
• src/StableCoin.sol
• src/StableCoinFactory.sol
• test/DevFeeAccounting.t.sol
• test/DevTransfer.t.sol
• test/GenericIOracleIntegration.t.sol
• test/GluonIntegration.t.sol
• test/ImmutableBeta.t.sol
• test/OrbOracleIntegration.t.sol
• test/PegFactorRegression.t.sol
• test/ReserveRatioConfiguration.t.sol
• test/TransmutationMinimumOutput.t.sol
• test/UnsignedVolumeLedger.t.sol

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Zahnentferner]

Remember to always check whether AI's comments and docs make sense.

[Zahnentferner]

I don't see anything in the solidity code requiring the critical reserve ratio to be between 100% and 150%. And that's fine. This comment in the readme appears to be wrong.

[Zahnentferner]

What is necessary is that:

• the critical reserve ratio c needs to be such that c > 1 and c < 2.
• the initial reserve ratio i needs to be such that c < i < 2.

Both c and i should be chosen by the deployer.

The frontend should recommend a c between 101% and 105%. But this recommended range does not need to be enforced by the contract.

[sach2004]

understood bruno, i will remove the 150% limit and let deployers choose both ratios, with 100% < critical < initial < 200%. i will update the README and add the 101%–105% recommendation to the frontend.

[Zahnentferner]

This entire paragraph seems to be wrong and misplaced, because this repo is only about the contract. References to the frontend's creation form are out of place.