Bridge Contracts - Tea-Fi

1. INTRODUCTION

Tea-Fi engaged Halborn to conduct a security assessment of their smart contracts between October 1, 2025 and October 11, 2025. The engagement focused on the protocol’s core components responsible for custody (Vault), cross‑chain transfers (Bridge Adapter), and yield generation (Aave Strategy), with an emphasis on correctness, robustness to edge cases, and protection of user and treasury value.

The review was performed against the codebase provided by Tea-Fi (see Engagement Details and Scope) and included a comprehensive, self‑contained Foundry test suite authored during the assessment. The suite combines unit tests, property/invariant tests, and fuzzing to validate expected behavior and adversarial scenarios locally (no external networks required).

2. ASSESSMENT SUMMARY

A full‑time Halborn security engineer with deep smart‑contract security expertise performed the assessment, combining manual code review with automated testing to maximize coverage and realism.

Objectives:

• Verify contract behavior and state transitions match intention under normal and adverse conditions.

• Identify vulnerabilities, economic inconsistencies, and unsafe assumptions.

• Validate access control, accounting (1:1 shares, principal vs. yield), and cross‑component interactions (bridge fees, strategy divest/harvest semantics).

Highlights and recommendations:

• Bridge Adapter: Add a caller‑provided maxFee and select native fees by token type (not array index). Sanitize empty/misaligned quotes; emit messageId events for observability.

• Aave Strategy: Clamp divest requests to booked principal to prevent yield leakage; consider allowance hygiene (exact approvals or emergency revoke).

• Vault (ERC‑4626, 1:1): Enforce runtime balance‑delta checks to reject fee‑on‑transfer tokens; forbid rebasing assets; consider an emergency withdrawal mode (on‑hand only) if the strategy misbehaves.

Overall, the codebase demonstrates clear security intent. The recommendations above reduce both likelihood and blast radius of operational risks while strengthening user and treasury safety.

3. CAVEATS

• Scope limits: Only the contracts and files listed in Scope were reviewed. External systems (e.g., Hyperlane router internals, Aave protocol), off‑chain infrastructure, and out‑of‑scope directories were treated as black boxes.

• Assumptions: Standard token behavior is assumed unless explicitly tested (e.g., fee‑on‑transfer and rebasing tokens were explored via mocks). Economic conditions beyond contract‑level invariants (market liquidity, MEV dynamics) were out of scope.

• Differential context: Findings are referenced against the scoped commit; external changes not visible in scope are excluded.

A full end‑to‑end assessment—covering off‑chain services, cross‑chain ops, and production deployment posture—is recommended for a complete security picture.