TrustSwap

We express our gratitude to the TrustSwap team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Team Finance is a token management platform by TrustSwap that provides infrastructure for project teams to lock, vest, stake, and distribute tokens on the Stellar blockchain. The platform's Soroban smart contract suite — comprising the token locking, staking, multisender, vesting (factory and instance), and token minting contracts — was audited for security vulnerabilities.

The system users should acknowledge all the risks summed up in the risks section of the report

{Finding_Table?columns=title,severity,status&setting.filter.type=Vulnerability}

Documentation quality

• The repository contains no whitepaper, technical specification, or architectural overview document. A README was present at the repository root but was deleted prior to the audit commit.

• Inline documentation is absent across all contract modules. No rustdoc comments describe public functions, storage structures, fee formulas, or reward accumulation logic.

• No formal specification exists for the staking reward distribution algorithm, the vesting release schedule arithmetic, or the fee-charging mechanism.

Code quality

• The codebase is well-organized into separate contract crates with clear separation between contract logic, storage, events, and error definitions.

• The project leverages the stellar-access, stellar-contract-utils, stellar-macros, and stellar-tokens crate ecosystem (v0.4.0) built on soroban-sdk 22.0.8, providing standardized patterns for ownership, pausability, upgradeability, and token operations.

• Several arithmetic and input validation edge cases were identified across the locking, staking, and vesting contracts, particularly around signed integer handling and boundary checks.

• Code duplication was observed between contracts where admin-related functions and event emitters were reused without adapting contract-specific constants.

Test coverage

Code coverage of the project cannot be measured.

• The test suite comprises approximately 6,681 lines across 9 test files, covering the primary operational flows for each contract.

• The locking contract has the most extensive test coverage, followed by the staking contract and the multisender.

• Tests do not cover negative case scenarios such as withdrawals exceeding a staked or locked balance, fee enforcement on alternative code paths, or vesting revocation edge cases.

• No fuzz tests, property-based tests, or invariant tests are present. Adding stateful fuzz testing for the staking reward accumulator and the locking partial-withdrawal arithmetic is recommended.

• The minting token contracts have minimal test coverage (173-207 lines each), with no tests for access control edge cases.

The Team Finance platform is a suite of Soroban smart contracts on the Stellar blockchain that provides token management infrastructure for project teams. The platform enables time-locked token custody, staking reward distribution, batch token distribution, token vesting with Merkle-tree-based schedules, and configurable token minting. All fee-bearing operations convert a USD-denominated fee into XLM using the Reflector oracle price feed.

The Locking contract allows users to deposit fungible tokens or NFTs into time-locked positions. Each deposit records a token address, withdrawal address, locked amount, and unlock timestamp. Deposits are assigned sequential IDs and tracked per withdrawal address in a persistent deposit vector. The contract supports partial withdrawals after the unlock time, lock splitting into new deposit IDs with independent unlock times, lock duration extension, and lock ownership transfer to a different withdrawal address. An owner-controlled recover_assets() function reassigns all deposits from one withdrawal address to another. The contract implements the Pausable trait, allowing the owner to halt lock creation and splitting during emergencies. A referral system provides fee discounts to callers who supply a referrer address, with a configurable split between the referrer and the protocol company wallet.

The Staking contract implements a pool-based staking model where pool creators deposit reward tokens upfront and stakers earn proportional rewards over a fixed time window. Reward distribution uses a time-weighted acc_token_per_share accumulator scaled by a configurable precision factor. Pool creators can add additional rewards, stop reward accrual early (reclaiming remaining rewards), and set per-pool stake limits. Stakers deposit tokens into specific pools, accrue rewards proportional to their share of total staked supply, and withdraw principal along with pending rewards. An emergency withdrawal function allows stakers to reclaim principal while forfeiting all accumulated rewards.

The Multisender contract provides batch distribution of fungible tokens and NFTs. The caller provides parallel arrays of recipients and amounts (or token IDs for NFTs), and the contract executes individual transfer_from calls for each entry in a single transaction. Configurable transfer limits cap the maximum batch size at 1,000 for tokens and 500 for NFTs. An owner-only claim_token/claim_nft function distributes tokens held by the contract itself.

The VestingFactory contract deploys individual Vesting contract instances using Soroban's deploy_v2 mechanism with a stored WASM hash. Each deployment is seeded with a unique salt derived from a sequential vesting ID and the token address. The factory transfers the total vesting allocation from the caller directly to the newly deployed vesting contract.

The Vesting contract distributes tokens to beneficiaries according to a schedule encoded in a Merkle tree. Each leaf contains an index, beneficiary address, total amount, revocability flag, start time, end time, cadence, and percentage claimable at start. The claim() function verifies a Keccak-256 Merkle proof against the stored root before computing the claimable amount using a linear release formula with optional cliff. Revocable schedules can be terminated by the owner through stop_vesting(), which returns unclaimed tokens to the owner. An emergency_withdraw() function allows the owner to reclaim all tokens if no claims have been executed, serving as a recovery mechanism for misconfigured Merkle roots.

The minting module provides four token contract variants built on the stellar-tokens fungible token base: TeamToken (fixed supply, no mint/burn), MintableTeamToken (owner-mintable), BurnableTeamToken (holder-burnable), and MintBurnTeamToken (owner-mintable and holder-burnable). All variants accept a name, symbol, decimals, initial supply, owner, and IPFS metadata hash at construction. The owner can update the metadata IPFS hash on all variants.

Privileged roles

• Owner (Locking, Staking, Multisender, VestingFactory, Vesting, all Token variants): The owner is set at construction via ownable::set_owner() and can be transferred using the Ownable trait. In the locking contract, the owner controls fee parameters, the oracle address, the company wallet, referral parameters, the whitelist admin roster, the free-token list, and the pause state, and can reassign all deposits from any user to any other address via recover_assets() without timelock or beneficiary consent. In the staking contract, the owner controls identical fee and whitelist parameters and can extract arbitrary token amounts from the contract via save_me(). In the multisender contract, the owner controls fee parameters and can distribute any tokens held by the contract through claim_token() and claim_nft(). In the vesting factory, the owner controls fee parameters and the WASM hash used for new vesting deployments. In the vesting contract, the owner can revoke revocable schedules and reclaim funds, and can execute emergency withdrawals before any claims occur. In the mintable and mint-burn token variants, the owner can mint unlimited tokens with no supply cap. The locking, staking, multisender, and vesting factory contracts implement the Upgradeable pattern, allowing the owner to replace the contract implementation. No timelock, multisig, or governance mechanism constrains any owner action.

• Whitelist Admin (Locking, Staking, Multisender, VestingFactory): Whitelist admins are granted by the owner through update_whitelist_admin_access(). Admins can add or remove wallet addresses from the fee-exemption whitelist. A compromised whitelist admin can exempt arbitrary addresses from protocol fees, causing revenue loss.

• Pool Owner (Staking): The address that calls add_pool() becomes the pool owner, distinct from the contract owner. The pool owner can add additional reward tokens to the pool, stop reward accrual and reclaim remaining rewards, and set the per-pool stake limit. The pool owner has no control over protocol-level settings or other pools.

The scope of the project includes the following smart contracts from the provided repository:

Assets in Scope