Short read: We have added a GitHub link to frogen.io and begun publishing the technical specifications behind the FROGEN protocol, one contract at a time. The first specification, DynamicStaking, is live now. Five more follow on a published schedule through early July. These are engineering specifications written for public scrutiny ahead of a third-party security audit, not finished audit reports, and we think the difference matters.
Why we are doing this, and why now
A protocol asks people to trust code they usually cannot see. We would rather not ask for that kind of blind trust. So we are publishing the specifications that describe how each FROGEN contract behaves, in plain technical language, on a public repository anyone can read, fork, and challenge.
The timing is deliberate. We are publishing now, while the contracts are in integration testing and before the formal third-party audit, because that is the window where outside review is most useful. A specification published only after everything is finished invites applause. A specification published while there is still time to change things invites the harder and more valuable thing: criticism that can actually be acted on. Several improvements to these documents have already come from exactly that kind of adversarial review, and we would rather have those conversations in the open.
This is also a commitment device. By putting a dated publication schedule on the record, we are making it costly for ourselves to quietly slip. You can hold us to the dates below.
What is going live today
The DynamicStaking Specification is the first document in the repository. It describes the staking mechanism in full: how the annual percentage rate is calculated, the mathematics behind it, and the pool-health logic that keeps the reward system solvent over time. It is written so that a developer, an auditor, or a sufficiently determined holder can follow the mechanism step by step and check the math independently, without needing to read Solidity.
You can find it through the GitHub link now on frogen.io, or directly at the protocol specifications repository.
The publication schedule
Each specification is released as its own document so that each can be reviewed on its own terms. The dates below are targets. We are publishing them precisely so they can be tracked.
| Specification | Target date | What it covers |
|---|---|---|
| DynamicStaking Specification | May 30, 2026 (live) | Staking mechanism, APR math, pool health |
| SmartVest Specification | June 7, 2026 | The dynamic transfer-fee curve and how fees are redistributed |
| Carbon Reversal Plan | June 15, 2026 | The Carbon Vault mechanism and the 10x offset math |
| GasPool Specification | June 22, 2026 | Sponsored gas through meta-transactions |
| Economic Mechanism Addendum | June 29, 2026 | The mathematical foundations shared across the contracts |
| Cross-Contract Specification | July 5, 2026 | System architecture and how the contracts interact |
A short preview of the two that matter most to day-to-day holders:
- SmartVest governs the transfer fee. Rather than a flat tax, the fee follows a curve: it starts higher when little of the supply is locked and decays as more is locked, with a small permanent floor and a separate response that lifts the fee when the staking reward pool runs low. The spec lays out the formulas, the bounds, and the edge cases.
- The Cross-Contract Specification, last in the sequence, ties everything together: how the token, the fee calculator, the staking system, and the supporting contracts read from and depend on one another. We put it last on purpose, so it can reference specifications that are already public rather than ones still in draft.
What this does and does not mean
We want to be precise about what publishing a specification represents, because overstating it would defeat the point.
What it means. The behaviour of each contract is now described in public, in detail, before launch. Anyone can read the intended mechanism, check the mathematics, compare documents against one another, and tell us where we are wrong. The specifications are explicit about their own trust assumptions, including where a contract is immutable, where governance can adjust a bounded parameter, and what the highest-bar remediation path would be if a defect were found.
What it does not mean. A published specification is not an audit, and it is not a guarantee. Each document is marked as a canonical specification still subject to refinement through audit cycles. A formal third-party security audit is a separate step that comes after. Some values, such as certain launch parameters, are shown as to-be-confirmed at deployment rather than guessed at. Reading a specification tells you what a contract is designed to do; it does not by itself prove the deployed code does exactly that. That proof is what the audit and the public, verifiable deployment are for.
We would rather you trust the process you can watch than a claim you have to take on faith.
How to engage
If you read these documents and find an error, an ambiguity, or a claim that does not hold up, that is the most useful thing you can send us. The specifications exist to be checked.
- Read the specifications through the GitHub link on frogen.io.
- Open an issue on the repository if you find something that needs fixing.
- Watch this space as each document on the schedule above goes live.
GitHub: https://github.com/frogen-protocol
We will report progress against the schedule as we go, including any date that moves and why.
Stay tuned for more technical updates!