Tradecraft AMM V7

INTRODUCTION#

Obsidian engaged Halborn to conduct a security assessment on their smart contracts beginning on October 27th, 2026 and ending on October 30th, 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.

The reviewed contracts are the V7 pool of the Tradecraft AMM, a concentrated-liquidity venue on Canton for tokenized stocks, written in Daml. Actors submit swap, deposit, withdrawal and collection orders through the public order API. The vault executes them in batches against the V6 swap and tick math, which ports the Uniswap v3 concentrated-liquidity formulas to Daml Numeric 20 arithmetic. The vault funds the orders from allocations, holdings or transfer offers, and settles both legs immediately or through deferred delivery-versus-payment requests.

A Transfer Agent issues at least one pool token and can freeze its movements for an individual, for the vault, or for the whole token, as its legal obligations require. The pool adds compliance controls on top of trading: holder and LP admission based on registry credentials, security-control holds and market status, volume limits, owner recovery with segregated claims, and venue rejection of orders.

ASSESSMENT SUMMARY#

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

The objectives of this assessment are 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 should be addressed by the Obsidian team. The main recommendations are:

• Keep the failure of one order inside that order. Reject a swap price limit outside the open price range, bound the instrument1 amount of each deposit, and cap the liquidity at each tick, so that no order can make a Numeric 20 operation or the AMM precondition abort the whole batch.

• Round every pool amount in favor of the pool. Compute each instrument1 and instrument2 amount as one exact quotient and round it once: up when the pool receives tokens, and down when the pool pays them.

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 Daml variables and functions to identify potential vulnerability classes.

• Manual testing using custom scripts.

• Invariant testing of Uniswap v3 properties with seeded, generated order sequences on the ledger.

• Static Analysis of security for scoped contracts, and imported functions (Daml compiler).

• Local deployment and testing with (Daml Script on the Daml IDE ledger).

Risk Methodology#

Scope#