Security and audits

Precept's security rests on independent review, machine-checked proofs and reproducible builds. None of these removes the risk of a loss. See Risks.

The Guardian review

Guardian reviewed Precept's contract changes and published the Guardian security review, October 2026. The scope was 1,407 source lines across 46 files, with an initial review at commit 7a09b0e3d228 and a remediation review at b385dfb5cf18. Together these form the code released as v0.1.0. Guardian recorded no Critical, High or Medium findings, and 5 Low and 10 Informational findings. v0.1.1 carries post-review changes on top, including event-topic changes listed on Code lineage.

Every finding except one was resolved. The single open item is L-05, on the price adapter's timestamp handling, which Guardian marked acknowledged. The reported defect was in the adapter: it rounded the parent's timestamp down to the start of the resolution bucket, which hid a future-dated parent price from the pool's own check. Precept's adapter now refuses a parent price dated ahead of ledger time (pool-oracle-adapter/src/lib.rs). The recommendation itself is aimed at the parent proxy oracle, a separate contract outside the Precept repository: let an observation inside the freshness window replace a history head that is ahead of ledger time, so the head cannot outlast the clock. Guardian notes that passing the parent's timestamp through unfloored would also restore the pool's check, but on its own it blocks pricing for that asset until ledger time catches up. Read L-05 together with the price rules on Risks: the pool independently rejects future-dated, stale, non-positive and wrongly-scaled prices.

Audits of the inherited code

Guardian's scope does not cover all the code in a Precept pool. Code4rena and Certora audited the code that Precept's changes build on, before those changes existed. Their reports do not cover Precept's changes. The reports are linked from Code lineage.

Reproducing a release build

Releases are published on the releases page with the four WASM artifacts (pool.wasm, backstop.wasm, pool_factory.wasm, pool_oracle_adapter.wasm) and a SHA256SUMS file. Every published artifact can be rebuilt from the tagged source:

git clone https://github.com/Templar-Protocol/precept.git
cd precept
git checkout v0.1.1
make build
mkdir -p .bin
printf '#!/usr/bin/env bash\nexec "$@"\n' > .bin/pool-adapter-env
chmod +x .bin/pool-adapter-env
export PATH="$PWD/.bin:$PATH"
cd pool-oracle-adapter && just preflight && just optimize

make build uses the pinned toolchain in rust-toolchain.toml; the optimized pool, backstop and factory land in target/wasm32v1-none/optimized/. just preflight is the adapter's own toolchain gate: it requires exactly Stellar CLI 28.1.0 and Rust 1.98.0, and just optimize does not run it, so skipping it can produce adapter WASM from a different toolchain whose checksum will not match. The adapter's optimized file is written to pool-oracle-adapter/target/wasm32v1-none/release-soroban-checked/pool_oracle_adapter.optimized.wasm; rename it to pool_oracle_adapter.wasm before hashing, as the release workflow does, and compare all four files against the release's SHA256SUMS. The just recipes run through a pool-adapter-env wrapper that must be on PATH; the four lines above create it locally as the same exec "$@" shim CI uses, and in CI it is created by the release workflow (.github/workflows/release.yml). That workflow rebuilds the optimized WASMs from the tagged source and fails if any rebuilt file's checksum differs from the SHA256SUMS attached to the release.

To run the contract suite and the differential test harness yourself, see Getting started in the repository README.

Formal verification

The pool carries machine-checked proof harnesses, and they run in CI:

  • Kani proofs: bounded model checking over the pool's arithmetic and state transitions.
  • Certora runs: rule- and summary-based checks against the contract model.
  • Verus theorems: the pure kernel, proven in Rust.
  • VERIFICATION.md: the proof surface, what each harness covers, and how to run them.

Reporting a vulnerability

Report security issues to security@templarprotocol.com. Please give enough detail to reproduce the behaviour (the contract address, the entrypoint, and the sequence of calls), and allow time for a fix before disclosing publicly.

Precept does not currently operate a bug bounty programme; a report is appreciated, not payable.