Smart Contract Assessment Audit | Dsrv Labs

Summary

100% of all REPORTED Findings have been addressed

About this report

Assessment Type

Assurance Assessment

Date of Engagement

June 11th, 2026 - June 22nd, 2026

Source Code

dsrv-contract-monorepo

Assessed Commit ID

56d067a

Severity Breakdown

4Acknowledged
7Risk Accepted
8Solved
19All Findings

Critical0
High0
Medium2
- 1Risk A.
- 1Solved
Low8
- 6Risk A.
- 2Solved
Informational9
- 4Ack.
- 5Solved

Summary#

Dsrv Labs engaged Halborn to conduct a security assessment on their smart contracts beginning on June 11th 2026 and ending on June 22nd, 2026. The assessment scope was limited to the smart contracts provided to Halborn. Commit hashes and additional details are available in the Scope section of this report.

Following completion of the remediation review, the Dsrv Labs team provided commit 1a62f90 as a later version of the codebase. Halborn's security assessment was performed against commit 56d067a, and remediation verification was limited to the changes referenced in the individual findings. The later commit contains additional changes, including a new non-atomic tryExecute() sponsored execution path with per-call failure tolerance and a distinct TryExecuteBatch() EIP-712 typehash, best-effort surplus refund logic with bounded gas stipend _tryRefundSurplus()), refactored shared input validation _validateBatchInputs()), a receive() function added to BatchRelayer contract for accepting mid-batch ETH refunds, and reworked BatchRelayer contract's refund accounting using balance-based sweep _refundExcess()) replacing the previous per-failure accumulator, which were not included in the agreed assessment scope and were not reviewed by Halborn. Its inclusion here is informational only and does not constitute a security assessment or approval of those additional changes.

The reviewed system is a smart contract monorepo consisting of four independent packages: an EIP-7702 account abstraction system with session keys and a two-phase recovery mechanism, an ERC-20 payment settlement system using Permit2 with a replaceable logic layer and a permanent spender, a permissionless ETH top-up router for keeping relayer wallets funded, and a deterministic cross-chain deployer. The recovery mechanism allows unrestricted execution of any action after the challenge period elapses, with no target, selector, or value constraints applied to the recovery batch. Trust is layered differently across modules: the smart account trusts the EOA key holder, session signers are constrained by owner-configured policies, the payment system trusts the operator for configuration and the customer for signing, and the sponsor-fund trusts only the project creator. Each package directory at the audited commit contains an acknowledged vulnerability report documenting known/acknowledged issues identified prior to this engagement, which are not included in this report.

ASSESSMENT SUMMARY#

Halborn was provided with 8 days for this engagement and assigned a full-time security engineer to assess the security of the smart contracts in scope. The assigned engineer possesses deep expertise in blockchain and smart contract security, including hands-on experience with multiple blockchain protocols.

The objective of this assessment is to:

Identify potential security vulnerabilities within the smart contracts.
Verify that the smart contract functionality operates as intended.

In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of security risks, which were partially addressed by the Dsrv Labs team. The main recommendations were:

Bind the customer signature to the active logic contract address so that a rotated-in logic cannot settle against previously signed payments.
Refund unused native value to the caller after sponsored execution, or restrict the sponsored path to zero value.
Cap the number of allowed targets and selectors per policy, and replace the physical signer sweep on bulk invalidation with an epoch-only increment that defers storage cleanup to lazy access.

TEST APPROACH AND METHODOLOGY#

Halborn performed a combination of manual review of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the smart contract assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of smart contracts and can quickly identify items that do not follow security best practices.

The following phases and associated tools were used throughout the term of the assessment:

Research into the architecture and purpose of the in-scope contracts.
Manual code review and walkthrough of the in-scope contracts.
Manual assessment of critical Solidity variables and functions to identify potential vulnerability classes.
Manual testing using custom scripts.
Static Analysis of security for scoped contract, and imported functions (Slither).
Local deployment and testing with (Foundry, Remix IDE).

Risk Methodology#

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.

The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.

The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.

The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.

The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

4.1 EXPLOITABILITY

Attack Origin (AO):

Captures whether the attack requires compromising a specific account.

Attack Cost (AC):

Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.

Attack Complexity (AX):

Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.

Metrics:

EXPLOITABILITY METRIC ( $m_e$ )	METRIC VALUE	NUMERICAL VALUE
Attack Origin (AO)	Arbitrary (AO:A)	1
Attack Origin (AO)	Specific (AO:S)	0.2
Attack Cost (AC)	Low (AC:L)	1
	Medium (AC:M)	0.67
	High (AC:H)	0.33
Attack Complexity (AX)	Low (AX:L)	1
	Medium (AX:M)	0.67
	High (AX:H)	0.33

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

4.2 IMPACT

Confidentiality (C):

Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.

Integrity (I):

Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.

Availability (A):

Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.

Deposit (D):

Measures the impact to the deposits made to the contract by either users or owners.

Yield (Y):

Measures the impact to the yield generated by the contract for either users or owners.

Metrics:

IMPACT METRIC ( $m_I$ )	METRIC VALUE	NUMERICAL VALUE
Confidentiality (C)	None (C:N)	0
	Low (C:L)	0.25
	Medium (C:M)	0.5
	High (C:H)	0.75
	Critical (C:C)	1
Integrity (I)	None (I:N)	0
	Low (I:L)	0.25
	Medium (I:M)	0.5
	High (I:H)	0.75
	Critical (I:C)	1
Availability (A)	None (A:N)	0
	Low (A:L)	0.25
	Medium (A:M)	0.5
	High (A:H)	0.75
	Critical (A:C)	1
Deposit (D)	None (D:N)	0
	Low (D:L)	0.25
	Medium (D:M)	0.5
	High (D:H)	0.75
	Critical (D:C)	1
Yield (Y)	None (Y:N)	0
	Low (Y:L)	0.25
	Medium (Y:M)	0.5
	High (Y:H)	0.75
	Critical (Y:C)	1

Impact

I

is calculated using the following formula:

$I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}$

4.3 SEVERITY COEFFICIENT

Reversibility (R):

Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.

Scope (S):

Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.

Metrics:

SEVERITY COEFFICIENT ( $C$ )	COEFFICIENT VALUE	NUMERICAL VALUE
Reversibility ( $r$ )	None (R:N)	1
	Partial (R:P)	0.5
	Full (R:F)	0.25
Scope ( $s$ )	Changed (S:C)	1.25
Scope ( $s$ )	Unchanged (S:U)	1

Severity Coefficient

C

is obtained by the following product:

$C = rs$

The Vulnerability Severity Score

S

is obtained by:

$S = min(10, EIC * 10)$

The score is rounded up to 1 decimal places.

Critical	High	Medium	Low	Informational
9 - 10	7 - 8.9	4.5 - 6.9	2 - 4.4	0 - 1.9

Scope#

(a) Repository:dsrv-contract-monorepo

(b) Assessed Commit ID:56d067ad112ea99feeae101358b4cedce5b636e2

38 files

create3-factory / src

2 files

interfaces

1 file

ICreate3Factory.sol

solidity

Create3Factory.sol

solidity

dsrv-smart-account / src

22 files

auth

6 files

AgentPolicy.sol

solidity

ERC1271.sol

solidity

NonceTracker.sol

solidity

RecoverAuthorization.sol

solidity

SessionAuthorization.sol

solidity

SingleOwner.sol

solidity

Out-of-Scope:Third party dependencies and economic attacks.

074b3dd2b0f291e398afe41831e0792efa6a7341

Out-of-Scope: New features/implementations after the remediation commit IDs.

Assessment Summary & Findings Overview#

#	Title	Severity	Score	Status
HAL-01	Payment signature digest does not bind to the executing logic contract	Medium	5.0	Risk Accepted06/26/2026
HAL-02	Excess native ETH sent with sponsored execution is not refunded to the relayer	Medium	5.0	Solved06/26/2026
HAL-03	Unbounded nested loops in session management cause gas exhaustion	Low	2.5	Risk Accepted06/26/2026
HAL-04	Passkey signature verification fails on chains without the P256 precompile	Low	2.5	Risk Accepted06/26/2026
HAL-05	Payment ordering within a batch enables selective budget depletion	Low	2.5	Risk Accepted06/26/2026
HAL-06	External call return data is silently discarded on success	Low	2.5	Risk Accepted06/26/2026
HAL-07	Signature verification view diverges from the execution path it is meant to preflight	Low	2.5	Solved06/26/2026
HAL-08	Validation check can be enabled when the validation registry is not deployed	Low	2.5	Solved06/26/2026
HAL-09	Batch funding scan window is consumed by ineligible sub-sponsors reducing effective coverage	Low	2.5	Risk Accepted06/26/2026
HAL-10	Payer resolution does not account for transfer-blocking conditions causing settlement to revert instead of falling through	Low	2.5	Risk Accepted06/26/2026
HAL-11	Admin role can be permanently renounced without safeguard	Informational	1.0	Acknowledged06/26/2026
HAL-12	Agent verification hook permits multiple unconfigured states that silently bypass all checks	Informational	1.0	Solved06/26/2026
HAL-13	P256 session signers can be registered without relying-party binding	Informational	1.0	Acknowledged06/26/2026
HAL-14	Customer change preserves existing budgets and backup accounts for the incoming signer	Informational	0.6	Acknowledged06/26/2026
HAL-15	Recovery proposal overwrite resets the challenge period without cancellation record	Informational	0.5	Solved06/26/2026
HAL-16	Trusted validators can be cleared while the validation check remains enabled	Informational	0.5	Solved06/26/2026
HAL-17	Admin role can escalate to operator role through intermediate role self-grant	Informational	0.5	Acknowledged06/26/2026
HAL-18	Recovery cannot evict a compromised key and provides no freeze during the challenge period	Informational	0.5	Solved06/29/2026
HAL-19	Backup payer allowances are spender-global and can be drained by any project without payer consent	Informational	0.5	Solved06/26/2026

Findings & Tech Details#

HAL-01Risk Accepted

Payment signature digest does not bind to the executing logic contract

Medium

5.0AO:A/AC:L/AX:L/R:N/S:U/C:N/A:N/I:M/D:N/Y:NAO:A/AC:L/AX:L/R:N/S:U/C:N/A:N/I:M/D:N/Y:N

Description

Recommendation

Remediation Comment

HAL-02Solved

Excess native ETH sent with sponsored execution is not refunded to the relayer

Medium

5.0AO:A/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:M/Y:NAO:A/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:M/Y:N

Description

Recommendation

Remediation Comment

Addressed in:

Remediation Comment

Addressed in:

074b3dd2b0f291e398afe41831e0792efa6a7341

HAL-08Solved

Validation check can be enabled when the validation registry is not deployed

Low

2.5AO:A/AC:L/AX:L/R:N/S:U/C:N/A:L/I:N/D:N/Y:NAO:A/AC:L/AX:L/R:N/S:U/C:N/A:L/I:N/D:N/Y:N

Description

Recommendation

Remediation Comment

Addressed in:

Remediation Comment

Addressed in:

Remediation Comment

Addressed in:

Remediation Comment

Addressed in:

074b3dd2b0f291e398afe41831e0792efa6a7341

Disclaimer#

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.