Audit name:
[SCA] Fabstir | Marketplace | Jan2026
Date:
Mar 16, 2026
Table of Content
Introduction
We express our gratitude to the Fabstir team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Fabstir Compute Contracts implements a decentralized peer-to-peer marketplace for AI/LLM inference on EVM-compatible chains (Base, opBNB).
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Fabstir |
| Audited By | Seher Saylik; Stepan Chekhovskoi |
| Approved By | Ivan Bondar |
| Website | https://fabstir.com→ |
| Changelog | 18/02/2026 - Preliminary Report |
| 03/03/2026 - Remediation Report | |
| 10/03/2026 - Second Remediation Report | |
| 16/03/2026 - Final Report | |
| Platform | Base, opBNB |
| Language | Solidity |
| Tags | Marketplace; Staking; Upgradable; Signatures; Governance; Voting |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Fabstir
- Audited By
- Seher Saylik; Stepan Chekhovskoi
- Approved By
- Ivan Bondar
- Website
- https://fabstir.com→
- Changelog
- 18/02/2026 - Preliminary Report
- 03/03/2026 - Remediation Report
- 10/03/2026 - Second Remediation Report
- 16/03/2026 - Final Report
- Platform
- Base, opBNB
- Language
- Solidity
- Tags
- Marketplace; Staking; Upgradable; Signatures; Governance; Voting
Review Scope | |
|---|---|
| Repository | https://github.com/Fabstir/fabstir-compute-contracts#→ |
| Commit | 8edc68be530f53249c6845fb0c1fbdf9dec68e62 |
| Retest 1 | f614355dbc0fd346dff331a587fc24413a9f0664 |
| Retest 2 | df1f2e4d7725a98d76b821ee759cd2c59f9dfa21 |
| Final | fba54b2bf1181dacc7ec8db43e0e16854df0483d |
Review Scope
- Commit
- 8edc68be530f53249c6845fb0c1fbdf9dec68e62
- Retest 1
- f614355dbc0fd346dff331a587fc24413a9f0664
- Retest 2
- df1f2e4d7725a98d76b821ee759cd2c59f9dfa21
- Final
- fba54b2bf1181dacc7ec8db43e0e16854df0483d
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are detailed.
Project overview is detailed.
All roles in the system are described.
Use cases are described and detailed.
Not all interactions are described.
Technical description is detailed.
Run instructions are provided.
The NatSpec documentation is partial.
Code quality
The development environment is configured.
Test coverage
Code coverage cannot be measured in the current state due to stack limitation errors in the coverage tooling.
Deployment and basic user interactions are covered with tests.
Negative cases coverage is partially missed.
Interactions by several users are not tested thoroughly.
System Overview
Fabstir Compute Contracts implements a decentralized peer-to-peer marketplace for AI/LLM inference on EVM-compatible chains (Base, opBNB). The protocol connects users who need AI compute (depositors) with GPU node operators (hosts) who run approved AI models, facilitating session-based interactions with on-chain payment settlement.
Hosts register as compute nodes by staking FAB tokens as an economic bond, declaring the AI models they support and their per-token pricing (in both native currency and stablecoins). AI models must first be approved either by the contract owner (trusted tier) or through community governance voting using FAB tokens. Users create sessions by depositing funds (ETH/BNB or ERC20 stablecoins), specifying a host, a model, and pricing terms. During a session, the host submits incremental proofs of work, ECDSA-signed attestations of tokens processed, which are verified on-chain. Conversation data and proofs are stored off-chain via S5 CIDs, with only hashes and references recorded on-chain for cost efficiency.
Upon session completion (voluntary by depositor/host, or forced via timeout), the contract settles payments: the host receives payment proportional to proven work (minus a configurable treasury fee), and the depositor is refunded the unused deposit. Host earnings are accumulated in a dedicated contract to reduce gas costs, allowing batch withdrawals. Misbehaving hosts can be slashed by a designated slashing authority, with slashed FAB tokens sent to the protocol treasury.
All five contracts follow the UUPS (Universal Upgradeable Proxy Standard) pattern using OpenZeppelin's upgradeable libraries, allowing the owner to upgrade implementations while preserving state.
Files in Scope
ModelRegistryUpgradeable.sol - Manages an on-chain registry of approved AI models (identified by HuggingFace repo + filename + SHA256 hash). Implements a two-tier approval system: owner-curated trusted models (tier 1) and community-proposed models approved via FAB token governance voting (tier 2) with anti-sniping vote extensions. Charges a 100 FAB proposal fee and requires 100k FAB approval threshold.
NodeRegistryWithModelsUpgradeable.sol - Manages compute node registration, staking, and model support declarations. Hosts must stake a minimum of 1,000 FAB tokens and declare supported models (verified against ModelRegistry). Supports granular pricing: per-node defaults for native and stable tokens, per-model overrides, and per-token overrides. Includes a slashing mechanism allowing a designated authority to penalize misbehaving hosts (up to 50% per slash with 24-hour cooldown), with automatic unregistration if stake falls below the minimum threshold.
JobMarketplaceWithModelsUpgradeable.sol - The core marketplace contract orchestrating session lifecycle: creation (with native or ERC20 deposits), proof-of-work submission by hosts, session completion/timeout settlement, and treasury fee collection. Supports both direct-deposit session creation and a wallet-agnostic pre-deposit pattern. Enforces host registration, model support, minimum pricing, deposit bounds, and proof rate-limiting. Integrates with HostEarnings for payment accumulation and ProofSystem for signature verification.
HostEarningsUpgradeable.sol - An accumulation contract that batches host earnings from completed sessions to reduce per-job gas costs. Only authorized callers (JobMarketplace) can credit earnings. Hosts can withdraw individual token balances, all balances for a token, or multiple tokens at once. Includes an emergency token rescue function for accidentally sent funds.
ProofSystemUpgradeable.sol - Provides ECDSA signature verification for host proof-of-work submissions. Hosts sign
keccak256(proofHash, prover, claimedTokens)usingeth_sign, and the contract recovers the signer to verify authenticity. Tracks verified proof hashes to prevent replay attacks. Supports single and batch (up to 10) proof verification. Also maintains a model-to-circuit registry for future extensibility.
Privileged roles
ModelRegistryUpgradeable.sol:
owner: Can add trusted models (tier 1) and batch-add models, bypassing community governance. Can deactivate and reactivate any model. Can authorize contract upgrades. Can transfer and renounce ownership.
NodeRegistryWithModelsUpgradeable.sol:
owner: Can update the ModelRegistry address. Can set the slashing authority and treasury addresses. Can initialize slashing functionality. Can repair corrupt nodes (returning their stake). Can authorize contract upgrades. Can transfer and renounce ownership.
slashingAuthority: Can slash a portion (up to 50%) of any active host's staked FAB tokens, providing evidence and reason. If the slash reduces the host's stake below the minimum threshold (100 FAB), the host is automatically unregistered.
JobMarketplaceWithModelsUpgradeable.sol:
owner: Can set the treasury address and USDC address. Sets
feeBasisPointsanddisputeWindowat initialization (no post-initialization setters). Can authorize contract upgrades. Can transfer and renounce ownership.treasuryAddress (or owner): Can pause and unpause the contract (blocking session creation and proof submission). Can set the proof system address. Can initialize chain configuration. Can add accepted payment tokens and update their min/max deposit bounds.
treasuryAddress: Can withdraw accumulated treasury fees (native and ERC20 tokens).
HostEarningsUpgradeable.sol:
owner: Can authorize or revoke callers that are permitted to credit earnings. Can rescue excess tokens accidentally sent to the contract. Can authorize contract upgrades. Can transfer and renounce ownership.
authorizedCallers (e.g., JobMarketplace): Can credit earnings to host balances and send ETH to the contract.
ProofSystemUpgradeable.sol:
owner: Can authorize or revoke callers for
recordVerifiedProof. Can register model circuits. Can authorize contract upgrades. Can transfer and renounce ownership.authorizedCallers (or owner): Can record verified proofs (marking proof hashes as used to prevent replay).
Potential Risks
Price precision for creating a session: in JobMarketplaceWithModelsUpgradeable, users specifying pricePerToken must understand that prices are stored with 1000x precision (PRICE_PRECISION), meaning a value of 1000 equals 1 base unit per token, not 1000 units per token, which could lead to mispricing if not clearly documented in the frontend.
Session settlement: In JobMarketplaceWithModelsUpgradeable, if the HostEarningsUpgradeable contract is not authorized to receive ETH or if token transfers to it fail (e.g., token blacklist, paused token), the _settleSessionPayments() function will revert, permanently locking user deposits until the configuration is fixed or contract is upgraded.
Model Selection Trust Assumption: In JobMarketplaceWithModelsUpgradeable, the modelId specified during session creation cannot be verified on-chain, meaning users must trust that hosts use the requested model rather than a cheaper alternative.
Slashing is fully discretionary: When a host is slashed, part of their staked FAB (up to 50% per slash, with a 24-hour cooldown) is taken from the contract and sent to the protocol treasury as a penalty. Evidence and reason are only used in events and off-chain review, so the slashing authority can slash any active host within those limits with no on-chain justification, which is a centralization and trust assumption.
Unbounded single-voter influence: In ModelRegistryUpgradeable.voteOnProposal, there is no cap on the amount a single address can vote. A whale holding 100k+ FAB can single-handedly meet the APPROVAL_THRESHOLD or block any proposal in a single transaction, making community governance effectively plutocratic. Combined with the absence of any quorum requirement on the against-side or minimum voter count, a single well-funded address can unilaterally decide every proposal outcome.
Optimistic proof model with no on-chain dispute mechanism: In JobMarketplaceWithModelsUpgradeable, hosts self-sign their own proof submissions and tokensUsed is incremented immediately upon proof acceptance. The disputeWindow only delays host-initiated completion, it does not provide any on-chain function for depositors to challenge or reject individual proofs. Settlement always pays based on cumulative tokensUsed, so a fraudulent proof that passes the rate limiter is irreversible once submitted. Depositors can only end sessions early via completeSessionJob, but this settles including any already-accepted inflated claims. Fraud remediation depends entirely on off-chain slashing, which is reactive and does not compensate affected users.
A delegate controls session parameters including pricePerToken, maxDuration, and proofTimeoutWindow, enabling a colluding delegate-host pair to set inflated pricing so the host earns the payer's full deposit while delivering minimal work, all within the configured spending cap
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1525 | Use of IERC20.transfer() Instead of SafeERC20.safeTransfer() in Refund Path | fixed | High | |
| F-2026-1497 | Token Pricing Assumes All Payment Tokens Have Same Decimals And Price | fixed | High | |
| F-2026-1496 | Proposal Fee Permanently Locked on Rejection | fixed | High | |
| F-2026-1533 | Delegate Spending Cap Bypass via Token Selection Allows Draining Payer Funds Beyond Intended Limits | fixed | High | |
| F-2026-1528 | Hardcoded Private Key Exposure in Test Scripts Enables Unauthorized Account Control | fixed | Medium | |
| F-2026-1525 | Early Cancel Fee Applied on Depositor-Triggered Timeouts | fixed | Medium | |
| F-2026-1516 | Deactivated Model Still Usable for Sessions and Node Registration | fixed | Medium | |
| F-2026-1514 | Missing Access Control on verifyAndMarkComplete Enables Proof Griefing Attack | fixed | Medium | |
| F-2026-1514 | Shared Proof Replay-Prevention State Across Multiple Uncoordinated Entry Points Causes Proof Submission Failure | mitigated | Medium | |
| F-2026-1514 | Dispute Window Calculated From Session Start Time Instead of Last Proof Submission | fixed | Medium |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/Fabstir/fabstir-compute-contracts#→ |
| Commit | 8edc68be530f53249c6845fb0c1fbdf9dec68e62 |
| Retest 1 | f614355dbc0fd346dff331a587fc24413a9f0664 |
| Retest 2 | df1f2e4d7725a98d76b821ee759cd2c59f9dfa21 |
| Final commit | fba54b2bf1181dacc7ec8db43e0e16854df0483d |
| Whitepaper | N/A |
| Requirements | https://github.com/Fabstir/fabstir-compute-contracts/tree/main/docs→ |
| Technical Requirements | https://github.com/Fabstir/fabstir-compute-contracts/tree/main/docs→ |
Scope Details
- Commit
- 8edc68be530f53249c6845fb0c1fbdf9dec68e62
- Retest 1
- f614355dbc0fd346dff331a587fc24413a9f0664
- Retest 2
- df1f2e4d7725a98d76b821ee759cd2c59f9dfa21
- Final commit
- fba54b2bf1181dacc7ec8db43e0e16854df0483d
- Whitepaper
- N/A
- Technical Requirements
- https://github.com/Fabstir/fabstir-compute-contracts/tree/main/docs→
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.
Frameworks and Methodologies
This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.