Pactus

Audit date · 2026-10-23

Audits are prepared by the site owner with a self-hosted (local) AI, checked against the exact commit above, and hand-edited before publishing. This is not financial, legal, or investment advice. Read it as one person's notes on one commit at one date. Do your own research.

This is a point-in-time review of code quality and tokenomics at the commit above, not a safety certification. Projects can change after this date. Check for newer releases or a newer audit before relying on these scores.

Committee-PoS L1 with the full 42M supply allocated at genesis and a 30% foundation reward share with no end height.

🪙 Pactus (PAC) — Code & Tokenomics Audit

Verdict: GOOD — code 10.0 / tokenomics 4.0 / risk 4.0. The code score reflects the reviewed code and its tests. The two tokenomics deductions are the disclosed full-supply genesis allocation and the continuing 30% foundation share.

Repo: pactus-project/pactus at 169b0e3f415dde3cb299e6e22b6edc4584b2f12a
Audited: 2026-10-23. Scope: consensus reward and subsidy paths, treasury funding, mainnet genesis allocation, foundation distribution, wallet encryption, and repository hygiene at the pinned commit.

🔑 At a glance

🔗 Links & sources

🧮 Risk score inputs

The rubric starts each score at 10.0. Each deduction is applied once. Risk is the lower of code and tokenomics scores.

code_score       = 10.0 − 0.0 = 10.0
tokenomics_score = 10.0 − 3.0 − 3.0 = 4.0
risk_score       = min(10.0, 4.0) = 4.0

Instant GOOD overrides: none fired. All five were checked. In particular, the published supply claim is supported by the reviewed issuance and balance-check path; the disclosed genesis allocation is scored under the premine rule, not treated as an undisclosed-supply override.

The earlier float-rounding deduction is removed: the reviewed mainnet reward coefficients are binary fractions and state/param/param_test.go:20-37 checks the expected reward values. The earlier separate “50% treasury concentration” deduction is not stacked on top of the full disclosed genesis allocation deduction. A precise treasury exhaustion block is not scored because fees are returned to the treasury and future fee inflows were not measured.

🔒 Code

The reviewed block execution checks the subsidy amount against the expected block reward and fees (state/execution.go:13-45). It checks the foundation payment and configured recipient (state/execution.go:47-81). The treasury transfer path returns ErrInsufficientFunds when funds do not cover a transfer and fee (execution/executor/batch_transfer.go:57-63). Mainnet reward-boundary values have tests (state/param/param_test.go:20-37).

No code deduction was supported by the findings reviewed for this report. The repository has CI, go.mod and go.sum, and 240 _test.go files. No real unsafe use was found outside generated protobuf files in the reviewed Go source. No outbound telemetry was found in that source review; this is not a runtime network guarantee.

Open code question: state/execution.go:74-81 indexes the first two batch-transfer recipients. The payload’s BasicCheck requires 2–8 recipients (types/tx/payload/batch_transfer.go), but this pass did not trace every block-validation route to confirm where that check is always invoked. No panic finding is claimed.

📊 Tokenomics

The treasury balance alone is below the sum of nominal rewards through the first three 8M-block eras, but that is not enough to establish an exhaustion height because transaction fees replenish it. If the treasury cannot fund a required subsidy, the balance check prevents that transfer; actual future fee sufficiency is unknown.

🕵️ Privacy

The wallet vault stores an encrypted mnemonic and rejects an empty password (wallet/vault/vault.go:95,118-119). The reviewed encrypter uses Argon2id with the configured parameters and AES-256 (wallet/encrypter/encrypter.go:19-64). No outbound telemetry endpoint was found in the reviewed Go source. Runtime traffic and third-party wallet behavior were not tested.

🚩 Red flags

• ⚠️ The full published 42M supply is allocated at genesis. The disclosure is clear, but it means no unallocated supply reserve remains outside the documented genesis distribution.
• ⚠️ Foundation receives 30% of each block reward without an end height, distributed among 100 addresses. Address ownership, custody controls, timelock, and multisig status were not established.
• 🔍 Treasury funding over the full reward schedule is uncertain. Fees return to the treasury, so a fixed exhaustion block and “fees-only after block 44M” claim are not established.
• 🔍 The recipient-length validation call path needs tracing to establish that BasicCheck always precedes recipient indexing in block execution.

✅ Green flags

• ✅ Subsidy is recomputed and checked during block execution (state/execution.go:13-45).
• ✅ Treasury transfers fail when balance is insufficient (execution/executor/batch_transfer.go:57-63).
• ✅ Mainnet reward coefficients and expected values are covered by tests (state/param/param_test.go:20-37).
• ✅ Wallet vault requires a password and stores the mnemonic encrypted (wallet/vault/vault.go:95,118-119).
• ✅ CI and a substantial Go test suite are present; dependency manifests include go.sum.
• ✅ Whitepaper supply and allocation disclosures match the reviewed 42M genesis total.

🧭 Context

❓ What I could not check

• Current on-chain supply and whether it conforms to the audited schedule.
• Actual future transaction-fee income and treasury ability to fund every scheduled reward.
• Control, identities, custody, or governance over the 100 foundation addresses.
• Whether every consensus execution route invokes batch-transfer BasicCheck before recipient indexing.
• Independent security-audit coverage and runtime network behavior.

🧭 Bottom line

Pactus has a well-tested reward-validation path and strong wallet encryption in the reviewed code. The main risk is tokenomics: all 42M published coins are allocated at genesis, while the foundation receives a 30% reward share indefinitely. The treasury’s long-term funding cannot be established without fee-flow data, so this report does not claim an exact exhaustion block. The rubric score is 4.0, driven by the two tokenomics deductions.

Files we opened

state/execution.go:13-45

state/execution.go:47-81

execution/executor/batch_transfer.go:57-63

state/param/param_test.go:20-37

genesis/mainnet.json:18-39

state/param/param.go:65,111-134

state/param/foundation_mainnet.json:1-103

wallet/vault/vault.go:95,118-119

wallet/encrypter/encrypter.go:19-64

Every file listed here was opened by us during the audit. Nothing here is a guess.

Back to Projects