Prepared by:
HALBORN
Last Updated 01/14/2026
Date of Engagement: December 15th, 2025 - December 29th, 2025
100% of all REPORTED Findings have been addressed
All findings
12
Critical
2
High
0
Medium
3
Low
5
Informational
2
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.
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.
| Security analysis | Risk level | Remediation |
|---|---|---|
| LP token supply can be created or consumed from a different pool | Critical | Solved - 12/30/2025 |
| User controlled transfer fee parameter enables unauthorized token overpayment | Critical | Solved - 01/07/2026 |
| Allocation execution window is more restrictive than the settlement model | Medium | Solved - 12/31/2025 |
| Multiple liquidity pools can be created for the same instrument pair | Medium | Solved - 01/02/2026 |
| Swap activity is not recorded for featured rewards | Medium | Solved - 12/31/2025 |
| Settlement deadlines allow logically invalid execution windows | Low | Solved - 01/02/2026 |
| Zero liquidity pool creation due to decimal quantization | Low | Solved - 01/02/2026 |
| Exact Decimal comparisons on computed values | Low | Solved - 12/31/2025 |
| Requests and relationships cannot be explicitly revoked once created | Low | Solved - 01/03/2026 |
| Fee updates can silently disable swaps | Low | Solved - 01/02/2026 |
| Lack of explicit venue and vault consistency checks when creating pool requests | Informational | Solved - 01/02/2026 |
| Cancellation reason for pool creation requests is not persisted | Informational | Solved - 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
