VTVL contest - pedroais's results

Building no-code token management tools to empower web3 founders and investors, starting with token vesting.

General Information

Platform: Code4rena

Start Date: 20/09/2022

Pot Size: $30,000 USDC

Total HM: 12

Participants: 198

Period: 3 days

Judge: 0xean

Total Solo HM: 2

Id: 164

League: ETH

VTVL

Findings Distribution

Researcher Performance

Rank: 32/198

Findings: 3

Award: $246.04

🌟 Selected for report: 0

🚀 Solo Findings: 0

Findings Information

🌟 Selected for report: eierina

Also found by: 0x52, 0xA5DF, 0xdapper, ElKu, Ruhum, RustyRabbit, TomJ, obront, pauliax, pcarranzav, pedroais, rbserver

Labels

bug
duplicate
3 (High Risk)

Awards

218.0935 USDC - $218.09

External Links

Lines of code

https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L432

Vulnerability details

Impact

Unfair loss of tokens for the receiver.

Proof of Concept

Vesting is used by employers to align incentives in startups and prevent employees from leaving the company if they want to get the vested tokens. This is why a revoke function was included.

From the documentation : "However, due to the nature of vesting, e.g. employee token vesting, our vesting contract is deliberately designed to allow admin revocation in the circumstances of early employment termination (before the end of vesting period specified)."

The current implementation of revoke is flawed since it disallows the receiver from getting tokens that were already unlocked. Admin revokation in case of early termination should be possible but the employee should be able to withdraw his tokens that were already released. If the employee didn't call the withdraw() function before termination he won't be able to get these (already released) tokens.

The revoke feature should only revoke future tokens that weren't still released. This is how vestings work, if you leave early you only get what was already released but not 0.

In the revoke function make a withdraw on behalf of the receiver before revoking. In that way, he will get his released tokens and be revoked from future releases.

#0 - indijanc

2022-09-24T17:14:43Z

Duplicate of #475

#1 - 0xean

2022-09-24T18:26:46Z

closing as dupe

Awards

18.8574 USDC - $18.86

Labels

bug
QA (Quality Assurance)
sponsor disputed

External Links

Non critical issues :

Comments with development questions are left in the repo. Example : https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L266

Lack of important events when withdrawing tokens : It's a best practice to emit an event when value is transferred. https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L446

Awards

9.086 USDC - $9.09

Labels

bug
G (Gas Optimization)

External Links

Use of unchecked math at multiple instances can save a lot of gas. This doesn't propose any risks since variables are already being checked.

AVG gas before unchecked arithmetic = 3740739 AVG gas after = 3677691

Instances :

1- https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L301 This addition can't overflow since allocated amount is capped by token balance in line 295

2- https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L161 Same reason as before, capped by token balance

3- https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L381 Both operations, same reason

4- https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L166

This block could use unchecked arithmetic since :

we know _referenceTs > _claim.startTimestamp so substraction won't underflow

currentVestingDurationSecs / _claim.releaseIntervalSecs) * _claim.releaseIntervalSecs : can't overflow since it's a truncation

_claim.linearVestAmount * truncatedCurrentVestingDurationSecs / finalVestingDurationSecs : can't overflow since linear vestAmount is capped by the balance of tokens and truncatedCurrentVestingDuration is a truncation of refereceTS-startTimestamp with referenceTS = to block.timestamp in a valid call.

5- https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L429 we know final best amount is bigger so no underflow

6- https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L433 amount remaining cant be bigger than total allocation

++i cheaper than i++ Instances : 1- https://github.com/code-423n4/2022-09-vtvl/blob/f68b7f3e61dad0d873b5b5a1e8126b839afeab5f/contracts/VTVLVesting.sol#L353

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter