Is Allora (ALLO) Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Audit History

2 audits on record

Jul 2391

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

This audit focuses on the provided OpenZeppelin ERC1967 Transparent Proxy contract. The proxy itself utilizes well-audited and standard components. However, the critical finding is that the source code for the underlying implementation contract (AlloOFTUpgradeable) is unverified, preventing a comprehensive security assessment of the system's core logic. Additionally, while upgrade control is managed by a multisig, the absence of a timelock for upgrades introduces a higher operational risk.

Final Recommendation: Prioritize verifying and thoroughly auditing the source code for the `AlloOFTUpgradeable` implementation contract to ensure its security and integrity. Implement a timelock mechanism for all critical administrative operations, especially contract upgrades, to provide a delay period for public scrutiny and emergency response. Regularly review and update multisig signers and their security practices to maintain robust access control over the system's upgradeability.

Category Ratings

TechnicalMedium

4/10

The proxy contract (ERC1967Proxy) is built upon battle-tested OpenZeppelin libraries, ensuring a robust foundation for its core functionality (7.2 Code Security). The architecture correctly implements the EIP-1967 standard for storage slots, minimizing collision risks (7.1 Architecture). However, a

GovernanceHigh

1/10

The governance model for upgrades employs a 2-of-3 multisig for the `ProxyAdmin` (7.5 Governance), which is a strong access control mechanism, reducing the risk of a single point of failure (7.3 Access Control). This setup requires multiple approvals for critical operations like upgrades. However, t

UpgradesHigh

1/10

The system utilizes the EIP-1967 Transparent Proxy pattern, a well-established and secure method for upgradeability (7.7 Upgrades). This pattern correctly separates the admin interface from the implementation, preventing function selector clashes. Upgrades are controlled by a 2-of-3 multisig, enhanc

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin → Multisig 2-of-3

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

What Raised This Score

12 factors

Ownership NOT renounced — Multisig (2-of-3)
Mintable supply — no cap found, dilution unbounded
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 70% (93.4% total → 89.6% effective; 87.0% in EOAs, 6.3% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $10k ($6,113 across 2 pairs — easily drained)
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium finding(s) from audit
1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Findings

4 total

1 Critical 1 High 1 Medium 1 Low

C-01CriticalUnresolved

Unverified Implementation Contract Source Code

The core logic of the system resides in the implementation contract (AlloOFTUpgradeable at 0xb21c7c5a7be430ea3517892e63f905c109b06278), but its source code is not publicly verified. This prevents any security assessment of the actual business logic, making it impossible to identify vulnerabilities such as reentrancy, access control flaws, or economic exploits. Users and auditors cannot independently verify the contract's behavior or safety.

Recommendation: Immediately verify and publish the source code for the `AlloOFTUpgradeable` implementation contract on block explorers. Conduct a thorough security audit of this implementation contract to identify and remediate any vulnerabilities. Ensure that all future implementation upgrades also have their source code verified.

H-01HighUnresolved

Lack of Timelock for Critical Operations (Upgrades)

While the upgrade mechanism is controlled by a 2-of-3 multisig, there is no timelock in place for executing upgrades. This means that once the required multisig approvals are obtained, an upgrade can be deployed instantly. This lack of a delay period prevents users, the community, or automated monitoring systems from reacting to a potentially malicious or erroneous upgrade before it takes effect, increasing the risk of irreversible damage or fund loss.

Recommendation: Integrate a timelock contract into the upgrade process. The `ProxyAdmin` should be owned by a timelock, which in turn is controlled by the multisig. This ensures that any proposed upgrade has a mandatory delay period (e.g., 24-72 hours) before it can be executed, allowing for review and potential intervention.

M-01MediumUnresolved

Reliance on External Contracts for Core Logic

The security and functionality of the entire system are entirely dependent on the `AlloOFTUpgradeable` implementation contract. Any vulnerability within this external contract, whether due to design flaws, coding errors, or malicious intent, will directly impact the proxy and its users. This risk is exacerbated by the unverified source code of the implementation.

Recommendation: Ensure rigorous security practices for the development, testing, and auditing of the implementation contract. Implement robust monitoring for the implementation contract's behavior and state. Consider formal verification or extensive fuzzing for critical components of the implementation.

L-01LowUnresolved

Centralized Upgrade Authority

Although the upgrade authority is managed by a 2-of-3 multisig, this still represents a centralized point of control. If a majority of the multisig signers are compromised, collude, or act maliciously, they could unilaterally upgrade the contract to a harmful implementation, potentially leading to loss of funds or system compromise.

Recommendation: While a multisig is a strong control, consider further decentralizing the upgrade authority over time, possibly by integrating a more distributed governance mechanism or a larger, more diverse set of signers. Implement strict operational security procedures for all multisig signers, including hardware wallets, secure key management, and multi-factor authentication.

Is Allora Safe? ALLO