GranEverest · ETH vault on Base

Trust & transparency

This page consolidates the canonical on-chain references for the GranEverest ETH vault on Base, together with a high-level overview of the design, testing approach and security posture. The goal is to make it easy for users, integrators and reviewers to verify how the system is configured and how it behaves.

1. Canonical on-chain references

All production contracts run on Base mainnet (chain ID 8453). Addresses below are the single source of truth for the live deployment.

GranVaultBaseETH (vault)

  • Role: main vault where users deposit ETH as collateral, borrow at 0% interest and withdraw when repaid.
  • Address: 0x0d1c…9E2d
  • Debt & collateral unit: ETH/WETH.
  • Max LTV: 70% (enforced on-chain, no liquidation engine).
  • Protocol fees: 0.25% on deposit and withdraw only; borrow and repay are fee-free (gas-only).

GranRouterBaseETH (router)

  • Role: orchestrates vault interactions where a user borrows in ETH and optionally routes the output into another supported asset in a single transaction, while respecting the same 70% LTV and fee rules.
  • Address: 0xa5b1…bDae
  • Routes are constructed so that if execution cannot complete or price protection is breached, the transaction reverts and the user’s vault position remains unchanged (only gas is paid).

Roles & control

  • Owner / guardian: 0xF5e9…8Be1, held on a hardware wallet.
  • Capabilities: pause/unpause the vault, adjust guarded parameters where applicable, and receive protocol fees. Ownership does not allow arbitrary withdrawal of user funds; each user’s collateral and debt are tracked and constrained by the contract.
  • Pause behaviour: while paused, deposit, borrow and withdraw revert; repay remains available so users can always reduce or close their debt.
  • On BaseScan, all roles and relevant parameters can be independently verified via the contract Read / Write as Proxy tabs.

2. Design summary

GranEverest focuses on a narrow, explainable design: a single ETH vault with a fixed LTV ceiling and a clear fee model. The aim is to minimise hidden complexity while still allowing flexible use in practice.

  • Single-asset vault: users deposit ETH as collateral and borrow in ETH; no cross-asset liquidation engine, no funding rates, no variable interest.
  • 0% protocol interest: debt is denominated in ETH. The amount owed does not grow over time due to protocol-set interest (network gas still applies for each transaction).
  • On-chain LTV limit: a hard 70% LTV is enforced by the vault. Withdrawals and new borrows that would exceed this limit revert.
  • Strict fee surface: 0.25% protocol fee on deposit and withdrawal only. Borrow and repay flows do not carry protocol fees.
  • Router as an optional layer: the router contract builds more complex flows (for example, borrowing and settling in another supported asset) but cannot bypass the vault’s LTV and fee rules.
  • No liquidation engine: there are no liquidation bots or auctions. Users remain responsible for managing their own risk within the 70% LTV boundary.

3. Security, testing & monitoring

The current codebase is developed with a narrow scope and several layers of testing and review. These measures reduce risk but cannot eliminate it entirely; users should size positions accordingly and avoid depositing funds they cannot afford to lose.

3.1 Hardhat tests

  • Core flows: deposit, borrow, repay, withdraw, including all fee paths.
  • Anti-loop guard: same-block borrow → deposit loops are rejected at the protocol level.
  • Edge cases around deposit/withdraw (0.25% fee) and over-repayment behaviour (excess ETH is returned to the user).
  • Events and accounting checks across multiple users and sequences, ensuring collateral and debt accounting stay consistent.

3.2 Static analysis

  • Static-analysis tooling (for example, Slither) is run regularly on the vault and supporting contracts.
  • Focus on re-entrancy, incorrect access control, unchecked external calls and arithmetic issues.
  • The current configuration reports no known high-severity issues in these runs.
  • Reports and configuration files are kept in the public repository for independent review.

3.3 Fuzzing & property tests

  • Fuzz tests exercise random sequences of deposit / borrow / repay / withdraw actions from multiple users.
  • Invariants include LTV ≤ 70%, non-negative balances, ETH/WETH conservation and correct handling of protocol fees.
  • Additional tests target the pause behaviour and anti-loop guard, ensuring they cannot be bypassed by combined calls or unusual sequences.
  • A consolidated test & analysis report (PDF) is published on the main site and linked from this page for external reviewers.

3.4 Manual review & live testing

  • Manual code review of the Solidity contracts and deployment scripts, with particular focus on access control, numerical limits, and upgrade / migration paths.
  • Scenario-based testing on Base testnet and Base mainnet with limited-size positions, validating the behaviour of deposits, borrows, repayments and withdrawals under realistic conditions.
  • Continuous comparison of on-chain data (via BaseScan) with the app UI to ensure balances, fees and limits are displayed accurately.
  • Monitoring of key metrics (TVL, active borrowers, pause status) using public explorers and internal dashboards.

3.5 Public review

  • All core contracts are verified on BaseScan, so their source code can be inspected directly at the addresses listed above.
  • The full source, deployment scripts and tests are available in the public GitHub repository, enabling independent review and reproducible deployments.
  • No formal third-party audit has been completed yet. External reviews and audits will be commissioned as TVL and usage grow.

4. Bug bounty & disclosure

Security researchers and integrators are encouraged to review the contracts and the public GitHub repository. For potential vulnerabilities, please follow a responsible disclosure process:

  • Contact the team privately at contact@graneverest.com with a clear description of the issue.
  • Avoid publishing full exploit details until there has been a reasonable chance to patch or mitigate.
  • Where possible, include reproduction steps, impacted scenarios and an assessment of severity.
  • Bug bounty terms and dedicated bounty addresses will be published progressively as the protocol matures and usage grows. Until then, disclosures are handled on a best-effort basis.

5. Roadmap & next steps

The current focus is on keeping the ETH vault stable, transparent and safe to integrate. Over time, the platform is intended to grow in depth rather than just in surface area.

  • Deeper security reviews: external security review / audit as TVL and usage justify it, including additional formal methods and runtime monitoring.
  • Expanded vault set: additional vaults built on the same principles—single-asset, explicit caps, clear LTV limits and no opaque liquidation engine.
  • On-chain yield options: optional strategies where collateral can be directed to transparent, on-chain yield sources (for example, staking) while keeping risk surfaces as narrow and auditable as possible.
  • Isolated strategies and vaults: exploration of multi-vault architectures where strategies are isolated, so that issues in one vault or strategy do not propagate to others. The objective is that failure domains remain small and predictable.
  • Operational hardening: stronger monitoring, alerting and incident playbooks, together with clearer public dashboards for vault metrics and risk indicators.

6. Contact

For security reports, integration questions or general enquiries, please reach out at contact@graneverest.com. Technical reviewers are encouraged to verify contract addresses on BaseScan and review the codebase on GitHub.