Short read: The SmartVest Specification is now live in the FROGEN protocol specifications repository. It describes the fee-calculation subsystem behind FROGEN, including the adaptive core transfer fee, the lock-percentage curve, the pool-health response, and the bounded governance parameters around the mechanism. This is the second specification in our public release schedule and another step toward making the protocol easier to inspect before audit.
Why SmartVest matters
SmartVest is one of the most important mechanisms inside the FROGEN protocol because it determines how the system responds to supply being locked and how the staking reward pool is protected over time.
Most transfer-fee systems are simple. A fixed tax is added, tokens move, and users are expected to accept it. SmartVest is different. It is not designed as a flat fee switch. It is designed as a deterministic calculator that reads the current state of the system and returns the core fee rate that should apply to a fee-bearing transfer.
That distinction matters. SmartVest does not hold tokens and it does not move tokens. Its job is narrower and more auditable: given the current lock percentage and the current health of the staking reward pool, it calculates the algorithmic core fee in basis points.
The surrounding token contract then applies the fee and routes the resulting tokens to the vault. That separation is deliberate. Smaller components are easier to reason about, easier to test, and easier to challenge.
What is going live today
The SmartVest Specification is now public in the FROGEN protocol specifications repository.
You can read it here:
It explains SmartVest as the fee-calculation subsystem of the protocol. The core fee starts from a governance-bounded ceiling when little of the supply is locked, then decays as more of the circulating supply becomes locked. The curve also keeps a small permanent minimum, so the active core-fee rate does not decay to nothing under normal operation.
There is also a second mechanism: the pool-health response. If the staking reward inventory becomes critically low, SmartVest can raise the core fee above the normal curve value, within the rules of the specification, so refill flow accelerates when the pool needs it most.
The important part is that governance cannot set the live fee directly. The curve shape, rounding rules, permanent minimum, pool-health response, and parameter bounds are fixed at deployment. Governance only has two bounded numeric dials: the core-fee ceiling and the ecosystem base fee.
That gives the protocol room to adapt without turning the mechanism into a manual control panel.
What the specification covers
The document is written for engineers, auditors, and anyone in the community who wants to understand how the fee logic works before launch. It is more technical than a community explainer, but the purpose is simple: make the intended behaviour clear enough to inspect.
| Area | What it explains |
|---|---|
| SmartVest role | The subsystem responsible for calculating the algorithmic core fee |
| Core fee | The adaptive fee component that changes with lock percentage and pool health |
| Base fee | A separate governance-bounded ecosystem fee added by the token |
| Lock percentage | The share of circulating supply treated as locked for the curve |
| Pool health | The reward inventory measure used to detect when the staking pool is stressed |
| Governance limits | The bounded parameters that can be adjusted through timelocked governance |
| Immutability | The parts of the mechanism that cannot be changed after deployment |
| Token interaction | How the token reads SmartVest and applies the resulting fee on transfers |
The specification also defines the terminology used around fees. This is important because not every fee in the system means the same thing.
The core fee is the SmartVest-calculated component. The base fee is a separate fixed component. The total fee is the sum of those two values, and the token applies that total on fee-bearing transfers.
That separation helps avoid confusion later when the system is implemented, tested, audited, and reviewed publicly.
The mechanism in plain language
SmartVest answers one question:
Given the current state of the protocol, what core fee should apply?
If the locked share of supply is low, the core fee can be higher. That creates stronger incentive alignment around staking and locking. As more supply becomes locked, the core fee decays along the fixed curve. The system becomes less fee-heavy as the lock percentage improves.
If the staking reward pool becomes unhealthy, the pool-health mechanism can lift the core fee above the normal curve value. That is not a panic button. It is a predefined response built into the specification.
In simpler terms, SmartVest is designed to do two things at once:
-
respond to how much supply is locked
-
help protect the reward pool when it becomes stressed
It is not trying to maximize fee extraction. It is trying to keep the economic loop aligned.
Why this is being published before audit
We are publishing this now for the same reason we began releasing the full specification suite publicly: review is more useful before everything is final.
A specification published only after deployment is mostly a record. A specification published before audit is an invitation to inspect the intended
behaviour while there is still time to improve it.
The community should be able to see what SmartVest is designed to do. Auditors should be able to compare the implementation against a written target. Builders should be able to trace assumptions clearly. Skeptics should be able to find the weak points, if any, and say so.
A public specification does not replace a security audit. It gives the audit a clearer target.
Updated publication schedule
SmartVest is the second release in the specification sequence. The remaining documents will continue to be published separately so each mechanism can be reviewed on its own terms.
| Specification | Target date | Status | What it covers |
|---|---|---|---|
| DynamicStaking Specification | May 30, 2026 | Live | Staking mechanism, APR math, pool health |
| SmartVest Specification | June 7, 2026 | Live | Adaptive fee curve, base fee, pool-health response |
| Carbon Reversal Plan | June 15, 2026 | Upcoming | Carbon Vault mechanism and the 10x removal target |
| GasPool Specification | June 22, 2026 | Upcoming | Sponsored gas through meta-transactions |
| Economic Mechanism Addendum | June 29, 2026 | Upcoming | Shared mathematical foundations across the contracts |
| Cross-Contract Specification | July 5, 2026 | Upcoming | System architecture and contract interactions |
Each document adds another layer of visibility. DynamicStaking explained the reward side. SmartVest now explains the fee-calculation side. The remaining specifications will continue filling in the rest of the system.
What this does and does not mean
We want to keep the meaning of this release precise.
What it means. The SmartVest mechanism is now described publicly in the FROGEN protocol specifications repository. Anyone can review the intended fee logic, the terminology, the governance limits, and the interaction between SmartVest and the token.
What it does not mean. This is not a completed third-party audit and it is not a deployment announcement. The specification describes what the mechanism is designed to do. The audit and public deployment are separate steps that will verify the implementation against the written design.
That difference matters.
A specification is the map. The audit checks the road. The deployed contract is the road everyone can finally walk on-chain.
How to engage
If you are reading the SmartVest Specification and something looks unclear, that is useful feedback. If a parameter explanation feels ambiguous, that is useful feedback. If a mechanism could be misunderstood by holders, that is useful feedback too.
-
Read the SmartVest Specification through the FROGEN GitHub repository.
-
Compare it with the DynamicStaking Specification already published.
-
Watch for the next document in the release schedule.
-
Send serious questions, edge cases, or issues that should be reviewed.
The goal is not to make the protocol look perfect.
The goal is to make the protocol inspectable.
That is how trust should be built: not by asking the pond to believe harder, but by giving everyone more to verify.
Stay tuned for more technical updates!