Audit name:
[SCA] Aurora Labs / Defuse Contracts / Dec2024
Date:
Jan 27, 2025
Table of Content
Introduction
We express our gratitude to the Aurora Labs Limited team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
NEAR Intents is a protocol for multichain financial products built by Aurora.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Aurora Labs Limited |
| Audited By | Stepan Chekhovskoi |
| Approved By | Olesia Bilenka |
| Website | https://aurora.dev→ |
| Changelog | 20/01/2025 - Initial Report |
| 27/01/2025 - Second Report | |
| Platform | NEAR |
| Language | Rust |
| Tags | DeX, DeFi |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Aurora Labs Limited
- Audited By
- Stepan Chekhovskoi
- Approved By
- Olesia Bilenka
- Website
- https://aurora.dev→
- Changelog
- 20/01/2025 - Initial Report
- 27/01/2025 - Second Report
- Platform
- NEAR
- Language
- Rust
- Tags
- DeX, DeFi
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/near/intents→ |
| Initial Commit | 160ba5829fea636283375ec462042d51409a6e66 |
| Second Commit | 91fee5e119fd74d8de1dbb57d27060873a0ae503 |
Review Scope
- Repository
- https://github.com/near/intents→
- Initial Commit
- 160ba5829fea636283375ec462042d51409a6e66
- Second Commit
- 91fee5e119fd74d8de1dbb57d27060873a0ae503
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional overview is provided.
Detailed functional requirements are missing.
Technical description is partially provided.
Code quality
Development environment is set up.
Code lacks comments essential for complex architecture understanding.
Code follows best coding practices.
Test coverage
Code coverage of the project is 22% (region coverage).
Core functionality and user interactions are tested.
Negative cases coverage is partially missed.
System Overview
NEAR Intents allows users to create and manage their crypto portfolios, provides functionality of token swap directly connecting demand side with available liquidity provider. The protocol is deployed on NEAR blockchain.
NEAR Intents contract operates over signed intents what simplifies onboarding, allows users to delegate transaction execution and pay for Gas in various tokens. NEAR Intents contract supports ERC-191 (Ethereum wallets compatible), NEP-413 (NEAR wallets compatible), Raw Ed-25519 (Solana wallets compatible) signature types.
Onboarding Process
Sending FT, NFT, or MT directly to the NEAR Intents contract causes appropriate callback is executed, the funds are wrapped into Multi Token Standard and are available for further actions.
Additionally, signed intents can be attached to the deposit and are executed immediately. This allows to deposit funds, swap, and withdraw in the same transaction.
Swap Process
The off-chain protocol part receives user request for token swap and passes it to Liquidity Providers to get a quote.
The best quote is provided back to the user and the user signs the proposed amount.
The signed intents are passed to the smart contract by the off-chain system part.
The NEAR Intents contract validates the token balances delta over all intents is not negative and updates the actor balances.
It need to be noted here that the off-chain system part is not privileged user in the smart contract. The system is expected to integrate multiple request solvers and liquidity providers. Alternative off-chain modules can be run by community to avoid transactions censorship by the protocol administrators.
Admin functionalities
The contract is upgradeable.
The contract is pausable.
The contract may take fee from each FT or MT swap.
Privileged roles
The DAO is allowed to add or remove Full Access Key to the contract.
The DAO and Fee Managers are allowed to set fee rate and fee collector contract.
The DAO and Upgraders are allowed to upgrade the contract logic.
The DAO and Unrestricted Withdrawers are allowed to withdraw any funds from the contract to arbitrary location.
Potential Risks
Continuous Increase of Contract Storage Deposit: The contract allows any user to trigger storage allocation without paying for it. In terms of NEAR blockchain it is common to request Storage Deposit in NEAR (native coin) prior to allocating any storage for the user. However, the model brings difficulties in easy users onboarding, so, the development team acknowledged the risk of spreading storage by the users. The contract may reach DoS situation in case it has less funds than needed to cover the Contract Storage.
Centralization over DAO Account: The DAO account is expected to be Multi-signature wallet controlling the system. The account is given wide permissions such as funds withdrawal to arbitrary destination and the smart contract upgrade.
Callback Failure causes Funds Lock: The asynchronous nature of NEAR blockchain creates difficulties in error handling at third-party contracts execution. The system accepted possibility of funds being locked in case withdrawal was not successful due to abnormal Gas usage by the token contract. Considering simulating the transaction and attaching enough Gas to the withdrawal transaction.
JSON Redundant Fields: The system parses signed messages payload as JSON. The payload may contain additional fields ignored by the smart contract which may potentially mislead the user regarding which action the message authorize.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8343 | Lack of Full Access Key Verification for Fee Update | fixed | Medium | |
| F-2025-8345 | Native Balance Exhausting due to Unpaid Storage Increase | accepted | Medium | |
| F-2025-8338 | Profitable intents Interception due to Front Running | mitigated | Medium | |
| F-2025-8337 | Inability to Execute Swap due to Fee Calculation Mechanism | fixed | Medium | |
| F-2025-8339 | Lack of Signed Payload Versioning | accepted | Low |
Identify vulnerabilities in your smart contracts.
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/near/intents→ |
| Initial Commit | 160ba5829fea636283375ec462042d51409a6e66 |
| Second Commit | 91fee5e119fd74d8de1dbb57d27060873a0ae503 |
| Whitepaper | N/A |
| Requirements | https://docs.near-intents.org→ |
| Technical Requirements | README.md |
Scope Details
- Repository
- https://github.com/near/intents→
- Initial Commit
- 160ba5829fea636283375ec462042d51409a6e66
- Second Commit
- 91fee5e119fd74d8de1dbb57d27060873a0ae503
- Whitepaper
- N/A
- Requirements
- https://docs.near-intents.org→
- Technical Requirements
- README.md
Assets in Scope
bitmap/src/lib.rs
core/src/accounts.rs
core/src/deadline.rs
core/src/engine/inspector.rs
core/src/engine/mod.rs
core/src/engine/state/cached.rs
core/src/engine/state/deltas.rs
core/src/engine/state/mod.rs
core/src/error.rs
core/src/events.rs
core/src/fees.rs
core/src/intents/account.rs
core/src/intents/mod.rs
core/src/intents/token_diff.rs
core/src/intents/tokens.rs
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.