Atlasprotocol Atlasprotocol risks
Atlas Protocol's native Bitcoin liquid staking model exposes atBTC holders to the contracts that validate deposits, issue tokens, and return BTC. NEAR Chain Signatures and optional DeFi positions add dependencies. Historical audit findings document contract vulnerabilities and subsequent fixes; current availability for real-BTC deposits and redemptions remains unconfirmed.
When a recorded status exceeds the actual transfer
During its October 14-25, 2024 engagement, Halborn examined Atlas's NEAR contracts and atBTC token contracts for NEAR and EVM. Its Atlas NEAR assessment identified a missing transaction-verification control in HAL-06. A privileged admin could supply arbitrary transaction hashes because the reviewed code did not check the relevant NEAR/EVM mempool for minting or the Bitcoin mempool for redemption. A deposit could consequently be recorded as minted, or a redemption as complete, without the corresponding asset delivery.
HAL-06 is listed as solved on January 9, 2025. A stored transaction hash alone does not prove confirmed receipt of atBTC or the return of BTC. Even a real transaction in a mempool still awaits confirmation.
Validation delays and conditional recovery
HAL-01 concerned the risk of BTC becoming stuck before atBTC issuance. In the reviewed implementation, minting depended on reaching the validator threshold configured for the deposit's receiving chain. Too few validations, an incorrect receiving chain, or an invalid receiving address could obstruct completion without an adequate recovery route.
Halborn lists that finding as solved on January 16, 2025. Its summary describes an emergency-withdrawal safeguard for deposits that remain invalidated after a specified period or are likely to fail because of persistent errors. These conditions distinguish recovery of a failed deposit from ordinary atBTC redemption. They do not establish a universal BTC withdrawal time.
Owner permissions and fee controls
The assessment also identified missing two-factor authentication for privileged actions and exposed functions that could reset contract state. Halborn's summary records work on authentication and removal of those reset functions. These safeguards address who can change sensitive state and which changes the contract permits.
For HAL-05, the owner could appoint their own account as admin, concentrating authority across the two roles. The findings table labels this centralization issue solved on December 18, 2024, while the remediation note describes a partial fix. That qualification limits any conclusion that administrative trust was eliminated.
Fee-setting authority is a separate concern. In the assessed code, setting the deposit fee to the permitted 100% maximum made the calculated fee equal the full deposit amount. Halborn marks HAL-10 solved, with code ceilings reduced to 3% for deposit, redemption, and bridging fees and to 10% for Babylon rewards fees. A maximum allowed by remediated code and the rate configured for a deployed instance are different values; the audit does not establish current deposit, redemption, bridging, or rewards charges.
Bitcoin backing, signing, and liquidity
Atlas describes an underlying staking arrangement involving partners such as Babylon, with NEAR Chain Signatures providing cross-chain signing. Staking supplies the intended underlying return; signing authorizes cross-chain operations. The Atlas and atBTC contracts still need to handle deposit validation, token issuance, and redemption correctly.
The documented 1:1 issuance relationship between BTC and atBTC does not establish a guaranteed secondary-market price or available buyers. Returning to BTC through redemption depends on the protocol's redemption path, while selling atBTC depends on a market. Additional income from a DeFi position carries that application's dependencies alongside the underlying staking arrangement.
How atBTC positions add dependencies
Atlas's Footprint public-testnet quest ran from March 25 to June 5, 2025. It named atBTC lending, USDC borrowing, and an atBTC/wBTC liquidity pool on Rhea Finance. The lending, borrowing, and pool uses below refer to that test environment, with simulated assets.
| Position | Contracts or assets involved | Risk implication | Documented scope |
|---|---|---|---|
| Holding atBTC | Atlas core and atBTC token contracts | Token issuance and BTC recovery depend on the core protocol's behavior. | NEAR and EVM token contracts covered by the 2024 assessment |
| Lending atBTC | Rhea Finance lending market in addition to atBTC | Access to supplied atBTC also depends on the lending market. | 2025 Rhea Finance public-testnet task |
| Borrowing USDC using atBTC | Lending-market contracts and collateral-backed debt | The position adds the market's collateral and repayment rules. | 2025 Rhea Finance public-testnet task |
| Providing atBTC/wBTC liquidity | Rhea Finance pool, atBTC, and wBTC | The position adds pool-contract and paired-asset dependencies. | atBTC/wBTC pool specified in the public-testnet quest |
The testnet tasks establish the intended position types. They do not establish production-market parameters, real-fund withdrawal liquidity, or a guaranteed return.
The boundary of the audit evidence
Halborn's report marks all 25 reported findings solved, subject to the partial-remediation wording for centralization described above. Its scope excludes third-party dependencies, economic attacks, and new implementations after the remediation commits. A risk conclusion for a live deployment therefore needs a match between its deployed code, permissions, and chain-specific settings and the relevant assessed changes. The historical report cannot extend its coverage to a lending market, liquidity pool, or staking partner.
Updated on