Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

vAPI Network Info

vapinetwork.ai

The trusted onchain task market where agents & humans do business. Every job verified, paid in USDC.

vAPI Network Logo
Onboarded date 19/10/2026

Team and KYC Verification

The team has securely submitted their personal information to SolidProof.io for verification.

In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

98.67
Poor Excellent

Audit Reports

PDF audit reports for this project are published on GitHub.

View on GitHub

Security Assessments

Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2026/10/19
Revision date 2026/10/19

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner cannot blacklist addresses.

It is not possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Token transfer can be locked

Owner can lock user funds with owner functions.

Token cannot be burned

There is no burning within the contract without any allowances

Ownership is not renounced

The owner retains significant control, which could potentially be used to modify key contract parameters.

Contract is not upgradeable

The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Smart Contract Analysis Statement

Contract Analysis

The vAPI Staking contract implements a single-asset, ownerless staking registry for the existing vAPI ERC20 token, with a minimum position of one vAPI, a fixed seven-day unstake cooldown, one pending unstake request per wallet that can be cancelled until it is withdrawn, and timestamp checkpoints that allow exact historical balance reads for past seconds. It is paired with the ThresholdReviewersGate, which treats a wallet as eligible to review Tasks disputes when its active stake reaches a threshold that can only move between 10,000 and 1,000,000 vAPI. In the reviewed code the threshold starts at 100,000 vAPI, and the project team has announced a starting value of 10,000 vAPI for the mainnet deployment. Staking earns no token rewards inside the contract; the stake is read by the off-chain Compute service and by the reviewer gate.

Ownership Privileges

The ownership of the contract has been removed entirely for VapiStaking, which has no owner, roles, pause, upgrade or rescue function, while the companion ThresholdReviewersGate is owned by the vAPI Foundation multisig. On Base mainnet the deployment script refuses an owner that is not a contract with a Safe signer threshold of at least two. Mainnet had not been deployed at the time of this review, so the owner and its signers should be confirmed on chain when the contracts go live. The gate owner retains full privileges including:

  • Proposing a new reviewer threshold between 10,000 and 1,000,000 vAPI.
  • Executing a proposed threshold after the seven-day notice and within the following fourteen days, which changes reviewer eligibility for new dispute panels immediately.
  • Cancelling or replacing a pending proposal; a replacement restarts the seven-day notice.
  • Starting an ownership transfer, which only takes effect once the new owner accepts it. Ownership cannot be renounced.
  • No address can move, lock, confiscate or redirect staked or pending vAPI; principal only returns to the wallet that requested the unstake.
  • No address can mint or burn tokens, charge fees, blacklist wallets or change the seven-day cooldown.
  • Neither contract can be paused or upgraded.
  • The owner cannot set a threshold outside the fixed bounds, apply a change before the notice period has passed or execute a proposal after it has expired.

Security Features

The contract implements several positive security features:

  • Self-custody of principal without any administrative, slashing or emergency path that could reach user funds.
  • Reentrancy protection on every state-changing function together with a checks-effects-interactions order.
  • Well-established OpenZeppelin libraries for token transfers, safe casting, checkpoints and two-step ownership, checked arithmetic and descriptive custom errors.
  • Historical lookups that only accept past timestamps, a minimum position size, views for both custody surplus and custody shortfall, and a bounded, timelocked reviewer threshold whose proposals expire.
  • A deployment process that validates the token and the owner before broadcasting and records the deployment only from confirmed transactions.
  • Custody, accounting and withdrawal-timing properties that held under symbolic proofs and several million randomized multi-wallet transaction sequences.

Auditor Comments

We found no critical, high or medium severity issues in the staking contract or the reviewer gate. The one low severity point, missing validation of the deployment inputs, and all eight informational points have been fixed by the project team, and we verified every fix on the remediated code without finding any new issue. The design relies on vAPI being a plain ERC20 without transfer fees or rebasing, which the project team has documented. The tests that run the contracts against the real vAPI token on a fork of Base mainnet were executed and passed. The match between the deployed contracts and the reviewed source code remains to be confirmed once the mainnet deployment has taken place.

Note - This Audit report consists of a security analysis of the vAPI Staking smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract and its reviewer gate for the vAPI Staking team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.

Files and details

Findings and Audit result

Critical
High
Medium
Low
4
Optimization
Informational
low Issues | 1 findings

Resolved

#1 low Issue
Deployment inputs are not validated
DeployVapiStaking.s.sol
L9-17
Description

The deployment script passes VAPI_TOKEN and FOUNDATION_MULTISIG from the environment straight into the constructors, and neither value has a default. The staking constructor only checks that the token address has code, and the gate constructor (ThresholdReviewersGate.sol lines 33-38) only checks that the staking address has code. On Base mainnet a wrong token, for example the freely mintable test token used on Base Sepolia, or a plain wallet as the gate owner would be deployed without any warning. All three are immutable, so the only repair is a new deployment, and a mintable token would let anyone create reviewer stake. The script also writes the deployment record, including its deployment block, during the local execution before the transactions are confirmed.

Comments

For chain 8453 assert in the script that VAPI_TOKEN equals the known vAPI address and that its decimals and total supply match expectations, and that FOUNDATION_MULTISIG has code and is the intended Safe with the agreed signer threshold. Write the deployment record only from confirmed receipts. In the gate constructor consider checking that the staking contract answers stakingToken and cooldownSeconds as expected.

Alleviation

Fixed in the remediated commit. The deployment script now validates its inputs before anything is broadcast: the token must have code and report 18 decimals and the owner must be non-zero on every chain, and on Base mainnet the token must be the known vAPI address and the owner must be a contract whose Safe threshold is at least two. The script only stages a pending record, and the canonical record is written afterwards from confirmed receipts, refusing a wrong chain, a failed receipt or addresses that do not match the created contracts. The gate constructor now checks that the staking contract reports a token with code and the seven-day cooldown. We verified the change in code, with the project's tests, with our own checks of the record writer and with a run against the real token on a fork of Base mainnet. Still to be done after the deployment: confirm the identity and signers of the Foundation Safe and show that the deployed bytecode matches the reviewed commit.

optimization Issues | 4 findings

Pending

#1 optimization Issue
Total stake is read back from storage right after it was written
VapiStaking.sol
L84-86
L108-121
Description

stake and requestUnstake update totalStaked in storage and then read it again to write the total checkpoint. Keeping the new total in a local variable avoids the extra storage read on every stake and unstake request.

Comments

Compute the new total in a local variable, store it once and pass the local value to _writeStakeCheckpoints in both stake and requestUnstake.

Alleviation

Not changed in the remediation. The item is optional and has no security impact.

Pending

#2 optimization Issue
Pending threshold fields occupy two storage slots
ThresholdReviewersGate.sol
L20-21
Description

pendingThreshold is a uint256 and pendingThresholdValidAt a uint48 in a separate slot, so every proposal writes two slots and every execution clears two slots. The threshold is bounded by one million tokens and fits comfortably in 208 bits next to the timestamp.

Comments

Store the pending value and its timestamp in one packed struct, for example a uint208 value and a uint48 validAt, while keeping the existing external getters.

Alleviation

Not changed in the remediation. The item is optional and has no security impact.

Pending

#3 optimization Issue
Recent historical lookups use the full binary search
VapiStaking.sol
L162
L167
Description

Both historical views call upperLookup, which searches the complete checkpoint history. The documented consumer always reads the most recent midnight, which upperLookupRecent locates faster once a wallet or the total has many checkpoints. The saving matters mostly when view calls run under an RPC gas cap.

Comments

Use upperLookupRecent in stakedBalanceAt and totalStakedAt. The returned values are identical and the documented reads of the latest midnight become cheaper for long histories.

Alleviation

Not changed in the remediation. The item is optional and has no security impact.

Pending

#4 optimization Issue
Global totals that change together use separate slots
VapiStaking.sol
L38-41
Description

requestUnstake updates totalStaked and totalPendingUnstake in the same transaction, each in its own storage slot. With a fixed supply of one hundred million tokens at 18 decimals both values fit in 128 bits and could share a single slot.

Comments

Pack totalStaked and totalPendingUnstake into one slot as two uint128 values and keep uint256 getters for the interface. This saves one storage write in every unstake request.

Alleviation

Not changed in the remediation. The item is optional and has no security impact.

informational Issues | 8 findings

Resolved

#1 informational Issue
Threshold proposals never expire and cannot be withdrawn
ThresholdReviewersGate.sol
L44-66
Description

proposeThreshold stores one pending value together with a validAt timestamp, and executeThreshold applies it at any moment after that timestamp. A proposal has no expiry and can only be replaced, never withdrawn. A change that reviewers saw announced and then reasonably assumed abandoned can therefore be executed months later with immediate effect, which removes the notice period the seven-day timelock is meant to provide. Raising the threshold this way makes reviewers ineligible for new panels in the same block, as demonstrated with a proposal executed a year after it was made.

Comments

Add an owner-only cancelThreshold function that clears the pending value and emits an event, and give every proposal a grace period, for example fourteen days after validAt, after which executeThreshold reverts and a fresh proposal with a new notice period is required. This keeps the seven-day delay meaningful for reviewers who follow the announced changes.

Alleviation

Fixed in the remediated commit. A proposal can now only be executed within an inclusive fourteen-day window after its seven-day notice ends, and afterwards a fresh proposal with a new notice period is required. The owner can cancel a pending or expired proposal, which clears both stored values and emits an event, and a view returns the last executable second. We verified the exact boundary seconds and showed that a proposal left for a year can no longer be executed.

Resolved

#2 informational Issue
No minimum position size
VapiStaking.sol
L72-91
Description

stake accepts any non-zero amount and every wallet that goes from zero to a positive balance increments stakerCount. Positions of a single wei from many fresh addresses inflate the staker count shown in the console and enlarge the list of wallets that the documented daily Compute snapshot reads one by one. Whether this can delay or stall the snapshot depends on the off-chain implementation, which was not part of this review; on chain the effect is limited to the staker count. In testing, 250 one-wei positions produced a staker count of 250 with a total stake of 250 wei.

Comments

Introduce a minimum active position, for example one vAPI, enforced in stake and in requestUnstake so that a remaining active balance is either zero or at least the minimum. The off-chain snapshot job should additionally skip wallets whose balance cannot earn a non-zero limit, and read balances in batches rather than one call per wallet.

Alleviation

Fixed in the remediated commit. A stake must leave the wallet with at least one vAPI, and an unstake request must leave either nothing or at least one vAPI behind. Cancelling a request cannot create a smaller position. We confirmed that the earlier scenario of 250 one-wei stakes now reverts entirely, and that no active balance below the minimum was reachable in long randomized transaction sequences. Filtering and batching in the off-chain snapshot job remain the project's responsibility.

Resolved

#3 informational Issue
Historical lookups accept the current timestamp
VapiStaking.sol
L160-169
L179-182
Description

_validateLookupTime only rejects timestamps strictly greater than block.timestamp. All writes within one second share a single checkpoint key, so a lookup at the current timestamp returns a value that later transactions in the same block can still change. The documented consumer reads past midnights and is not affected, but an on-chain integrator reading stakedBalanceAt or totalStakedAt for the current second can be shown a balance that is staked and unstaked again within the same block.

Comments

Reject lookups where the timestamp is greater than or equal to block.timestamp, which is the convention OpenZeppelin uses for past votes, or document clearly that only past timestamps are final and that integrators must never read the current second.

Alleviation

Fixed in the remediated commit. Historical lookups now reject the current second as well as future ones, so every value that can be read is final. We confirmed that a lookup in the same second reverts and that the same second returns its final value once the block time has moved on.

Resolved

#4 informational Issue
Single-step ownership with an available renounce path
ThresholdReviewersGate.sol
L11
L33
Description

The gate inherits Ownable, so transferOwnership takes effect immediately and renounceOwnership remains callable. A mistyped transfer or an accidental renounce freezes the reviewer threshold permanently. The Tasks deployment also relies on the gate owner being the same address as the escrow council, which is only checked once when the stack is deployed.

Comments

Use Ownable2Step so that a new owner has to accept the role, and override renounceOwnership to revert unless a permanently frozen threshold is an intended end state. Keep the owner a multisig and re-verify that it still matches the escrow council whenever either role changes.

Alleviation

Fixed in the remediated commit. The gate uses two-step ownership, so a new owner only takes over after accepting, and renouncing ownership always reverts. The interface exposes the pending owner and both transfer steps. Keeping the gate owner equal to the escrow council remains an operational task for any future change of either role.

Resolved

#5 informational Issue
Interfaces carry no NatSpec although the implementation inherits from them
IVapiStaking.sol
L4-28
Description

Every public function of VapiStaking uses inheritdoc pointing at IVapiStaking, but the interface has no documentation, so the generated documentation of the staking contract is empty. ThresholdReviewersGate and IReviewersGate document no functions either. Rules that matter to integrators, such as the meaning of stakerCount, the exclusion of pending principal from stakedBalance and the finality of historical lookups, are only described in external documents.

Comments

Move the function documentation into IVapiStaking and IReviewersGate with notice, param and return tags that state units and edge cases, so that the interfaces and the implementations are self-describing for integrators.

Alleviation

Fixed in the remediated commit. Every function, error and event of both interfaces and contracts is now documented with units, revert conditions and edge cases, and the contracts inherit that documentation. We checked the content against the code. If the initial threshold changes for the deployment, the documented initial value has to be updated as well.

Resolved

#6 informational Issue
A custody shortfall is reported as zero
VapiStaking.sol
L143-147
Description

unaccountedStakingToken returns zero whenever the token balance is below totalStaked plus totalPendingUnstake. Monitoring that relies on this view would therefore show a healthy state even if the contract held less than it owes. With the plain vAPI token a shortfall cannot arise, so the point is about observability rather than an exploitable condition.

Comments

Expose the shortfall explicitly, for example through a custodyDeficit view or a signed difference, and monitor it next to the surplus. Comparing the received amount with the requested amount in stake would also make the contract fail closed if the token ever behaved differently from a plain ERC-20.

Alleviation

Fixed in the remediated commit. A new view reports any shortfall between the recorded principal and the tokens actually held, next to the existing surplus view. We demonstrated with a token that allows balances to be clawed back that a shortfall is now reported correctly. The optional check of the received amount during staking was not adopted, which is acceptable because the token address is pinned on mainnet.

Resolved

#7 informational Issue
Unstake requests cannot be cancelled
VapiStaking.sol
L94-124
Description

After requestUnstake the amount stops counting immediately and can only be recovered through withdraw once the cooldown has passed. A reviewer who requests by mistake loses eligibility for new panels and can only restore it by depositing additional tokens, and no further request is possible until the first one has been withdrawn.

Comments

Consider a cancelUnstake function that moves the pending amount back into the active balance and writes a new checkpoint. It cannot create double counting because the principal never leaves the contract, and it removes an avoidable seven-day lockout for users who request by mistake.

Alleviation

Fixed in the remediated commit. A staker can cancel the pending request before or after the cooldown, which restores the full amount to the active balance, writes new checkpoints, restores the staker count and emits an event without moving any tokens. Earlier history is not rewritten, and cancelling and requesting again starts a new seven-day cooldown, so the snapshot protection is unchanged. Because eligibility can now be switched off and on again at no cost, the escrow side should read reviewer eligibility at a fixed past time when it fixes panel selection.

Resolved

#8 informational Issue
Compiler version with known issues
VapiStaking.sol
L2
Description

Both staking contracts pin Solidity 0.8.35, for which five compiler bugs are listed, including two of medium severity that are fixed in 0.8.36 and 0.8.37. None of their trigger conditions appear in this code: there is no require with custom errors, no deletion of single bytes elements in memory, no recursion and no custom storage layout. The exposure is therefore theoretical.

Comments

Move to the latest patch release, 0.8.37 or newer, before the mainnet deployment and keep the version pinned exactly. Run the full test suite again after the upgrade because via-IR code generation can change between releases.

Alleviation

Fixed in the remediated commit. The staking contracts, the staking interface and the deployment script are pinned to 0.8.37, the newest released compiler, and the full verification was repeated on that build. The gate interface keeps a version range because the unchanged registries compiled with 0.8.35 import it, which is acceptable for an interface without bytecode. One low severity optimizer issue published after 0.8.37 still affects every recent release and will be fixed in 0.8.38; the testing on the compiled code showed no deviation, so no action is needed before deployment.