Leather Info
Leather is the fastest and most cost-efficient way to move native Bitcoin between chains, without giving up custody.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is upgradeable
The contract uses a proxy pattern or similar mechanism, enabling future upgrades. This can introduce risks if the upgrade mechanism is not securely managed.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The Leather contract implements a swap router and proxy system with upgradeability, permit support, and sweep functionality. While the overall design follows common patterns on Ethereum, a few areas need attention:
- Centralization Risk: The contract uses
delegatecallto an owner-controlledswapTarget. This allows the owner to execute arbitrary code in the contract's context, posing a significant trust risk. - Fund Safety: The
rescueFundsfunction allows the owner to withdraw all assets, including ETH that belongs to users waiting for refunds. - Input Validation: There are missing checks for
msg.valuein ERC20 swaps and missing contract checks for output tokens, which could lead to accidental fund loss or slippage bypass.
Ownership Privileges
The ownership of the contract has been centralized in a single account (or two, if Proxy Admin and Owner are different). The owner retains full privileges including:
- Upgrading the contract implementation logic via the Proxy.
- Setting the
swapTargetaddress, enabling arbitrary code execution. - Rescuing any amount of ETH or ERC20 tokens held by the contract.
- Transferring ownership to a new address.
- Limitation: Cannot mint new tokens (this is a router, not a token).
- Limitation: Cannot burn user funds directly (though
rescueFundseffectively allows seizing them). - Limitation: Cannot pause the contract or freeze transfers.
- Limitation: Cannot blacklist specific user addresses.
Security Features
The contract implements several positive security features:
- Reentrancy Protection: All external swap and refund functions are guarded by
nonReentrant. - Safe Transfers: The contract utilizes
SafeERC20to handle non-standard token implementations correctly. - Permit Support: Integrated support for EIP-2612 permits allows for gas-efficient, single-transaction swaps.
- Standardized Libraries: The codebase relies on battle-tested OpenZeppelin upgradeable contracts for core logic.
Note - This Audit report consists of a security analysis of the Leather smart contract system. This analysis did not include economic analysis of the contract's incentives. Moreover, we only audited the main contracts (Leather.sol and LeatherRouter.sol) for the Leather team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before interacting with the protocol.
Files and details
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Functions
public
/
State variables
public
/
Total lines
of code
/
Capabilities
Hover on items
/
Findings and Audit result
high Issues | 2 findings
Pending
#1 high Issue
Centralization Risk / Arbitrary Code Execution
When swapTarget is set to a non-legacy address, _executeInternal performs a delegatecall to it. The delegatecall executes the target's code in the Leather contract's context, granting full storage access. A malicious or compromised swapTarget can overwrite ownership, drain all funds, or self-destruct the contract. The only protection is onlyOwner on setSwapTarget.
Pending
#2 high Issue
Centralization Risk / Fund Drainage
The rescueFunds function allows the owner to withdraw any amount of any token or ETH with no restrictions. The contract holds ETH for users with pending refunds in pendingEthRefunds. The owner can call rescueFunds(address(0), address(this).balance) and drain all ETH, leaving pending refund claimants unable to withdraw their funds.
medium Issues | 4 findings
Pending
#1 medium Issue
Slippage Protection Bypass
If _tokenOut is a non-zero address that is not a contract (e.g., an EOA or destroyed contract), the _isContract check returns false and the slippage check is entirely skipped. The _amountOutMin parameter has no effect. Additionally, if _tokenOut == _tokenIn, the second slippage check branch is also skipped. Users could lose input tokens with no output protection.
Pending
#2 medium Issue
Single-Step Admin Transfer
The changeAdmin function performs an immediate, irreversible admin transfer. If the admin sets the wrong address (typo, wrong checksum, or an address the team does not control), proxy admin access is permanently lost. The proxy can never be upgraded again, which is catastrophic for an upgradeable contract.
Pending
#3 medium Issue
Centralization Risk
A single owner address controls setSwapTarget (enabling delegatecall to arbitrary contracts), clearSwapTarget, and rescueFunds (draining all assets). A single proxy admin controls changeAdmin, upgradeTo, and upgradeToAndCall. Neither role has timelock delays, multi-signature requirements, or governance oversight. A single compromised key gives full protocol control.
Pending
#4 medium Issue
Improper msg.value Handling
In the native path, the code only enforces msg.value >= _amountIn, then forwards full msg.value to the legacy target call. In the ERC20 path there is no require(msg.value == 0). This can lead to accidental overpayment and unintended ETH forwarding behavior.
low Issues | 6 findings
Pending
#1 low Issue
Missing Event
The claimPendingEthRefund function clears pendingEthRefunds[msg.sender] and transfers ETH but emits no event. The queuing emits EthRefundQueued, but claiming does not emit a corresponding event. This makes it difficult for off-chain indexers and monitoring systems to track refund claims.
Pending
#2 low Issue
Denial of Service
The _snapshotExtraTokenBalances and _forwardExtraTokenDeltas functions iterate over user-provided _extraSweepTokens and call external token contracts in a loop. A reverting token can make the entire transaction fail. This is typically user-driven self-DoS but can become protocol-level risk if a backend auto-builds these lists.
Pending
#3 low Issue
Residual Approval
When the initial permit call with exact _amountIn fails, the code falls back to a permit with type(uint256).max. After this flow, the Leather contract retains an unlimited approval from the user. While only _amountIn is transferred in this transaction, the residual approval persists. If the contract is later compromised via delegatecall or upgrade, the attacker could drain the user's entire token balance.
Pending
#4 low Issue
Floating Pragma
Both contracts use pragma solidity ^0.8.20 which allows compilation with any compiler from 0.8.20 to 0.8.x. Different versions may produce different bytecode. Additionally, ^0.8.20 enables the PUSH0 opcode (Shanghai). If deployed on L2 chains without Shanghai support, deployment will fail.
Pending
#5 low Issue
Ambiguous Initialization
The contract has two initialize function overloads: initialize(address) and initialize(address, address). Both are guarded by the initializer modifier. Whichever is called first succeeds and the other is permanently locked. If the wrong overload is called during deployment, the initial swap target may not be set, requiring a separate setSwapTarget transaction.
Pending
#6 low Issue
Unbounded Array / Gas
The _extraSweepTokens array passed to executeSwapAdvanced and executeSwapWithPermitAdvanced has no length limit. The _seenEarlier function uses O(n^2) deduplication, and both snapshot and forward functions make external calls in a loop. A very large array causes out-of-gas, wasting the caller's gas fees.
optimization Issues | 1 findings
Pending
#1 optimization Issue
Gas Optimization
The _snapshotExtraTokenBalances function allocates a new memory array and _seenEarlier uses O(n^2) nested loops for deduplication. For large sweep token lists, this is gas-intensive.
informational Issues | 4 findings
Pending
#1 informational Issue
Code Obfuscation
The legacy target address (0x1231DEB6f5749ef6Ce6943a275A1D3E7486f4EAe) is derived by XORing two hardcoded constants (_TARGET_KEY_A and _TARGET_KEY_B). This is security through obscurity and provides no protection while impairing code readability and auditability.
Pending
#2 informational Issue
Visibility
Both initialize overloads are marked public but are only called externally during proxy initialization. Using public generates additional dispatch code compared to external, wasting gas on deployment and every call.
Pending
#3 informational Issue
Missing Tests
The project contains zero test files. There is no test/ directory and no test contracts. No unit, integration, fuzz, or invariant tests exist for any function in either contract.
Pending
#4 informational Issue
Style / CEI Ordering
In rescueFunds, FundsRescued is emitted after external transfer calls. This is not a direct security issue here because onlyOwner gates the function and no sensitive post-call state mutation occurs, but reordering can improve stylistic consistency.