OpportunitiesLeaderboardAbout Cantina
Drips

Ethereum Smart Contract Audit for Drips

Cantina Security Report

Organization

@Drips

Engagement Type

Cantina Reviews

Period

-

Repositories

N/A

Researchers

0xicingdeath

high byte

Token Streaming Contract Review of Drips

Drips is an Ethereum-based protocol for streaming and splitting funds with continuous settlement. It enables recurring payments, real-time vesting, and decentralized funding—ideal for use cases like open-source grants and contributor compensation.

To assess the safety of this infrastructure, Drips partnered with Cantina for a security audits review focused on key primitives and deployment behaviors. The scope covered unwrap mechanics, zero address protections, receive function behavior, and zkSync deployment conditions.

Cantina provides formal reviews and supports resilient deployment strategies through additional solutions like bug bounty programs, crowdsourced security competitions, and multisig security.

Findings

Informational

3 findings

1 fixed

2 acknowledged

Informational3 findings

  1. Missing zero address check to ensure unwrapper can't accidentally burn tokens

    State

    Acknowledged

    Severity

    Severity: Informational

    Submitted by

    0xicingdeath

    Description

    The unwrap function is missing a check to ensure that the recipient address is not address(0). If it is, the native token can be accidentally burnt when withdrawn.

    Recommendation

    Add a require (recipient != address(0)) to the unwrap function.

  2. ZKSync Integration Recommendations

    State

    Acknowledged

    Severity

    Severity: Informational

    Submitted by

    0xicingdeath

    Description

    As part of the review, the client asked us specifically to look at one commit that replaced L1's use of CloneProxies with a precompile call in ZKSync to create2 directly. The below compiles our recommendations on future maintainability:

    • Add a chain ID check on the contracts to differentiate whether the deploy is on Ethereum or ZKSync. Implement separate cases for both, and revert if there is an attempt to be used with an unsupported chain.
    • Document the limitations of ZKSync that require these workarounds
    • If additional chains are being deployed, consider either creating external libraries that contain deployment logic and deciding which logic to execute or ensuring that the list of supported chain ID's is kept up to date and monitored

    Note: Issue is TBD and we are still investigating what additional recommendations we may be able to provide.

  3. Add documentation on the payable receive function

    State

    Fixed

    https://github.com/drips-network/contracts/commit/80ec110400f79bdfeb634c71001e2b350707df31

    Severity

    Severity: Informational

    Submitted by

    0xicingdeath

    Description

    The codebase maintains a fairly high standard of documenting security-related assumptions in the Natspec. We recommend to document the impacts of the payable receive function on the unwrapper contract as well, namely - If a user accidentally transfers ETH to the contract without an associated native token, the funds will be lost, as a user can only take out at most the amount of native tokens that have been transferred.

    Recommendation

    Add a natspec comment or in user documentation warning users from attempting to deposit ether directly into the NativeTokenUnwrapper contract.

    Drips

    Good idea. Alternatively unwrap could transfer not the amount of wrapped tokens that were unwrapped, but all native tokens held after the unwrapping. Either way, documentation on receive would be useful.

    Spearbit

    Documentation added as per recommendation.