uSOL Risk Assessment by BA Labs
Part I: Protocol Overview
A.1 Protocol Details
Unit Solana (uSOL) is a wrapped representation of Solana’s native token (SOL) on the Hyperliquid platform. It is issued by the Hyperunit protocol via a lock-and-mint bridging mechanism. In essence, when users deposit SOL from the Solana blockchain into Hyperunit, an equivalent amount of uSOL is minted on Hyperliquid for use in trading and DeFi, and when users withdraw, uSOL is burned and the corresponding SOL is released back on Solana. The design of uSOL emphasizes a fully collateralized peg – every uSOL in circulation should be backed 1:1 by actual SOL held in reserve.
A.1.1 Underlying Collateral
The underlying collateral for uSOL is native SOL tokens held in a designated treasury account on the Solana blockchain. Whenever a user deposits SOL through Hyperunit, those SOL coins are locked in a Solana address controlled by the protocol’s guardian network, and an equivalent amount of uSOL is created on Hyperliquid. According to Hyperunit’s documentation, the main Solana treasury address for uSOL on Solana mainnet is publicly known (9SLPTL…KpKS, as stated in their docs). This transparency allows anyone to verify the total SOL reserves on Solana that back the uSOL tokens in circulation. In other words, uSOL is fully collateralized by SOL – it is not an algorithmic or fractional stablecoin, nor a synthetic derivative. It represents a claim on real SOL, held in a secure, multi-signature-like custody (via threshold signature) by the Hyperunit guardians.
Importantly, Hyperunit’s architecture is designed to avoid single-custodian risk. Unlike some wrapped tokens that entrust reserves to a single entity, uSOL’s reserve of SOL is managed by a distributed set of operators (Guardians) who must jointly authorize any movement of those funds. Hyperunit emphasizes that it is “neither custodian-based nor reliant on synthetic assets,” but rather a native tokenization layer bridging SOL into Hyperliquid. This means users maintain self-custody in the sense that no centralized exchange or third-party holds their SOL; instead, a decentralized protocol (the guardian network) locks the SOL on-chain and issues uSOL. As a result, each uSOL is always redeemable for 1 SOL, assuming the system operates correctly and guardians faithfully hold the collateral. The known collateral addresses and on-chain verifiability of reserves provide some assurance that the uSOL supply is fully backed at all times (users can observe the Solana address balance to confirm that it matches total uSOL outstanding).
A.1.2 Fee and Revenue Sources
Hyperunit does not charge explicit fees for minting or redeeming uSOL beyond the necessary network transaction costs. In other words, the protocol’s goal is to provide the bridge at minimal cost to the user, only passing along the underlying blockchain fees. When a user performs a deposit or withdrawal, they are responsible for the standard transaction fees on the source and destination blockchains (e.g. Solana network fee, Hyperliquid network fee), but no additional fee or spread is taken by Hyperunit itself. The documentation explicitly states that “Unit does not collect revenue from deposits or withdrawals – we aim to offer the lowest cost possible. The ‘fees’ associated with an operation are those required to process the transactions on their respective networks.”.
This fee structure implies that Hyperunit’s revenue model is not based on bridge tolls. Instead, the incentive for the Hyperliquid ecosystem is indirect: by making it cheap and easy to bring assets like SOL onto Hyperliquid (as uSOL) for trading, the platform can attract higher trading volume and user activity, which in turn generates revenue through trading fees on the exchange. For the users, the only costs incurred during a deposit or withdrawal are: (a) the fee to send SOL on Solana to the deposit address, and (b) the fee for the guardians to send the redemption transaction on Solana (for withdrawals). These fees are typically minor network fees; for example, current fee estimates show only a few million lamports (fractions of a cent in SOL) are required for Solana transaction processing. Hyperunit provides an API endpoint to estimate the prevailing fees on each network, so users know the expected cost and timing for deposits/withdrawals.
Because Hyperunit itself does not impose extra charges, there are no direct revenue streams like seigniorage or profit from uSOL issuance. All uSOL are issued and redeemed at parity (1 uSOL for 1 SOL), and the protocol’s objective is to minimize friction. This fee-less model can be seen as an incentive for users to utilize uSOL, as they can move assets in and out without worrying about heavy bridge fees. It’s worth noting that Hyperliquid may run trading reward programs or loyalty point schemes (e.g. users can earn Hyperliquid points for activity), which could indirectly incentivize bringing assets like SOL into the ecosystem, but the bridge itself remains simply a utility and not a profit center.
A.1.3 Minting and Redemption Flow
Minting uSOL (Deposit Flow): To mint uSOL, a user deposits SOL from Solana into Hyperunit’s system. This process is initiated by the user in the Hyperliquid or Hyperunit interface by selecting Solana (SOL) and generating a unique deposit address. Hyperunit’s guardian network uses a threshold signature scheme to derive a unique Solana deposit address tied to the user’s Hyperliquid account. The user then transfers their SOL to this deposit address, just like sending a regular SOL transaction. Once the deposit transaction is detected by the guardians, it goes through a confirmation and verification process. The protocol waits for a sufficient number of Solana confirmations (currently 32 blocks on Solana) to ensure the deposit is final and cannot be reverted. Each guardian independently monitors Solana’s blockchain (via their own Solana node/indexer) and validates that the deposit to the correct address has occurred and is irreversible.
After finality, the guardians coordinate to mint the corresponding uSOL on Hyperliquid. On Hyperliquid’s side (the destination), a transaction is constructed to credit the user’s Hyperliquid wallet with an equivalent amount of uSOL. All guardians perform additional checks (e.g. ensuring the source address is not sanctioned or blacklisted) before approval. The guardians then reach consensus and collectively sign the mint transaction using a 2-of-3 threshold signature (MPC) scheme. Once the threshold signature is produced, the mint (deposit credit) transaction is broadcast to the Hyperliquid network. Hyperliquid itself is a high-throughput chain; however, Hyperunit still enforces a confirmation period on Hyperliquid (currently 10 Hyperliquid blocks) to consider the operation finalized. After this finalization, the user’s Hyperliquid balance shows the new uSOL, and the deposit operation is marked complete. At this point, the user effectively has an IOU for their original SOL, now in the form of uSOL, which can be traded or used on Hyperliquid as if it were native SOL.
Behind the scenes, after a deposit is credited, Hyperunit will often sweep the deposited SOL from the one-time deposit address into a central treasury address for better security and management. This means the SOL originally sent by the user doesn’t remain isolated at the deposit address indefinitely; it is consolidated (via another on-chain transaction) into the main Solana reserve address controlled by the guardians. This sweep is also performed by the guardians under consensus and ensures that the collateral is held in a small number of secure addresses. The sweeping process does not affect the user’s credited uSOL, but it optimizes custody on the Solana side.
Redemption of uSOL (Withdrawal Flow): Redeeming uSOL for SOL is essentially the reverse process. The user initiates a withdrawal by specifying a Solana recipient address (where they want the SOL delivered) and the amount of uSOL to redeem. On Hyperliquid, the user will execute a transfer of uSOL to a designated withdrawal address or smart contract that signals the guardians to process a withdrawal. The Hyperunit system identifies a withdrawal request by detecting this on-chain event in Hyperliquid (a transfer of uSOL to the Unit protocol’s withdrawal account). Just like deposits, withdrawals require confirmations on the source side (Hyperliquid chain) – Hyperunit currently waits for 5000 block confirmations on Hyperliquid to ensure the withdrawal request is well-finalized and not subject to reorgs. Once finalized, the guardians prepare the corresponding SOL transaction on the Solana network: this will transfer the specified amount of SOL from the treasury to the user’s provided Solana address.
However, to manage throughput and network load, Hyperunit employs a withdrawal queue and batching mechanism for many blockchains. Solana has fast block times, but for consistency Hyperunit may still queue Solana withdrawals in timed batches (the documentation explicitly mentions batching every ~3 blocks for Bitcoin and ~21 slots for Ethereum; Solana’s interval would be analogous, likely a short interval given Solana’s speed). When the withdrawal comes up in the queue, the guardians collectively sign the Solana transaction releasing the SOL. The 2-of-3 MPC signature is applied to the Solana treasury’s private key shares, so that a valid Solana signature is produced without any single guardian ever holding the full key. The SOL is then sent on-chain to the user’s Solana address, and the guardians mark the uSOL withdrawal as completed.
During this process, Hyperunit subtracts the Solana network fee for the transaction from the withdrawn amount (or otherwise ensures the fee is covered), since the user must ultimately pay for the on-chain execution. In practice, the SOL withdrawal fee is tiny (~0.000008 SOL as of recent estimates). After broadcasting the SOL transaction, Hyperunit will also update the uSOL supply (burning the uSOL that was redeemed). The user should then see the SOL appear in their wallet on Solana after the standard Solana block confirmations (Solana confirmations are near-instant finality due to its design, so effectively the user receives SOL almost immediately once guardians broadcast).
Both deposit and withdrawal flows are orchestrated by a deterministic state machine running off-chain within the guardian network. Each step (detection, waiting for confirmations, signing, broadcasting, etc.) is performed in order by all guardians, ensuring that at least a majority have validated every condition before proceeding. This design minimizes race conditions and ensures consistency (e.g., a withdrawal will not be signed unless the corresponding uSOL burn on Hyperliquid was seen by all guardians, etc.). If anything abnormal is detected (such as mismatched amounts, or a potential double spend), guardians will not sign and can even trigger safety halts (see circuit breakers in Section B.2).
In summary, minting involves locking SOL and minting uSOL on Hyperliquid, and redemption involves burning uSOL and releasing SOL on Solana. Both operations are atomic from the user’s perspective (deposit → receive uSOL; redeem → receive SOL) but are underpinned by a robust cross-chain coordination protocol to ensure security and correctness at each stage.
A.1.4 Fee Structure and Incentives
Fee Structure: As noted above, Hyperunit’s fee structure is very straightforward – it is essentially fee-free aside from mandatory network costs. Users do not pay any spread or commission to Hyperunit when converting between SOL and uSOL. Instead, the user only pays the on-chain transaction fees for the deposit and withdrawal operations. For a deposit: the user pays the Solana transaction fee to send SOL into the deposit address (this is paid in SOL to Solana validators). For a withdrawal: the user effectively pays the Solana network fee for the guardians’ transaction out of the reserve (this may be deducted from the withdrawn amount or requires the user to leave a tiny bit to cover it). Additionally, on the Hyperliquid side, the deposit and withdrawal trigger transactions on Hyperliquid’s ledger — Hyperliquid’s chain currently has negligible fees (or the protocol might subsidize them) so this cost is minimal. Hyperunit provides an API to estimate fees and processing times on each supported chain, reflecting current network conditions. For instance, if Solana is congested or Bitcoin fees spike, the API would show higher fees and perhaps longer estimated times. This transparency helps users plan their transfers.
Because Hyperunit’s own fee is zero, there is no direct monetary incentive extracted from users at the bridge level. This aligns with Hyperliquid’s strategy: the presence of assets like uSOL on the exchange boosts trading volume and platform liquidity, which indirectly benefits Hyperliquid (trading fees, ecosystem growth) without needing to nickel-and-dime the deposit/withdrawal process. It is a user-friendly approach that lowers the barrier for on-boarding capital.
Incentives: Currently, there are no native token incentives or yield rewards specific to holding or using uSOL – it is intended to track SOL 1:1, not to provide an extra yield or staking reward. (Notably, uSOL itself is not a staked SOL derivative; it’s a liquid, instant redeemable asset, so it does not earn Solana staking returns.) The primary incentive for users is the utility uSOL provides: it enables participation in Hyperliquid’s high-performance on-chain order book and DeFi ecosystem using SOL value, with the ability to easily go back to native SOL. In a sense, uSOL inherits whatever incentives Hyperliquid offers for trading and liquidity provision. For example, if Hyperliquid has reward programs (like trading competitions or point systems for active traders), users bringing SOL into Hyperliquid (as uSOL) to trade can indirectly benefit from those. In one example from a DeFi strategy built on Hyperliquid, participants depositing uSOL to a yield strategy also accrued HyperUnit points as a reward, highlighting that active use of uSOL can tie into Hyperliquid’s broader incentive framework. These points or rewards are part of Hyperliquid’s exchange incentive program, not a property of uSOL itself.
From the protocol’s perspective, guardians and operators are incentivized to maintain the system’s integrity because Hyperunit’s success drives Hyperliquid’s success. The initial guardians include the Hyperliquid team and partners (discussed later), who have a vested interest in the platform growth rather than direct fee revenue. It’s possible that in the future, if the guardian network decentralizes further, there could be a fee model or a token to reward guardian operators for their service. As of now, however, no such token or fee exists; the service is run presumably by stakeholders funded through other means (e.g., Hyperliquid’s revenues or investment backing).
In summary, Hyperunit’s fee structure is extremely low-cost for users, and the incentives are aligned with increasing Hyperliquid usage rather than extracting fees. This user-aligned model encourages more SOL holders to bring liquidity on-platform via uSOL, which benefits the overall ecosystem (even if the bridge itself isn’t a profit center). It’s a trade-off where security and trustworthiness of the bridge must remain very high, since the protocol isn’t compensated per transaction; any loss of trust (e.g., an incident) would harm Hyperliquid’s reputation and volumes, which is presumably a far greater cost.
A.1.5 Off-Chain Components
While the end result of using uSOL is visible on-chain (SOL locked on Solana, uSOL tokens minted on Hyperliquid), much of the Hyperunit protocol’s logic resides off-chain in a coordinated network of servers called the Guardian Network. These off-chain components are critical to the system’s design and introduce certain trust assumptions (which we will evaluate in risk sections). Here we describe the key off-chain elements:
• Guardian Network:
The core of Hyperunit is a small set of independent guardians (initially three) running the Hyperunit Agent on secure servers. They monitor supported blockchains and collectively execute bridge actions. One guardian acts as leader to propose operations; the others independently verify. Communication is broadcast via a lightweight relay that only forwards encrypted messages and holds no keys. Even if the relay fails or is compromised, secrets are not exposed and funds remain protected, since all sensitive operations occur inside enclaves.
• Blockchain Nodes & Indexers:
Each guardian runs its own full nodes and indexers for every supported chain (e.g., Solana, Ethereum, Bitcoin). This lets every guardian independently detect deposits, track confirmations, and validate events. No single oracle or watcher is trusted. A false deposit would require multiple guardians to be deceived in the same way, materially reducing the risk of spoofed or incorrect credits.
• Agent Software (Protocol Engine):
Each guardian runs identical agent software that enforces the protocol:
– Chain Service: watches blockchains, verifies finality, and constructs outgoing transactions.
– State Machine / Flow Manager: enforces the ordered lifecycle of each operation (detect → confirm → agree → sign → execute), preventing shortcuts or unilateral actions.
– Consensus Service: enforces the threshold quorum (currently 2-of-3) on both data and execution; if guardians disagree, the operation halts.
– Wallet Manager (MPC): controls signing via threshold cryptography. Private keys are split into shards held by guardians and used only inside secure enclaves (e.g., Nitro). Signatures are produced jointly without ever reconstructing the full key.
• Off-Chain Compliance Layer:
Guardians apply sanctions screening, geo-blocking, and related policy checks before processing deposits or withdrawals. These controls are enforced off-chain using external lists and heuristics. This supports regulatory alignment but makes the system explicitly permissioned and not fully censorship-resistant.
• User Interface & APIs:
Hyperunit is accessed through a centralized web UI and guardian APIs, which handle deposit address generation, status updates, and error reporting. Advanced users can integrate directly with the APIs, but they remain a central dependency. For most users, the UI and Hyperliquid interface abstract away the off-chain complexity while aggregating confirmations, queues, and operation states.
Summary of Off-Chain Trust: All these off-chain components mean that uSOL’s issuance and redemption rely on an external consensus (the guardian network) rather than a trustless on-chain contract. The upside is flexibility and performance – deposits can be from non-EVM chains (Bitcoin, Solana), and the process can include sophisticated logic (threshold signatures, batching) that might be impossible or inefficient to do purely on-chain. The downside is that users must trust that the guardian network is honest and secure. The guardians collectively act as the decentralized custodian of the SOL collateral and the oracle informing Hyperliquid of deposits. Thus, the design is often described as “non-custodial” in that no single party holds funds, but it’s not trustless in the same way a smart contract on Ethereum would be – trust is distributed among the guardians. This will be discussed more in the risk analysis (Part II).
B. System Design
B.1 Monitoring and Observability
A critical aspect of any asset-backed token system is the ability for users and third parties to monitor the backing collateral and overall system health. Hyperunit provides certain avenues for transparency, though some components remain opaque by nature of being off-chain.
First, as mentioned, the reserve addresses on each source chain are publicly known, which is a cornerstone of observability. For uSOL, one can look up the Solana treasury address in a Solana block explorer and see the balance of SOL held. Likewise, Hyperunit publishes addresses for its Bitcoin and Ethereum reserves in its docs. This means that at any time, the community can audit that the amount of SOL held in custody is at least equal to the total uSOL supply. On Hyperliquid’s side, uSOL exists as a token on both the HyperCore (native exchange chain) and HyperEVM environments. The total supply of uSOL on HyperEVM is visible via the token contract (address 0x068f…A29) which anyone can query. On HyperCore (the non-EVM chain), uSOL is a native asset with a known token index (254) and a maximum supply parameter (500 million set as an upper bound). While HyperCore doesn’t have a public block explorer in the traditional sense, Hyperliquid does expose APIs and data on asset balances, so one can observe how much uSOL is in circulation. In short, the peg backing is verifiable: e.g., if there are X uSOL in existence, the Solana address should also hold ~X SOL (minus any slight differences due to fees or timing of sweeps).
Furthermore, Hyperunit and community contributors have built dashboards for real-time monitoring. One notable example is the HyperDash Unit dashboard, which compiles data on deposits, withdrawals, and total flows. According to an analysis by OAK, “Thanks to the HyperDash dashboard (unit.hyperdash.info), users can monitor all flows handled by Unit.”. This dashboard visualizes metrics like cumulative inflows of each asset, recent volumes, and even comparative stats (showing, for instance, that Hyperliquid became the #1 DEX for native BTC spot volume largely due to Unit bridging BTC onto the platform). For uSOL specifically, one could see the total SOL brought in and out via Unit over time. As of mid-2025 (a few months post-launch), the dashboard indicated substantial usage – for example, over 1,182 BTC and 9,619 ETH had been bridged into Hyperliquid in the first four months for trading, and Solana integration (uSOL) was also live, likely contributing similarly. Such statistics demonstrate both the utility and the scale of assets under management, which is directly relevant to risk (higher TVL makes it a bigger target for exploits, and necessitates stronger monitoring).
Figure 1: Simplified architecture of the Hyperunit system, showing the off-chain Guardian Network coordinating between external blockchains (like Solana) and the Hyperliquid platform. Guardians independently monitor deposits on L1 chains and reach consensus to mint or burn tokens on Hyperliquid.
User-facing observability:
Users get real-time status updates via the UI and APIs. After depositing SOL, they can track stages like “waiting for confirmations” or “minting in progress.” Hyperunit also exposes endpoints such as GET /withdrawal-queue, showing queued withdrawals and the last processed transaction per network. This gives users visibility into whether their withdrawal is batched and roughly where it sits, reducing uncertainty and support overhead.
Structural opacity:
Guardian operations are off-chain and not directly observable. Users don’t see individual guardian checks or signatures—only the final on-chain result (mint or release). Deterministic execution means a completed operation implies consensus was reached; failures usually surface only as delays or stuck transactions. In those cases, users must rely on support channels or status announcements, unlike fully on-chain bridges where failure modes are visible in smart contract events.
Auditability limits:
While Hyperunit has disclosed its high-level security design (MPC, enclaves, guardian model), the guardian software is not open source. This constrains independent verification and shifts trust to external audits and team credibility. The Zellic audit provides transparency on the on-chain contracts, but the off-chain guardian logic remains largely opaque. Guardians maintain internal logs and audit trails, but these are not publicly accessible in real time.
In summary, Hyperunit offers a moderate level of transparency: the collateral is on-chain and checkable, key metrics and flows are tracked by dashboards, and users have tools to check the status of their transactions. However, the core consensus process among guardians is opaque by necessity, which requires a level of trust. The current guardian set is known (Hyperliquid and partners), which at least means the actors are accountable to their reputations. But from an exterior point of view, the opaqueness is that one must trust that these known entities are following the protocol and not colluding or deviating, since one cannot “watch” the guardian consensus on-chain. This is a typical trade-off in such bridge designs – they prioritize performance and cross-chain flexibility at the cost of some transparency, unlike purely on-chain light-client bridges that put all logic on-chain (but those are limited to certain ecosystems and often slower). Users and observers should therefore monitor both the on-chain reserves and any available off-chain status indicators (like official dashboards or announcements) to remain confident in uSOL’s backing and operation.
B.2 System Architecture
The Hyperunit / uSOL architecture is security-first and structured in layers: on-chain assets (SOL, uSOL), an off-chain guardian network, and hardened security infrastructure (MPC, enclaves). Together, these balance decentralization with operational control.
• Distributed Guardians & Consensus:
The system currently runs with N=3 guardians (Unit, Hyperliquid, Infinite Field) using a 2-of-3 threshold. Any mint or release requires two independent approvals, preventing unilateral control and tolerating one faulty or malicious node. A threshold signature scheme (TSS) ensures no single guardian can forge transactions. Guardians run a deterministic state machine in lockstep; if one deviates, the others refuse to sign, halting the operation.
• Secure Key Management (MPC + Enclaves):
Reserve keys are split into shards held by guardians and never reconstructed. Signing is done jointly via MPC inside hardware enclaves (e.g., AWS Nitro), so even a compromised server cannot extract key material. No machine ever sees the full private key, significantly reducing key-theft risk versus standard multisigs.
• Strict Protocol Logic & Circuit Breakers:
Guardians independently verify deposits (confirmations, formatting, blacklists, minimums, etc.). Only if all checks pass does processing continue. The system includes rate limits and emergency halts: if invariants break or suspicious behavior appears, the bridge can automatically pause and require manual intervention.
• Secure Communication:
All guardian-to-guardian communication is end-to-end encrypted with pre-shared identities. A relay may forward messages but cannot read or forge them. Even if the relay fails, safety is preserved (though liveness may degrade).
• Redundancy & Roadmap:
With 2-of-3 consensus, the bridge continues operating if one guardian is offline. It cannot tolerate two failures. Future plans include expanding the guardian set (e.g., 3-of-5) to improve decentralization and fault tolerance.
• Deep Integration with Hyperliquid:
uSOL is native on HyperCore (for spot trading) and mirrored as an ERC-20 on HyperEVM. Guardians mainly handle external L1 ↔ HyperCore bridging; transfers between HyperCore and HyperEVM are handled by Hyperliquid’s own chain logic. This tight integration enables fast settlement and native use of uSOL as collateral.
• Compliance & Policy Layer:
Guardian software embeds sanctions and geofencing checks. Deposits from blocked entities are not processed. These controls are enforced collectively by guardians rather than a single admin key. This makes the system explicitly permissioned at the policy level, aligning it with regulatory requirements but reducing neutrality and transparency.
In summary, Hyperunit’s architecture is a carefully balanced combination of decentralization (a small consortium of nodes), advanced cryptography (MPC, TSS, enclaves), and practical engineering (state machines, batching). It is designed to maximize security (by eliminating single points of failure in key storage and validation) and to maintain high performance (by using off-chain coordination to avoid expensive on-chain verification of external chains). The system architecture succeeds in making uSOL feel like a native part of Hyperliquid – deposits and withdrawals are relatively fast (finalized in minutes), and within Hyperliquid, uSOL behaves just like SOL would (fast trading, instant settlement). The cost is that the architecture introduces a trusted intermediary layer (the guardians), which we will analyze for risks in Part II. Nonetheless, as a piece of infrastructure, Hyperunit is a novel design pushing toward decentralized custody of non-native assets. It operates with a philosophy that even though it’s not fully trustless, it’s transparent and robust enough that users can trust it more than a centralized custodian, and it can be progressively decentralized over time.
