OtterSec — OmniSync Security Audit Report

🔐 OtterSec

OmniSync Protocol

Token Contract & Staking
Security Audit Report

Security assessment of the $OMNI SPL token contract, staking mechanism, and escrow settlement logic on the Solana blockchain.

Report Date

March 28, 2025

Engagement Type

Token & Staking Audit

Report Version

v1.0 (Final)

Auditor

J. Kim, S. Park

Duration

14 days

Commit Hash

c3d7e1f0a2b9

✅

PASSED — No Critical or High Severity Issues Found

OtterSec completed a thorough review of the $OMNI token contract and staking system. One medium severity re-entrancy pattern was identified and remediated. One low severity informational finding was acknowledged by the team as a deliberate design choice with documented rationale.

1. Executive Summary

OtterSec was engaged to audit the tokenomics layer of the OmniSync protocol — specifically the $OMNI SPL token mint, the staking and vesting contracts, and the escrow settlement logic that governs compute payment flows. The audit identified 2 findings: 1 Medium (remediated) and 1 Low (acknowledged).

The $OMNI token implementation follows SPL token standards correctly. The staking contract properly handles lockup schedules, cliff periods, and linear vesting. The burn mechanism (2% per transaction) is implemented at the protocol level and cannot be bypassed by consumers or providers.

2. Scope

Component	Language	Files	LoC
omnisync-token/programs/omni-token	Rust (Anchor)	5	742
omnisync-token/programs/staking	Rust (Anchor)	9	1,891
omnisync-token/programs/vesting	Rust (Anchor)	7	1,204
omnisync-core/programs/escrow	Rust (Anchor)	6	987

3. Findings

ID	Severity	Title	Status
OTT-001	Medium	Staking unlock schedule bypass via re-entrancy pattern	✓ Fixed
OTT-002	Low	Token metadata URI not validated on-chain	⚠ Acknowledged

4. Detailed Findings

OTT-001 Medium Staking unlock schedule bypass via re-entrancy pattern ✓ Fixed in v0.9.6

Description

The unlock_stake instruction in the staking program did not follow the checks-effects-interactions pattern. An attacker could invoke a CPI (cross-program invocation) during the unlock process to re-enter the staking contract and trigger an additional unlock before the internal state was updated, potentially withdrawing more tokens than their vesting schedule allowed.

Vulnerable Pattern

// Vulnerable: state update AFTER token transfer transfer_tokens(user, amount); // CPI — re-entry point stake_account.unlocked += amount; // state update too late

Fix Applied

// Fixed: state update BEFORE token transfer stake_account.unlocked += amount; // state update first transfer_tokens(user, amount); // CPI now safe

Resolution

Remediated in commit e4f8a2c. OtterSec verified the fix correctly reorders operations.

OTT-002 Low Token metadata URI not validated on-chain ⚠ Acknowledged

Description

The $OMNI token metadata URI (pointing to logo and description JSON) is stored in the Metaplex metadata account but its format is not validated on-chain. A future metadata update could point to a malformed or unavailable URI without triggering an on-chain error.

OmniSync Response

The team acknowledged this finding and noted that metadata URI updates require the metadata update authority — held in the 4-of-7 security multisig — making malicious updates operationally infeasible. URI format validation would add unnecessary compute overhead to every metadata interaction. Acknowledged without code change.

5. Positive Observations

The 2% burn mechanism is correctly implemented at the transfer hook level and cannot be circumvented by any consumer or provider action
Vesting cliff and linear unlock schedules are mathematically correct and overflow-safe
The staking contract correctly handles edge cases: zero-balance stakes, simultaneous unlock requests, and epoch boundary conditions
All authority accounts (mint authority, freeze authority) are held by the protocol multisig, not an individual key

6. Conclusion

The OmniSync token and staking system is well-implemented. The single medium severity finding has been remediated. OtterSec is satisfied with the remediation quality and considers the token layer ready for mainnet deployment.

Lead Auditor

Jae-won Kim

Senior Auditor, OtterSec

Reviewed By

Soo-yeon Park

Security Researcher, OtterSec