# Radicle Drips-Hub Findings

## 1. Set Splits would lost the splittable value for old split receivers.
__Severity__: Major
Context: [`DripsHub.sol#L459`](https://github.com/radicle-dev/drips-contracts/blob/835656a99015e3cc28ee1003924654e5071f3d00/src/DripsHub.sol#L459)

`setSplits` function can be called independently of the split function but if there is already some value has been ready to split but `split` function would not be exlicitly called onchain and if the user again call `setSplits` with new receiver sets then old receivers would not be able to receive split funds anymore.

**Recommendation**: Call `split` function before calling `setSplits`.

**Status**: Pending

**Client Comment**: `ImmutableSplitsDriver.sol` would be used to solve the problem.

## 2. Incorrect parameter value provided while squeezing drip.
__Severity__: Minor
Context:[`DripsHub.sol#L248`](https://github.com/radicle-dev/drips-contracts/blob/835656a99015e3cc28ee1003924654e5071f3d00/src/DripsHub.sol#L248)

According to the `_give` function specification in `Splits.sol`. The `userId`, or the person who sets the drips, should be the first argument, and the drip recipient should be the second. But in this context, both the first and second parameters are set to the same value, `userId`. The correct terms are `senderId` and `userId`.

**Recommendation**: Replace the statement with below statement

Splits._give(senderId, userId, assetId, amt);

**Status** Pending

**Client Comment**: TBD

## 3. Inefficient mathematical operations
__Severity__: Informational
Context: [`Drips.sol#274-275`](https://github.com/radicle-dev/drips-contracts/blob/835656a99015e3cc28ee1003924654e5071f3d00/src/Drips.sol#L274)

The drips receiving procedure will be facilitated by frequent calls to `_receiveDripsResult()`. For a frequent drips receiver user, even a tiny gas savings can add up to significant monetary savings. Due to the fact that `receivableCycles` and `toCycle` cannot go underflow, it is unnecessary to waste gas doing inherent underflow and overflow checks.

There are other multiple places can be found in codebase to save gas like this.

**Recommendation**: Use `unchecked` block to avoid inherent underflow and overflow checks on mathematical operations.

**Status** Pending

**Client Comment**: TBD

## 4. Inconsistent naming convention used in codebase.
__Severity__: Informational
Context: [`DripsHub.sol#L239`](https://github.com/radicle-dev/drips-contracts/blob/835656a99015e3cc28ee1003924654e5071f3d00/src/DripsHub.sol#L239)

The term `userId` is used throughout the codebase to identify the setter or receiver of drips as well when the person is doing operation on its receivable drips. While the `receiver` variable name is used to specify the recipient of drips. But in this situation, `userId` is used for the recipient and `senderId` for the person who initiated the drips. As a result code redability is reduced and creates confusion.

**Recommendation**: It is preferable to have uniformity across the codebase. Use `userId` for the person who set the drips and `receiver` or `receiverId` for the person for whom the drips are set.

**Status** Pending

**Client Comment**: TBD