POSY Contract & Sealcoin OFT - SEALCOIN

Prepared by:

HALBORN

Last Updated 01/07/2026

Date of Engagement: December 22nd, 2025 - December 24th, 2025

Summary

100% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

1. Introduction
2. Assessment summary
3. Scope
4. Findings overview

1. INTRODUCTION

SEALCOIN engaged Halborn to conduct a security assessment on their smart contracts beginning on December 22nd 2025 and ending on December 24th, 2025. The security assessment was scoped to the smart contracts provided in the sealcoin/posy-contract and sealcoin/oft Github repositories, provided to the Halborn team. Commit hash and further details can be found in the Scope section of this report.

The reviewed contracts consist of a staking and reward distribution system (Sealcoin PoSy) deployed on Hedera that manages time-locked staking, reward accounting, and role-based administration for the QAIT token. In parallel, they include an omnichain fungible token (OFT) bridging system that locks the canonical QAIT HTS supply on Hedera and mints or burns fully backed OFT representations on EVM chains via LayerZero.

2. ASSESSMENT SUMMARY

Halborn was provided with 3 days for this engagement and assigned a full-time security engineer to assess the security of the smart contracts in scope. The assigned engineer possess 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 issues within the SEALCOIN protocol smart contracts.
Ensure that smart contract of ````SEALCOIN protocol functions operate as intended.

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

Implement a two-step ownership transfer mechanism.
Pause rewards setting functionality when the staking contract is paused.
Reset the position states when the position is withdrawn.
Prevent bridging to the zero address.
Use the correct parameters types when encoding the transfer call.

3. SCOPE

REPOSITORIES

(a) Repository: posy-contract

(b) Assessed Commit ID: 08fd9bf

contracts/AdminBaseUpgradeable.sol
contracts/Constants.sol
contracts/Errors.sol

↓ Expand ↓

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

(a) Repository: oft

(b) Assessed Commit ID: e6c2441

contracts/IHederaPreCompile.sol
contracts/QAITHTSConnector.sol
contracts/QAITOFT.sol

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 analysis	Risk level	Remediation
Single-step ownership transfer increases risk of accidental ownership loss	Informational	Solved - 12/28/2025
Paused staking contract still allows reward configuration for current stakers	Informational	Solved - 12/23/2025
Type mismatch in HTS transferred amount	Informational	Solved - 12/23/2025
Withdrawn positions retain stale data	Informational	Solved - 12/23/2025
Zero-address recipient can cause failed credit and stuck bridging delivery	Informational	Acknowledged - 12/29/2025

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.