Smart Contract Assessment - Splyce

1. Introduction

This security assessment was commissioned by Splyce, a permissionless institutional yield protocol built on Stellar/Soroban that offers fixed rate, fixed term lending vaults backed by tokenized real world assets alongside a yield bearing stablecoin product. The review was conducted by Halborn's experienced security team, focusing on the on-chain components of the Splyce S-Token smart contract suite. The assessment covered all functionality within the SToken, Factory, Accountant, NavOracle, FixedYieldOracle, ProxyAssetManager, Multisig, ThresholdPolicy, and Ed25519Verifier contracts from June 5th, 2026, to July 8th, 2026. The primary objective of this engagement was to identify potential vulnerabilities, verify module reliability, and enhance the overall security posture of the protocol.

2. Assessment Summary

Halborn's security team dedicated significant effort to verifying the security of the smart contracts, combining manual code review, control flow analysis, and targeted proof of concept validation across the vault, governance, and oracle layers of the protocol.

The purpose of this assessment is to:

• Ensure that smart contract functions operate as intended

• Identify potential security issues within the smart contracts

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were completely addressed by the Splyce team. The main recommendations were the following:

• Redesign asset custody and liquidity accounting around the ProxyAssetManager. A single vault binding permanently strands underlying funds belonging to a sibling vault after a cross-vault swap or asset manager rotation, and a separate emergency sweep path bypasses total_idle accounting entirely. Both undermine the guarantee that vault funds remain recoverable and correctly tracked on-chain, and together represent the most severe risk identified in this engagement.

• Close the pending-price arbitrage window across vault operations. Large price deviations are queued for manager review instead of being rejected, but deposits, withdrawals, and swaps can still execute against a stale accepted price while a more accurate pending price awaits acceptance, creating a risk-free arbitrage opportunity that a user can exploit before the price is corrected.

• Harden the yield oracles against manipulation and denial of service. NavOracle's fee accrual function can be called by anyone to repeatedly block legitimate price updates, and FixedYieldOracle's linear time-based price curve allows early depositors to capture value from later depositors while retroactive rate changes can produce discontinuous price jumps; both designs need stronger economic and access-control safeguards.

• Correct management fee accrual and fee distribution accounting. Zero-accrual calls silently advance the accrual timestamp and suppress fees the protocol is owed, and the Accountant contract cannot distribute fee shares for any vault whose share token differs from the one set at initialization, permanently stranding fee income from secondary vaults sharing the same Accountant.

• Align token behavior with ERC-4626 and SEP-41 expectations. Whitelist checks validate only the caller on deposit and withdrawal paths, allowing a whitelisted user to route shares or underlying funds to a non-whitelisted receiver, and burn events are emitted before the underlying withdrawal request actually completes, misrepresenting when tokens are destroyed.

• Harden storage-dependent safeguards against expiry and unbounded growth. The factory's vault registry is stored as a single unbounded list that will eventually exceed the instance storage limit and permanently block new vault deployments.