Secure voting

No Epochs

The protocol does not use epochs.

Voting power is continuous and always reflects the current state of staked tokens. There are no periodic snapshot windows, no reset cycles, and no artificial governance phases.

This design choice simplifies the system and aligns governance directly with live capital allocation.

By removing epochs, the protocol eliminates several common issues found in snapshot based systems:

Snapshot Timing Manipulation

In epoch based systems, participants may attempt to time their actions around snapshot blocks to gain temporary advantage.

Since this protocol does not rely on discrete snapshots for ranking, influence is determined continuously by total staked capital.

There are no snapshot windows to exploit.

Epoch Farming

Epoch based reward systems can create opportunities for strategic short term participation, where users enter only during reward windows and exit immediately after.

Because this protocol uses continuous staking and daily revenue routing, influence must be maintained over time to remain competitive.

Artificial Resets

Traditional governance systems often reset voting weight at fixed intervals.

This protocol does not reset stake or influence. Capital remains active until voluntarily withdrawn or reallocated.

The result is a persistent and stable capital allocation environment.

Governance strength reflects real time commitment rather than historical cycle boundaries.

---

Flash Loan Considerations

The protocol’s ranking model is based on total staked tokens.

Revenue distribution occurs daily through the Tax Distributor.

Because distribution depends on the ranking at the time of execution, capital must be staked when the distribution function is called to influence revenue allocation.

Flash staking for a single block does not provide meaningful advantage under normal operation, since rewards are distributed according to sustained stake levels.

However, as with any on chain system, timing of distribution calls is important.

To maintain predictability, the distribution function is executed through controlled automation. This ensures that revenue routing occurs consistently once per day.

This operational discipline reduces opportunities for timing based manipulation and preserves the integrity of the reward cycle.

---

Reentrancy Protection

Security is a core design requirement of the protocol.

All Proposal contracts must implement reentrancy protection mechanisms to prevent recursive calls during reward claims or delegate withdrawals.

Specifically:

Use of nonReentrant Modifier

Claim functions must be protected with a nonReentrant modifier. This prevents malicious contracts from re entering claim logic during ETH transfers.

State Updates Before External Calls

All internal accounting updates must occur before any external ETH transfer.

This ensures that reward balances and reward debt variables are finalized prior to sending funds.

Following this pattern prevents double claiming and maintains correct reward calculations.

Safe ETH Transfer Patterns

All ETH transfers should use secure transfer mechanisms that minimize risk.

The contract must:

• Avoid unprotected external calls

• Prevent state inconsistencies

• Maintain strict accounting order

By adhering to these practices, the system ensures that reward distribution remains secure, predictable, and resistant to common smart contract attack vectors.

The combination of continuous governance, automated revenue routing, and robust security practices creates a stable and resilient protocol foundation.