Security
Smart contract safety and best practices
RateVault Protocol is built with security as the highest priority. Multiple layers of protection ensure your tokens remain safe while enabling controlled liquidity.
Immutable Parameters
Vault parameters (beneficiary, daily limit, cliff) cannot be changed after creation. What you set is what you get - forever.
Whitelisted Exchanges
Only battle-tested DEX aggregators (0x, Paraswap) are allowed. No arbitrary contract calls or untrusted protocols.
Reentrancy Protection
All state-changing functions use OpenZeppelin's ReentrancyGuard to prevent reentrancy attack vectors.
No Admin Keys
No backdoors, no upgrade functions, no emergency pauses. Completely trustless operation with zero admin privileges.
Smart Contract Architecture
The protocol consists of two main contracts working together:
- RateVaultFactory
- Deploys new vaults using CREATE2 for deterministic addresses. Tracks all vaults and collects protocol fees. Factory cannot modify or access individual vaults after creation.
- RateVault (Individual Vaults)
- Each vault is an independent contract with its own parameters. Enforces daily limits, cliff periods, and beneficiary restrictions. Only the beneficiary can execute sells.
Security Features
Time-Based Limits
Daily sell limits are enforced at the block timestamp level. The contract tracks the last sell time and calculates elapsed time to determine available limit. This cannot be manipulated or bypassed.
Cliff Period Enforcement
If a cliff is set, the contract checks that current block timestamp exceeds the cliff end time. Sells revert if attempted before cliff expiration. No exceptions.
Beneficiary-Only Access
The sell function includes a beneficiary check as the first operation. If msg.sender is not the beneficiary, the transaction reverts immediately. No one else can sell your tokens.
Atomic Swaps
All swap operations are atomic - they either complete fully or revert entirely. You cannot lose tokens or ETH to a partially-failed transaction. If anything goes wrong, everything reverts.
ETH Handling
After swaps, ETH is immediately sent to the beneficiary and protocol fee recipient. No ETH stays in the vault contract. This eliminates custody risk and attack surface.
Contract Verification
All contracts are verified on Etherscan, allowing anyone to inspect the source code and verify the deployed bytecode matches.
Verified Contracts
Dependencies
RateVault uses minimal, well-audited dependencies:
- •OpenZeppelin Contracts: Industry-standard library for ReentrancyGuard, token interfaces, and safe math operations
- •0x Protocol: Audited DEX aggregator with billions in volume
- •Paraswap: Established aggregator with extensive security review
Best Practices
Recommendations for Users
- 1.Always verify vault parameters before creation - they cannot be changed
- 2.Double-check beneficiary address - a typo means permanently locked tokens
- 3.Test with small amounts first before depositing large sums
- 4.Verify vault address on Etherscan after creation
- 5.Keep your beneficiary wallet secure - it's the only way to sell
- 6.Review transaction details in your wallet before approving
Audits & Bug Bounties
Security is an ongoing priority. The protocol undergoes regular security reviews.
⚠️ Responsible Disclosure
If you discover a security vulnerability, please report it responsibly. Contact the team on GitHub or via the official channels. Do not publicly disclose until the issue is resolved.
Known Limitations
Token Compatibility: Works with standard ERC20 tokens. Rebase tokens, fee-on-transfer tokens, or tokens with non-standard implementations may not work correctly.
Immutability: Once created, vault parameters cannot be modified. Choose carefully during creation.
Beneficiary Control: Only the beneficiary can sell. If the beneficiary loses wallet access, tokens are permanently locked.
MEV Risk: Large sells may be subject to MEV extraction. Consider splitting very large sells across multiple transactions.
Questions about security?
Review the source code or reach out to the community