• Sec. Infra Overview
  • Past Audits
  • Code Structure
  • Centralization
  • Exposure to other Defi
  • Recommendation
  • User Rating
  • Back
protocol logo

Velocitimeter V4

Rating

AA

Score88.00

DEX

Sec. Infrastructure Overview

Current Bug Bounty: Own
Bug Bounty Max Payout: 200.0K $
Has paid White Hats before:
Date of Last Audit: 1 Jan 1

Recent Security Incidents

  • Incident

    Amount Lost

    Date

Secured By

The Protocol is secured by

  • Name

    Type

    Website

  • logo of list item
    0

Past Audits

Number of Audits

2

Number of Vul. Found

24

Date of Last Audit

1 Jan 1

Past Audit Reports

Last codebase change was on: 1 Jan 1

Show Code Locations
Show all Vulnerabilities

Vulnerabilities reported in past audits

Code Structure

Lines of Code

0

Amount of Contracts

53

External Integrations

0

Code Summery

The main purpose of the DeFi application is to enhance liquidity provision through the introduction of veLPs, which utilize Liquidity Pool tokens instead of just VM reward tokens. This upgrade ensures that liquidity providers have a vested interest in the system, as veLPs are tied to actual liquidity rather than merely reward tokens. Additionally, the distribution of option token exercise fees has been refined, directing them solely to veLP holders and paid out in a lump sum at the end of each epoch. The emission schedule in V4 is designed to be more efficient, adjusting based on the number of active gauges to prevent wasteful early emissions, while allowing anyone to create gauges under specific conditions.

Show Dependency Graph

Code Structure & Dependency

Show Codefile metrics

Centralization

Decentralization Score

13 out of 20

Contract Upgradability

No upgradability

Frontend

Go to Dapp

Maintenance Score

2.00

Poor

Excellent

Admin / Governance Functions

Timelocks

Uses Timelocks

Pauseability

No pause

Admin Wallet

Admin can set router, update pairFactory, can withdraw stuck ERC20s

Guages can be paused

Timelock on mint

Recommendations

Any issues created by front running the distribute function on voter after epoch flip ( doing actions on the protocol after epoch flip but before the distribute call was executed ) are acceptable risk unless it' high severity Any issues related to variable blk in the Point structure (VotingEscrow) are acceptable risk unless it' high severity Any issues related to views balanceOfAtNFT,totalSupplyAt (VotingEscrow) are acceptable risk

User Rating

Avg. User Rating

No ratings

No ratings yet

Submit your review

Protocols on SCAS can't offer incentives to hide reviews

Disclaimer:

SCAS conducts security assessments on the provided source code exclusively. Conduct your own due diligence before deciding to use any info listed at this page.

In case you find any information on this report is incorrect, please fill out following form:Feedback