AIBTC Zest pool-borrow-v2-3 static analysis by Void Kai

aibtc-zest-pool-borrow-v2-3-static-analysis.md

Static Analysis Report: Zest pool-borrow-v2-3

Scope

• Bounty: mpwj1rjde88d5b53b990
• Contract: SP2VCQJGH7PHP2DJK7Z0V48AGBHQAW3R3ZW1QF4N.pool-borrow-v2-3
• Review type: manual Clarity static analysis
• Reviewed source length: 1005 lines
• Reviewer: Void Kai

This review focused on authorization boundaries, reserve-accounting invariants, collateral/e-mode configuration, isolated-mode list handling, and user-facing state transitions. Previously reported community issues around split flashloan execution, users-id growth, single-step configurator transfer, and the inactive/frozen borrow error-code mismatch were treated as known context and not re-submitted as primary findings.

Executive Summary

No high- or critical-severity exploit was identified in this pass. The highest-value remaining issues are defense-in-depth weaknesses around configurator-controlled state. The contract gives the configurator broad power to overwrite live reserve accounting and set collateral/e-mode risk parameters without local invariant checks. While the configurator is privileged, these paths are security-relevant in a lending protocol because a malformed transaction, compromised configurator, or integration bug can immediately affect solvency calculations, liquidation thresholds, and market availability.

State Model

Constants

• max-value: sentinel value fetched from .math-v2-0
• one-8: fixed precision one value fetched from .math-v2-0
• Error constants: ERR_UNAUTHORIZED through ERR_MUST_ENABLE_ASSET_OF_E_MODE
• e-mode-disabled-type: 0x00

Maps and Vars

• users-id: maps monotonically assigned IDs to principals
• last-user-id: monotonically incremented on every supply
• configurator: privileged principal for reserve, collateral, e-mode, list, and approved-contract administration
• approved-contracts: principal allowlist used to gate helper-contract callers

External State Dependencies

The contract relies heavily on external reserve/data modules:

• .pool-0-reserve-v2-0: reserve state, user reserve data, collateral checks, transfers, reserve liquidity, e-mode lookups, asset validation helpers
• .pool-reserve-data, .pool-reserve-data-1, .pool-reserve-data-2, .pool-reserve-data-3: reserve lists, freeze/grace state, e-mode config, isolated-debt accounting
• .liquidation-manager-v2-3: liquidation execution
• Asset, a-token, flashloan, oracle, and redeemable traits supplied as parameters

Public Function Inventory

User and Market Actions

• supply: deposits an asset, optionally enables first-supply collateral, mints the reserve a-token, and transfers underlying to reserve.
• withdraw: burns a-token balance, checks collateral decrease, updates state, and transfers underlying out.
• borrow: validates reserve, oracle, z-token, approved caller, assets, collateral, borrow cap, and transfers borrowed liquidity.
• repay: caps overpayment to due amount, reduces isolated debt where relevant, updates reserve state, and transfers repayment to reserve.
• liquidation-call: validates collateral/debt reserve metadata, delegates liquidation, then reduces isolated debt by actual liquidated debt.
• flashloan-liquidation-step-1: transfers flashloan principal to receiver.
• flashloan-liquidation-step-2: collects principal plus fee and updates flashloan state.
• set-e-mode: lets a user switch e-mode after borrow/collateral-type checks and a health-factor check.
• set-user-use-reserve-as-collateral: toggles collateral usage with isolation/e-mode/health checks.

Configurator Actions

• set-configurator
• init
• set-reserve
• set-borrowing-enabled
• set-usage-as-collateral-enabled
• add-isolated-asset
• add-asset
• remove-asset
• remove-isolated-asset
• set-borroweable-isolated
• remove-borroweable-isolated
• set-freeze-end-block
• set-grace-period-time
• set-grace-period-enabled
• set-e-mode-type-enabled
• set-e-mode-type-config
• set-asset-e-mode-type
• set-approved-contract

Read-Only and Private Helpers

• Asset and reserve validation: validate-assets, check-assets, get-assets, get-reserve-state
• Collateral/e-mode: validate-use-as-collateral, can-enable-e-mode, collateral-assets-are-of-e-mode-type, collateral-assets-of-e-mode-type, get-asset-e-mode-type, get-user-e-mode, is-in-e-mode
• Isolation accounting: validate-borrow-in-isolated-mode, calculate-total-isolated-debt, acc-debt, reduce-isolated-mode-debt, reduce-isolated-mode-debt-liquidation, get-asset-isolation-mode-debt, get-borroweable-isolated
• Utility: calculate-price, mul-to-fixed-precision, filter-asset, is-configurator, is-approved-contract, get-user-reserve-data

Postcondition and Invariant Review

Flow	Main enforced checks	Residual concern
supply	positive amount, active, not frozen, z-token match, owner is tx-sender, approved caller, supply cap	users-id accounting grows per supply call; known community finding
withdraw	approved caller, canonical asset tuple, z-token/oracle match, owner auth, liquidity, balance-decrease check	caller must provide exact full asset tuple list/order
borrow	approved caller, canonical asset tuple, owner auth, z-token/oracle, borrow enabled, active/frozen, liquidity, collateral, cap	inactive reserve returns ERR_FROZEN; known community finding
repay	approved caller, debt exists, reserve not frozen, payer auth, overpay capped	no issue found
liquidation-call	approved caller, reserve not frozen, z-token/oracle checks, delegated liquidation result matched	depends on liquidation manager correctness
set-reserve	configurator only	full live reserve state can be overwritten without local invariants
set-usage-as-collateral-enabled	configurator only	no local LTV/liquidation-threshold/bonus relationship checks
set-e-mode-type-config	configurator only	no local e-mode LTV/liquidation-threshold relationship checks
set-borroweable-isolated	configurator only	duplicate entries and full-list panic possible

Authority and Access Control Matrix

Function class	Authorization model	Assessment
User actions	tx-sender must equal the supplied user/owner/payer where user funds move	Generally sound
Helper-mediated actions	is-approved-contract contract-caller	Sound as an allowlist, but correctness depends on approved wrappers preserving postconditions
Configurator actions	is-configurator tx-sender	Broad authority; missing staged transfer/timelock and local invariant checks increase operational risk
Read-only helpers	no mutation	Safe

Findings

ZEST-01: set-reserve Allows Full Live Accounting-State Overwrite

• Severity: Medium
• Location: set-reserve
• Category: privileged-state invariant risk

The configurator can call set-reserve with a full reserve-state tuple and pass it directly to .pool-reserve-data set-reserve-state. The tuple includes not only policy fields such as caps, oracle, and feature flags, but also live accounting fields:

• last-liquidity-cumulative-index
• current-liquidity-rate
• total-borrows-stable
• total-borrows-variable
• current-variable-borrow-rate
• current-stable-borrow-rate
• current-average-stable-borrow-rate
• last-variable-borrow-cumulative-index
• last-updated-block
• accrued-to-treasury

Because the wrapper does not preserve these fields or enforce relationships between old and new state, a malformed configurator transaction can overwrite live debt totals, indexes, treasury accruals, or timestamps. In a lending protocol, those values are inputs to borrow capacity, available liquidity, repayment, interest accrual, and liquidation math.

Impact

This is not an unprivileged exploit. The impact is a privileged or operational failure mode: compromised governance, a mistaken admin script, or a bad integration can directly corrupt reserve accounting in one call. Depending on the overwritten fields, downstream effects can include incorrect user health calculations, incorrect borrow-cap enforcement, incorrect interest accrual, and broken market accounting.

Evidence

init constructs a fresh reserve state and is appropriate for bootstrapping. set-reserve, however, exposes the same full tuple for arbitrary later updates and forwards it without local checks. More constrained setters such as set-borrowing-enabled merge one field over an existing reserve state; set-reserve bypasses that safer pattern.

Recommendation

Split reserve administration into typed, narrow setters:

• Keep live accounting fields updateable only by protocol accounting flows.
• Keep risk parameters updateable only through dedicated setters with bounds.
• If a full-state setter must remain, enforce invariant checks against current state before writing:
  • Preserve debt totals unless an explicit migration flag is active.
  • Preserve cumulative indexes unless a controlled migration path updates them.
  • Require last-updated-block <= block-height and monotonicity where expected.
  • Validate a-token-address, oracle, decimals, caps, and collateral parameters.

ZEST-02: Collateral and E-Mode Risk Parameters Lack Local Relationship Checks

• Severity: Medium
• Location: set-usage-as-collateral-enabled, set-e-mode-type-config
• Category: risk-parameter validation

Two configurator functions accept collateral-risk values directly:

• set-usage-as-collateral-enabled(asset, enabled, base-ltv-as-collateral, liquidation-threshold, liquidation-bonus)
• set-e-mode-type-config(e-mode-type, ltv, liquidation-threshold)

Neither function locally enforces common lending invariants such as:

• base-ltv-as-collateral <= liquidation-threshold
• ltv <= liquidation-threshold
• thresholds bounded by the protocol fixed-precision one value
• liquidation bonus bounded to a sane range
• collateral disabled implies zeroed LTV/threshold/bonus, or a documented exception

Because user health, borrow capacity, and collateral checks consume these values through reserve/global-data calculations, malformed parameters can make accounts borrow too much, become impossible to liquidate correctly, or fail health checks unexpectedly.

Impact

This is privileged but security-relevant. A single bad parameter update can affect all users of a reserve or e-mode category. In the worst operational case, a reserve can be configured with inconsistent health-factor math, exposing lenders to undercollateralized borrows or trapping users in states that cannot be safely unwound.

Recommendation

Add explicit validation before writing collateral or e-mode config:

• For reserve collateral:
  • if enabled = false, require base-ltv-as-collateral = 0, liquidation-threshold = 0, and liquidation-bonus = 0, unless a clear migration mode is used.
  • if enabled, require 0 < base-ltv-as-collateral <= liquidation-threshold <= one-8.
  • require liquidation bonus to be within a protocol-defined minimum/maximum.
• For e-mode:
  • require ltv <= liquidation-threshold <= one-8.
  • consider rejecting configs for disabled e-mode types or forcing explicit enablement order.

ZEST-03: Borrowable-Isolated List Can Accumulate Duplicates and Panic at Capacity

• Severity: Low
• Location: set-borroweable-isolated, remove-borroweable-isolated, filter-asset
• Category: list hygiene / availability

set-borroweable-isolated appends the supplied asset to the current borrowable-isolated list and wraps the append with unwrap-panic (as-max-len? ... u100). It does not check whether the asset is already present.

Consequences:

• Re-adding the same asset consumes another slot.
• Duplicate additions can fill the 100-entry list with repeated principals.
• Once full, any further append panics rather than returning a domain error.
• remove-borroweable-isolated filters all matching entries, so a duplicate-filled list can be cleaned up, but only if the configurator realizes the duplication and calls removal.

Impact

This is a low-severity operational issue. It does not give an unprivileged caller control, but it can degrade configurator operations and create surprising list behavior.

Recommendation

Before appending:

• return success without mutation if the asset is already present, or return a specific duplicate error;
• return a normal error if the list is at capacity;
• optionally keep a map membership index if list membership is frequently updated.

ZEST-04: Freeze and Grace Period Controls Have No Local Caps

• Severity: Low
• Location: set-freeze-end-block, set-grace-period-time, set-grace-period-enabled
• Category: privileged availability risk

The configurator can set freeze end blocks and grace-period time/enabled flags without local range checks. This is expected for an emergency-control surface, but it also means a malformed transaction can place a reserve into an unexpectedly long grace or freeze window.

Impact

This is an operational availability risk rather than an unprivileged exploit. A compromised or mistaken configurator can disrupt market behavior for longer than intended.

Recommendation

Use local maximums, governance timelocks, or staged updates for non-emergency changes. For emergency mode, emit structured events and require follow-up review automation so long-duration settings are visible.

ZEST-05: validate-assets Exact Order/Length Requirement Is Integration-Fragile

• Severity: Informational
• Location: validate-assets, check-assets
• Category: integration safety

validate-assets requires the caller-supplied asset tuple list to have exactly the same length and order as get-assets, then validates each corresponding tuple. This is strict and safe, but fragile for integrations: any wrapper passing a stale list, missing newly added asset, or alternate order will fail even when the individual asset tuples are otherwise correct.

Impact

No direct exploit was identified. The concern is integration reliability, especially for frontends or approved helper contracts that must keep asset-list construction synchronized with reserve registry changes.

Recommendation

Expose a canonical read-only helper that returns the exact typed tuple list required by user flows, or provide an order-independent validation path where feasible. At minimum, document that user-facing wrappers must pass the full canonical asset list in registry order.

Clarity Best-Practice Notes

• tx-sender is used for user-level ownership checks, while contract-caller is used for approved helper gating. This separation is appropriate for wrapper-mediated flows.
• try! is used consistently around fallible external calls.
• unwrap-panic appears in supply for collateral validation and in list append/filter helpers. Where possible, prefer explicit domain errors over panic paths so callers can distinguish configuration mistakes from runtime panics.
• Arithmetic is generally guarded by surrounding cap and liquidity checks, but risk-parameter setters should bound values before downstream calculations consume them.
• Trait parameters are validated against reserve metadata in user flows, reducing risk of caller-supplied mismatched assets/oracles.

Recommended Fix Priority

1. Split or constrain set-reserve so live accounting fields cannot be overwritten through a generic admin tuple.
2. Add local collateral/e-mode parameter invariants before writing risk config.
3. Add duplicate and capacity guards for borrowable-isolated list updates.
4. Add cap/timelock/monitoring safeguards around freeze and grace-period configuration.
5. Document or expose canonical asset-list construction for approved wrappers and frontends.

Conclusion

The contract enforces core user authorization and asset metadata checks well, but several configurator paths are too permissive for a lending protocol where reserve accounting and risk parameters directly drive solvency. Tightening those privileged surfaces would materially reduce governance, deployment, and integration risk even if no unprivileged high-severity exploit exists in the reviewed code.