This proposal is for a comprehensive security audit of the Terra Classic blockchain, with a re-audit of remediated findings and a final audit report.
The audit is proposed to be conducted by SolidProof, a German blockchain security company who is also a governance approved provider of KYC.
The fixes for issues identified by the audit will be remediated by OrbitLabs, who previously completed the Cosmos SDK v0.53 upgrade for the chain. OrbitLabs will work with the auditors and develop the fixes including the necessary chain upgrade proposal to implement them.
Why an Audit?
The last audit the chain had was pre-crash on 3 September 2020. The chain has significantly changed since then, and we are in an environment with security breaches on other chains including Cosmos chains.
The chain has also been informed by partner exchanges who list LUNC and USTC that given the breaches with other Cosmos chains a security audit is required otherwise in the event of a significant security breach the status of our listing could be in jeopardy.
Scope of Audit
The scope provided by SolidProof for the audit covers:
Examination of the source code for the Terra Classic protocol, with particular focus on the seven custom modules, the thirteen Cosmos SDK module overrides, the transaction processing and fee handling chain, the application and IBC wiring, and the CosmWasm integration.
Examination of the framework migration surface introduced by the SDK53 upgrade, including all twenty upgrade handlers and the hand-written migration of the CosmWasm key-value store that executed on mainnet at block height 25,619,230.
Security assessment of the economic mechanisms as implemented: oracle vote aggregation, tally and reward distribution; treasury seigniorage and policy; burn tax collection, splitting and exemption; and dynamic validator commission enforcement.
Adversarial simulation of the protocol under fuzz, localnet and interchain conditions, including oracle manipulation, burn tax bypass, treasury drain and denial of service scenarios.
Identification of security vulnerabilities across the components in scope, with severity classification and concrete remediation guidance.
A full re-audit of the remediated code after the Client’s remediation window, with verification of each reported finding and an updated, publishable Final Audit Report.
The Audit is performed against a single frozen commit of the repository at https://github.com/classicterra/core. Development on main may continue during the engagement. Changes landing after the freeze are not in scope, save for the remediation changes.
Activities
Architecture and Threat Model: Construction of the module dependency and keeper graph, store key inventory, privilege and authorisation map, and an explicit threat model recording assets, adversaries and attack surfaces. Issued to the Client early in the engagement so that the Auditor’s assumptions can be challenged before the bulk of the review is performed.
Code Review: Review of the protocol code at the depth assigned to identify security vulnerabilities including custom module logic flaws, Cosmos SDK and ibc-go integration defects, non-determinism and state divergence hazards, incorrect fee and tax arithmetic, missing authorisation on message handlers, state migration defects, and unmetered execution paths.
Migration Verification: Differential replay of the CosmWasm store migration functions against mainnet derived key material, determinism analysis of the legacy store compatibility shim, and review of all twenty upgrade handlers against the declared store upgrades.
Risk Assessment: Evaluation of the impact and exploitability of each identified issue on the security, liveness and economic integrity of the Terra Classic protocol.
Testing and Adversarial Simulation: Dynamic testing techniques to assess protocol behaviour under adversarial conditions, including property-based and fuzz testing of oracle tally, tax computation, commission enforcement and migration key handling; localnet and interchain scenarios for IBC, mempool and governance behaviour; multi-validator misbehaviour scenarios; and the economic attack scenarios.
Reporting: Preparation of a detailed Audit Report including findings, threat analysis and remediation recommendations. The Auditor shall prepare a draft Audit Report for the Client’s review, where the Client may provide comments and request factual amendments as necessary.
Remediation Verification: A full re-audit of the Client’s remediation, feeding into the Final Audit Report.
Vulnerability Classes Targeted
The review is organised around failure modes specific to Cosmos SDK Layer 1 chains: nondeterminism and state divergence; state migration defects; transaction lifecycle and fee handling errors; authorisation and privilege defects; economic mechanism implementation errors including precision loss and manipulation resistance; CosmWasm integration defects including reentrancy and gas accounting; IBC integration defects; and node-level availability defects.
Core Focus Areas
All areas A to H are within the contracted scope of the Agreement.
A. Custom Module Implementation
• Oracle module: vote and prevote handling, ballot construction, weighted median tally, reward distribution, miss counting and slashing, and the module’s ABCI hooks.
• Treasury module: seigniorage computation and distribution, tax and reward policy updates, economic indicators, burn account operations, and governance proposal handling.
• Market module: swap mechanism, constant-product pool behaviour, pool recovery, stability spread application, and oracle price integration.
• Tax and tax exemption modules: burn tax computation, splitting to the distribution module, exemption zones and address lists, governance proposal handling, and the interaction between the two modules.
• Dyncomm module: dynamic validator commission calculation and enforcement through its ante and post decorators.
• Vesting module: custom vesting account types and their interaction with staking and bank.
B. Transaction Processing and Fee Handling
• Composition and ordering of the custom ante handler chain, and the consequences of that ordering for authentication, gas metering and fee deduction.
• Correctness of fee and burn tax computation, including rounding and truncation direction, precision loss, and interaction with fee grants.
• The custom post handler chain and its state effects.
• Oracle vote spam prevention, IBC transfer spam prevention and minimum initial deposit enforcement, including correct separation of CheckTx-only from consensus-relevant behaviour.
• The custom transaction service and its compatibility layer.
C. Framework Migration and State Integrity
• The hand-written migration of the CosmWasm key-value store from the forked key layout to the upstream layout, including contract keys, code keys, contract storage keys, contract history, secondary indexes, sequence keys and params. Particular attention to the length-prefix and composite-key heuristics applied to attacker-influenced contract storage keys.
• The legacy store compatibility shim serving historical queries across the migration height, including its determinism on the contract execution path and its implications for archive node replay.
• All twenty upgrade handlers, the declared store upgrades against the actual store keys, handler idempotency, and the effect of handlers that reset module parameters.
• Height-conditional and chain-ID-conditional branches on the consensus path.
• Retained fork logic and the conditions under which it could be re-registered.
D. Cosmos SDK Override Layer
• All thirteen module overrides, with emphasis on the wasm, staking, bank and governance overrides, and on the legacy query servers and message services retained for backward compatibility.
• Correctness of the module manager ordering for PreBlock, BeginBlock, EndBlock and InitGenesis.
• Module account permissions and the blocked address set.
• The authority address on every parameter update message.
E. CosmWasm Integration
• The custom query and message plugins, including the Stargate query allow-list and its deterministic-response requirement.
• Reentrancy and state consistency across the virtual machine boundary, and gas accounting across that boundary.
• The custom wasm message service retained from the legacy chain.
• The migration surface introduced by wasmd 0.46 to 0.61 and wasmvm 1.5 to 3.0.
F. IBC Integration
• Composition and ordering of the ICS4 wrapper and the IBC hooks middleware relative to the transfer, interchain accounts and wasm stacks.
• Packet, acknowledgement and timeout handling, and the effect of the ibc-go v7 to v10 migration including the removal of the capability module.
• Whether the version 2 packet path is reachable in the absence of a registered version 2 application router.
G. Node-Level Availability and API Surface
• The custom FIFO mempool, its eviction and ordering behaviour, and the ABCI++ proposal preparation and processing handlers built on it.
• The custom HTTP middleware, including the transaction log reconstruction layer, assessed for unbounded allocation and parsing robustness.
• Default node configuration and its hardening.
H. Economic Mechanism Implementation and Adversarial Simulation
• Oracle price feed manipulation resistance, vote buying, and Sybil resistance of the voting mechanism as implemented.
• Burn tax bypass paths and exemption abuse.
• Treasury drain scenarios and seigniorage manipulation.
• Denial of service scenarios targeting the custom modules and the custom mempool.
• Where the market swap mechanism is enabled by on-chain parameters, market manipulation and arbitrage scenarios. The Auditor notes that the chain’s historical fork logic set the minimum stability spread to 100%, which disables swaps; effort in this sub-area is contingent on the current on-chain parameter value.
Audit Goals
The Audit verifies the security soundness of the Terra Classic custom module implementations and the economic properties of the oracle, treasury, tax and market modules as implemented. It establishes whether the Cosmos SDK, ibc-go and CosmWasm integrations maintain their security properties under adversarial conditions following the SDK53 migration. It assesses the integrity of the state produced by the CosmWasm store migration and the determinism of the compatibility layer serving historical state. It identifies security risks introduced through Terra Classic’s customisations, delivers prioritised, implementable remediation guidance distinguishing consensus-breaking from non-breaking fixes, and confirms through the re-audit that the remediation actually closes the reported findings without introducing new ones.
Not in Scope
Upstream Cosmos SDK, CometBFT, ibc-go and wasmd code, except where Terra Classic modifies, wraps or configures it.
Consensus-layer properties of CometBFT are not re-derived.
CosmWasm contracts deployed on the chain. Only the chain-side integration is reviewed.
Off-chain infrastructure: validators, relayers, RPC providers, explorers, wallets.
Generated protobuf bindings. The 27 .proto definitions themselves are reviewed.
Deliverables
Upon and during completion of the Audit, the Auditor will provide the Client with:
Threat Model and Architecture Note: trust boundaries, privilege map, store inventory and prioritised attack surface, issued early for Client challenge.
Interim Findings Report: all Critical and High severity findings identified to date, issued midengagement rather than withheld until completion.
Draft Audit Report: a comprehensive report detailing all findings, their severity, affected code paths with file and line references, preconditions, potential impact, proof-of concept or reproduction steps where feasible, and specific remediation recommendations including code examples where appropriate.
Final Audit Report: the draft report updated after the re-audit, stating the remediation status of every finding, and including the review depth map and a risk assessment matrix evaluating likelihood and impact for each finding. The Final Audit Report is suitable for publication.
Recommendation Summary: a concise, prioritised summary of key recommendations, separating consensus-breaking fixes that require a governance upgrade from non-breaking fixes.
Hardened Continuous Integration Configuration: a .golangci.yml and workflow addition with the security-relevant linters enabled and existing violations triaged, delivered as a pull request. The Client’s current configuration disables errcheck, staticcheck, revive and unparam, with the result that unchecked error returns are not detected anywhere in the repository.
Fix Verification Statement: a per-finding statement of whether the remediation is verified, partially verified or not effective, issued as part of the re-audit.
Timeline
The expected timeline of the audit provided by SolidProof is 6.5 weeks, with 4 weeks anticipated for expected fixes before the final report, expected in 10 weeks.
The audit will start in 3 weeks of the proposal passing.
Full SolidProof Audit Agreement
The full audit agreement is available at the following link for review:
SolidProof Security Audit Agreement dated 16 September 2026
Costs
The costs for the complete audit and re-audit of remediated findings with a final report is a fixed price of $70,800 USD.
The quoted development time for SolidProof to complete the audit is 472 hours. If more work is required to deliver the audit as agreed there will be no further charge from SolidProof. Scope and depth changes, additional review rounds or fixes materially larger than the reported findings require are not included.
SolidProof have agreed to accept LUNC directly, with the total amount to be paid by the community up front to a Terra Classic address owned by SolidProof.
A buffer amount of 20% will be added to the community spend proposal (totalling $84,960) to account for any transfer fees/tax and LUNC price volatility during the 7 day voting window, with any portion of the buffer not consumed in the transfer being returned by SolidProof to the community pool.
The implementation of the audit findings will be done by OrbitLabs, who will work with the auditors and develop the fixes and prepare a chain upgrade proposal to implement them for a fixed price of $20,000 USD in LUNC.
OrbitLabs has estimated 10 days of development work to prepare the fixes and 6 days for the upgrade proposal.
The fee for OrbitLabs is to be paid after the completion of their work (standard PPJ).
The total fee for the entire audit and implementation of fixes is therefore $90,800 USD to be paid in LUNC.
At the time of preparing this proposal the community pool is worth $747,000 USD, comprising of $431,000 USD in LUNC and $316,000 USTC.
The total spend of $90,800 USD in LUNC is approximately 21.1% of the LUNC in the community pool, and 12.2% of the total community pool balance.
An exception should be considered to the standard PPJ for the auditors given they are an external body performing a specialised service for our chain. The initial spend proposal will be to SolidProof only. OrbitLabs will be paid for implementation of fixes according to standard PPJ.
The benefit of the arrangement with SolidProof is that payment will be directly made to them, there are no third parties or multi-sig needing to hold funds or need for the community to exchange LUNC to other coins to make payment to the auditor.
Voting
Vote YES to approve the SolidProof audit of the Terra Classic blockchain for the amount of $70,800 USD total in LUNC paid up front by a community spend proposal, plus a 20% buffer to cover transfer fees and price volatility during voting, with the balance of the buffer to be returned to the community pool, AND approval of Orbit Labs to develop and implement the required audit fixes including a software upgrade proposal for the amount of $20,000 USD in LUNC to be paid once their work is completed.
Vote NO if you oppose with this proposal.
Vote ABSTAIN if you wish to contribute to quorum only.
Vote NO WITH VETO if you believe this proposal is an abuse of governance.
Proposer
The proposer will not be in receipt of any community funds and will liaise with both SolidProof and OrbitLabs throughout the audit as necessary through to its completion.
The proposer receives no remuneration relating to this proposal.
Given the blockchain is unable to sign, the proposer will sign the required audit agreement with SolidProof, performance of which is contingent upon the community passing this proposal.