Tradecraft AMM - Obsidian


Prepared by:

Halborn Logo

HALBORN

Last Updated 01/14/2026

Date of Engagement: December 15th, 2025 - December 29th, 2025

Summary

100% of all REPORTED Findings have been addressed

All findings

12

Critical

2

High

0

Medium

3

Low

5

Informational

2


1. INTRODUCTION

Obsidian engaged Halborn to conduct a security assessment on their DAML application beginning on December 15th, 2025 and ending on December 29th, 2025. The security assessment was scoped to the repository listed with commit hash, and further details in the Scope section of this report.

2. ASSESSMENT SUMMARY

The team at Halborn was provided four weeks for the engagement and assigned two full-time security engineers to verify the security of the smart contracts. The security engineers are blockchain and smart contract security experts with advanced penetration testing and smart contract hacking skills, and deep knowledge of multiple blockchain protocols.

The purpose of the assessment is to:

    • Identify potential security issues within the different smart contracts and services.

    • Ensure that smart contract and services functionality operates as intended.


In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were successfully addressed by the Obsidian team. The main ones were the following:

    • Store the LP configuration and allocation factory inside the AMM at creation and use those stored values instead of relying on caller input. If external input must remain, add strict validation so only the correct LP configuration and factory are accepted.

    • Ensure that all transfer fee parameters are fully protocol controlled and cannot be influenced by user supplied inputs.

    • Adjust allocation timing checks so valid allocations are still permitted during the full settlement window, aligning execution behavior with expected Splice semantics.

    • Guarantee uniqueness of AMM instances by deriving a deterministic identifier from the underlying asset pair and blocking the creation of duplicate pools.

3. SCOPE

REPOSITORY
(a) Repository: tradecraft
(b) Assessed Commit ID: ad2619c
(c) Items in scope:
  • AMMRulesRequest
  • AMMRules
  • AMMFees
↓ Expand ↓
Out-of-Scope: Third party dependencies and economic attacks.
Remediation Commit ID:
Out-of-Scope: New features/implementations after the remediation commit IDs.

4. Findings Overview

Security analysisRisk levelRemediation
LP token supply can be created or consumed from a different poolCriticalSolved - 12/30/2025
User controlled transfer fee parameter enables unauthorized token overpaymentCriticalSolved - 01/07/2026
Allocation execution window is more restrictive than the settlement modelMediumSolved - 12/31/2025
Multiple liquidity pools can be created for the same instrument pairMediumSolved - 01/02/2026
Swap activity is not recorded for featured rewardsMediumSolved - 12/31/2025
Settlement deadlines allow logically invalid execution windowsLowSolved - 01/02/2026
Zero liquidity pool creation due to decimal quantizationLowSolved - 01/02/2026
Exact Decimal comparisons on computed valuesLowSolved - 12/31/2025
Requests and relationships cannot be explicitly revoked once createdLowSolved - 01/03/2026
Fee updates can silently disable swapsLowSolved - 01/02/2026
Lack of explicit venue and vault consistency checks when creating pool requestsInformationalSolved - 01/02/2026
Cancellation reason for pool creation requests is not persistedInformationalSolved - 01/03/2026

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.

// Download the full report

Tradecraft AMM

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed