Prepared by:
HALBORN
Last Updated 11/05/2025
Date of Engagement: October 21st, 2025 - October 29th, 2025
100% of all REPORTED Findings have been addressed
All findings
5
Critical
0
High
0
Medium
2
Low
1
Informational
2
Permapod engaged Halborn to conduct a security assessment of the Zigchain Oracle contract suite, beginning on October 21st, 2025 and ending on October 29th, 2025. This security assessment was scoped to the smart contracts located in the Zigchain Oracle repository, specifically focusing on the integration and implementation of the Stork Oracle within the CosmWasm-based Zigchain network. Commit hashes and further details can be found in the Sources section of this report.
Zigchain Oracle is a CosmWasm smart-contract module responsible for providing on-chain price feeds for assets within the Zigchain ecosystem. It integrates multiple price sources — including Fixed, Stork, and Pyth — to deliver verified and up-to-date pricing data to other on-chain modules. The scope of this assessment centered primarily on the Stork oracle integration, which enables low-latency, verifiable price queries with configurable validation parameters such as staleness, confidence, and deviation thresholds.
The team at Halborn assigned a full-time security engineer to verify the security of the smart contracts. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.
The purpose of this assessment is to:
Ensure that smart contract functions operate as intended
Identify potential security issues with the smart contracts
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which have been completely addressed by the Permapod team. The main ones were the following:
Replace silent zero-price fallbacks with explicit error handling that returns domain-specific errors to avoid propagating price = 0 into business logic.
Correct timestamp validation to explicitly reject future timestamps rather than treating them as fresh, preventing bypass of staleness checks.
Eliminate unsafe use of signed-integer absolute operations that can panic.
Expand unit, integration, and fuzz testing to cover edge cases (overflow, negative values, stale/future timestamps, decimal conversion failures).
Emit on-chain CosmWasm events for price queries and validation outcomes to improve observability and post-execution diagnostics.
Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of this assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of the code and can quickly identify items that do not follow the security best practices. The following phases and associated tools were used during the assessment:
Research into architecture, purpose, and use of the platform.
Manual code read and walk through.
Manual assessment of use and safety for the critical Rust variables and functions in scope to identify any arithmetic related vulnerability classes.
Architecture related logical controls.
Cross contract call controls.
Scanning of Rust files for vulnerabilities (cargo audit)
Review and verification of integration tests.
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
0
High
0
Medium
2
Low
1
Informational
2
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Silent zero-price fallback via unwrap_or_default() in Stork price paths | Medium | Solved - 10/29/2025 |
| Future timestamp handling: Faulty logic allows future-dated prices to bypass staleness validation | Medium | Solved - 10/30/2025 |
| Panic from unsafe i128.abs() conversion | Low | Solved - 10/30/2025 |
| Insufficient test coverage and lack of fuzzing | Informational | Solved - 10/30/2025 |
| Missing event emission for price query results | Informational | Not Applicable |
//Medium
//Medium
//Low
//Informational
//Informational
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
Permapod Core Contracts Zigchain
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
