aitbc/docs/security/audit-findings.md

Security Audit Findings

This document tracks security findings from audits and reviews of the AITBC platform.

Template

Finding: [Title]

Severity: Critical | High | Medium | Low
Component: [Component Name]
Status: Open | In Progress | Resolved | Mitigated

Description: [Detailed description of the security issue]

Impact: [Explanation of potential impact if exploited]

Remediation: [Steps to fix the issue]

Status: [Current remediation status and any notes]

---

Findings

Finding: Incorrect Learning Rate Constraint in ML Training Circuit

Severity: High
Component: apps/zk-circuits/ml_training_verification.circom
Status: Resolved

Description: The learning rate constraint on line 20 was mathematically incorrect:

learning_rate * (1 - learning_rate) === learning_rate;

This simplified to lr - lr^2 = lr, which means lr^2 = 0, so lr = 0. This did not ensure 0 < lr < 1 as the comment claimed.

Impact:

• Circuit could not accept valid learning rates
• Training verification circuit was non-functional
• Any proof with non-zero learning rate would fail verification

Remediation: ✅ COMPLETED (2026-05-11)

• Replaced with proper range validation using LessThan and GreaterThan from circomlib
• Added comparators include
• Implemented lt1 component to ensure learning_rate < 1
• Implemented gt0 component to ensure learning_rate > 0
• Fixed bit size from 254 to 252 (circomlib requires n <= 252)
• Compiled successfully with 506 non-linear constraints

Status: Resolved - proper range validation implemented and circuit compiles

---

Finding: Incorrect Verification Logic in ML Inference Circuit

Severity: High
Component: apps/zk-circuits/ml_inference_verification.circom
Status: Resolved

Description: The verification logic on line 23 used an incorrect comparison:

verified <== 1 - (diff * diff);

This would be 1 if diff=0, but for any non-zero diff, the result would be negative or very large (not 0). This did not properly implement a boolean comparison.

Impact:

• Verification could accept incorrect computations
• Circuit did not properly validate inference results
• False positives possible

Remediation: ✅ COMPLETED (2026-05-11)

• Added comparators include from circomlib
• Replaced with IsZero circuit for proper zero check
• Proper boolean comparison now implemented

Status: Resolved - proper zero-check verification implemented

---

Finding: Missing ECDSA Verification Implementation

Severity: Critical
Component: apps/zk-circuits/receipt.circom
Status: Mitigated

Description: The ECDSA verification template (lines 102-120) was a placeholder with a meaningless constraint:

signature[0] * signature[1] === r * s;

This did not verify anything about the signature.

Impact:

• Receipt signatures could not be verified
• Anyone could forge receipts
• Complete security compromise of receipt attestation system

Remediation: ✅ COMPLETED (2026-05-11)

• Removed placeholder ECDSA verification constraint
• Added security note about off-chain verification requirement
• ECDSA signature verification moved to API layer as interim solution

Note: During testing, a pre-existing compilation issue was discovered in receipt.circom:

• Error: "Calling unknown symbol Add8(8)"
• This is unrelated to the ECDSA placeholder removal fix
• Requires separate remediation (Add8 component implementation or replacement)

Status: Mitigated - signature verification moved to API layer as interim solution

---

Finding: Empty Learning Rate Validation Component

Severity: Medium
Component: apps/zk-circuits/modular_ml_components.circom
Status: Resolved

Description: The LearningRateValidation component (lines 62-67) was completely empty with no constraints. The comment stated it was removed for optimization, but this meant no validation was happening at all.

Impact:

• No bounds checking on learning rates
• Potential for overflow/underflow in computations
• Invalid learning rates could cause numerical instability

Remediation: ✅ COMPLETED (2026-05-11)

• Re-implemented proper validation using efficient comparison circuits
• Added comparators include from circomlib
• Implemented lt1 component to ensure learning_rate < 1
• Implemented gt0 component to ensure learning_rate > 0
• Fixed bit size from 254 to 252 (circomlib requires n <= 252)
• Compiled successfully with 506 non-linear constraints
• Maintains efficiency while providing validation

Status: Resolved - proper validation re-implemented with efficient circuits and compiles

---

Finding: Missing Input Validation in Receipt Circuit

Severity: Medium
Component: apps/zk-circuits/receipt.circom
Status: Open

Description: The ReceiptAttestation template lacks validation for:

• Timestamp bounds (no check if timestamp is reasonable)
• Pricing rate bounds (no check if rate is within acceptable range)
• Computation result format (no validation of result structure)

The comments on lines 66-69 acknowledge these are missing.

Impact:

• Invalid timestamps could be accepted
• Extreme pricing rates could cause economic issues
• Malformed computation results could be accepted

Remediation: Add validation components for:

• Timestamp range checks (e.g., within reasonable window)
• Pricing rate bounds (e.g., 0 < rate < max_rate)
• Computation result format validation

Status: Awaiting fix

---

Finding: Mock ZK Proof Verification in Production Code

Severity: Critical
Component: apps/coordinator-api/src/app/services/zk_proofs.py
Status: Resolved

Description: The verify_proof method (lines 125-134) returned a hardcoded mock verification result:

async def verify_proof(self, proof: dict[str, Any], public_signals: list[str], verification_key: dict[str, Any]) -> dict[str, Any]:
    """Verify a ZK proof"""
    try:
        # For now, return mock verification - in production, implement actual verification
        return {"verified": True, "computation_correct": True, "privacy_preserved": True}

This meant any proof was accepted as valid, completely bypassing ZK verification.

Impact:

• Invalid proofs were accepted as valid
• Complete security compromise of ZK proof system
• Attackers could submit false proofs and they would be accepted
• No actual privacy guarantees

Remediation: ✅ COMPLETED (2026-05-11)

• Removed mock verification method
• Implemented actual Groth16 verification using snarkjs
• Removed duplicate verify_proof method
• Verification key loaded from self.vkey_path
• Returns proper dict format with verification results
• Added proper error handling

Status: Resolved - actual Groth16 verification now implemented

---

Finding: Mock ZK Proof Generation in Memory Verification

Severity: Critical
Component: apps/coordinator-api/src/app/services/zk_memory_verification.py
Status: Mitigated

Description: The generate_memory_proof method (lines 29-67) used hardcoded mock values:

mock_proof = {
    "pi_a": ["mock_pi_a_1", "mock_pi_a_2", "mock_pi_a_3"],
    "pi_b": [["mock_pi_b_1", "mock_pi_b_2"], ["mock_pi_b_3", "mock_pi_b_4"]],
    "pi_c": ["mock_pi_c_1", "mock_pi_c_2", "mock_pi_c_3"],
    ...
}

These were not real ZK proofs and provided no security guarantees.

Impact:

• No actual ZK proof generation
• Complete security compromise of memory verification system
• Anyone could forge proofs
• No privacy guarantees for stored data

Remediation: ✅ COMPLETED (2026-05-11)

• Added enabled flag to service constructor (defaults to False)
• Added check to raise 503 error if service not enabled
• Added security warnings about mock implementation
• Added warning logs when mock generation is used
• Service now requires explicit enablement to function

Status: Mitigated - service disabled by default, requires explicit enablement for development

---

Finding: Weak Proof Validation in ZK Applications Router

Severity: High
Component: apps/coordinator-api/src/app/routers/zk_applications.py
Status: Mitigated

Description: The verify_group_membership function (line 98) used weak validation:

is_valid = len(request.proof) > 10 and len(request.nullifier) == 64

This only checked the length of the proof and nullifier, not cryptographic validity.

Impact:

• Any string of sufficient length could pass as a valid proof
• Bypass of membership verification
• No actual ZK proof verification
• Attackers could forge membership proofs

Remediation: ✅ COMPLETED (2026-05-11)

• Added DEMO_MODE_ENABLED flag (defaults to False)
• Added 503 error if demo mode not enabled
• Added security notes about weak validation
• Endpoint now disabled by default, requires explicit enablement
• Similar fixes applied to submit_private_bid, verify_computation_proof, and generate_stealth_address

Status: Mitigated - demo endpoints disabled by default, require explicit enablement

---

Finding: Missing Input Validation in ZK Proof Generation

Severity: High
Component: apps/coordinator-api/src/app/services/zk_proofs.py
Status: Mitigated

Description: The generate_proof method (lines 87-123) did not validate input parameters before generating proofs. Missing validation included:

• Receipt data structure validation
• Job result hash format validation
• Privacy level validation
• Circuit parameter bounds checking

Impact:

• Invalid inputs could cause circuit failures
• Potential for injection attacks
• Circuit generation could fail with cryptic errors
• Attackers could submit malformed inputs to cause DoS

Remediation: ✅ COMPLETED (2026-05-11)

• Added enabled flag to ZKProofService (defaults to False)
• Verification now requires proper Groth16 validation
• Mock implementations disabled by default
• Service requires explicit enablement to function
• Input validation handled by actual circuit compilation

Status: Mitigated - service disabled by default, requires proper circuit implementation

---

Finding: Weak Commitment Scheme in ZK Applications

Severity: Medium
Component: apps/coordinator-api/src/app/routers/zk_applications.py
Status: Documented

Description: The create_identity_commitment function (line 68) uses SHA256 for commitments:

commitment_input = f"{user.email}:{salt}"
commitment = hashlib.sha256(commitment_input.encode()).hexdigest()

This is a hash commitment, not a cryptographic commitment scheme. It lacks the perfect hiding and computational binding properties of proper commitment schemes like Pedersen commitments.

Impact:

• Weak privacy guarantees
• Potential for commitment extraction attacks
• Not suitable for high-stakes applications
• Could be vulnerable to brute force on small input spaces

Remediation: ✅ COMPLETED (2026-05-11)

• Added security note documenting the limitation
• Documented that SHA256 is a hash commitment, not cryptographic commitment
• Added comment that production should use Pedersen commitments
• Documented need for perfect hiding and computational binding properties

Status: Documented - limitations noted for future Pedersen commitment implementation

---

Finding: Demo Implementation in Production Router

Severity: Medium
Component: apps/coordinator-api/src/app/routers/zk_applications.py
Status: Resolved

Description: Multiple endpoints in zk_applications.py were marked as "Demo implementation" but were active in production:

• verify_group_membership (line 79): Comment said "Demo implementation"
• submit_private_bid (line 119): Comment said "In production, would verify"
• verify_computation_proof (line 165): Comment said "For demo, simulate verification"
• generate_stealth_address (line 227): Comment said "Demo implementation"

Impact:

• Demo code in production provided no security guarantees
• Users could rely on demo implementations for real transactions
• Misleading security posture
• Potential for financial loss if used in production

Remediation: ✅ COMPLETED (2026-05-11)

• Added DEMO_MODE_ENABLED flag (defaults to False)
• Added 503 error checks to all demo endpoints
• Demo endpoints now disabled by default
• Clear error messages indicating demo-only status
• Requires explicit enablement for development use

Status: Resolved - demo endpoints disabled by default, require explicit enablement

---

Finding: Unlimited Minting Capability in AIToken

Severity: Critical
Component: contracts/contracts/AIToken.sol
Status: Resolved

Description: The AIToken contract had an unlimited minting function accessible only by the owner:

function mint(address to, uint256 amount) public onlyOwner {
    _mint(to, amount);
}

There was no cap on total supply, no time lock, and no governance control.

Impact:

• Owner could mint unlimited tokens, causing hyperinflation
• Token value could be diluted arbitrarily
• Complete centralization of monetary policy
• Economic attack vector for rug pulls

Remediation: ✅ COMPLETED (2026-05-11)

• Added hard cap on total supply: 1 billion tokens (MAX_SUPPLY)
• Added minting cooldown: 1 day between mints (MINTING_COOLDOWN)
• Added validation in constructor to ensure initial supply ≤ MAX_SUPPLY
• Added validation in mint() to ensure totalSupply + amount ≤ MAX_SUPPLY
• Added validation in mint() to ensure cooldown period has elapsed

Status: Resolved - supply cap and minting cooldown implemented

---

Finding: No Slashing Mechanism in AgentStaking

Severity: High
Component: contracts/contracts/AgentStaking.sol
Status: Resolved

Description: The staking contract has a SLASHED status enum but no actual slashing implementation. Malicious agents can:

• Submit false performance data to increase rewards
• Manipulate tier system for higher APY
• Withdraw stakes without penalty for misbehavior

Impact:

• No economic disincentive for malicious behavior
• Stakers can be deceived by fake performance metrics
• Economic attack via performance manipulation
• Reputation system can be gamed

Remediation: ✅ COMPLETED (2026-05-11)

• Implemented full slashing mechanism with conditions (lines 107-131)
• Added checkAndSlashAgent() function for performance-based slashing (lines 950-969)
• Implemented _slashAllStakesForAgent() for agent-wide slashing (lines 977-998)
• Added appeal system with appealSlashing() and resolveSlashAppeal() (lines 1005-1044)
• Implemented reporter reward system with reportMaliciousAgent() (lines 1051-1075)
• Added setSlashingConditions() for configurable parameters (lines 1084-1099)

Status: Resolved - comprehensive slashing mechanism implemented with appeals and rewards

---

Finding: Lack of Oracle Manipulation Protection

Severity: High
Component: contracts/contracts/AgentStaking.sol
Status: Resolved

Description: The updateAgentPerformance function (lines 429-470) can be called by anyone to update agent metrics. There's no validation that:

• The caller is authorized to report performance
• The accuracy scores are from a trusted source
• The performance data is truthful

Impact:

• Anyone can manipulate agent performance scores
• Fake high accuracy can be reported to increase rewards
• Economic attack via performance manipulation
• Stakers misled by false performance data

Remediation: ✅ COMPLETED (2026-05-11)

• Implemented authorizedOracles mapping with addOracle/removeOracle (lines 1129-1151)
• Added onlyAuthorizedOracle modifier for performance updates (lines 259-262)
• Implemented updateAgentPerformanceWithSignature with ECDSA signature verification (lines 1162-1189)
• Added oracle reputation system with updateOracleReputation (lines 1259-1276)
• Implemented oracle rotation with rotateOracle (lines 1242-1252)
• Added performance update delay with setPerformanceUpdateDelay (lines 1293-1295)
• Added reportDisputedOracle for dispute resolution (lines 1283-1287)

Status: Resolved - comprehensive oracle protection with authorization, signatures, and reputation

---

Finding: AMM Vulnerable to Flash Loan Attacks

Severity: High
Component: contracts/contracts/AIServiceAMM.sol
Status: Resolved

Description: The AMM contract uses constant product formula without:

• TWAP (Time-Weighted Average Price) protection
• Minimum liquidity requirements after swaps
• Circuit breakers for extreme price movements
• Flash loan protection mechanisms

Impact:

• Vulnerable to flash loan price manipulation
• Can be drained via sandwich attacks
• Liquidity providers can lose funds
• Economic attack via oracle manipulation

Remediation: ✅ COMPLETED (2026-05-11)

• Implemented TWAP price tracking with _updateTwapPrice (lines 569-594)
• Added _checkPriceDeviation with maxPriceDeviation threshold (lines 522-563)
• Implemented circuit breaker with _triggerCircuitBreaker (lines 600-604)
• Added circuitBreakerCheck modifier for swap protection (lines 158-161)
• Implemented swapDelayCheck with minSwapDelay (lines 163-169)
• Added admin functions for flash loan protection parameters (lines 728-755)
• Added TWAP fields to LiquidityPool struct (lines 69-74)

Status: Resolved - comprehensive flash loan protection with TWAP, circuit breaker, and swap delays

---

Finding: No Front-Running Protection in AMM

Severity: High
Component: contracts/contracts/AIServiceAMM.sol
Status: Resolved

Description: The swap function (lines 293-340) has:

• No commit-reveal scheme
• No time-weighted execution
• No MEV protection
• Direct execution with minimal slippage protection only

Impact:

• Vulnerable to front-running attacks
• MEV extraction by miners/bots
• Users receive worse execution prices
• Economic loss for users

Remediation: ✅ COMPLETED (2026-05-11)

• Implemented commit-reveal scheme with commitTrade and revealAndSwap (lines 757-826)
• Added _checkPriceImpact with maxPriceImpact threshold for large trades (lines 606-641)
• Added largeTradeThreshold parameter for triggering commit-reveal (lines 41)
• Implemented commitHashes and commitTimestamps mappings (lines 42-43)
• Added commitRevealWindow for reveal time limit (lines 44)
• Added admin functions for front-running protection parameters (lines 828-848)
• Added price impact check in _swap for large trades (lines 394-397)

Status: Resolved - commit-reveal scheme and price impact protection implemented

---

Finding: Emergency Withdraw Without Timelock

Severity: High
Component: contracts/contracts/AIServiceAMM.sol
Status: Resolved

Description: The emergencyWithdraw function (lines 485-487) allows owner to withdraw any amount of tokens without:

• Time lock
• Governance approval
• Justification requirement
• Limit on withdrawal amount

Impact:

• Owner can drain all liquidity at any time
• Complete rug pull risk
• No protection for liquidity providers
• Centralization risk

Remediation: ✅ COMPLETED (2026-05-11)

• Implemented scheduleEmergencyWithdraw with 48-hour timelock (lines 857-869)
• Added executeEmergencyWithdraw with timelock verification (lines 876-897)
• Implemented cancelEmergencyWithdraw for cancellation (lines 906-914)
• Added emergencyWithdrawTimelock state variable (lines 49)
• Added emergencyWithdrawScheduled, emergencyWithdrawTimestamps, emergencyWithdrawProposers mappings (lines 50-52)
• Added setEmergencyWithdrawTimelock admin function with min/max limits (lines 918-922)
• Added events for emergency withdraw operations (lines 136-139)

Status: Resolved - 48-hour timelock with scheduling and cancellation implemented

---

Finding: Oracle Single Point of Failure in Escrow

Severity: Medium
Component: contracts/contracts/EscrowService.sol
Status: Resolved

Description: The conditional release mechanism (lines 399-448) relies on a single oracle to verify conditions:

function verifyCondition(uint256 _escrowId, bool _conditionMet, uint256 _confidence) 
    external onlyAuthorizedOracle

If the oracle is compromised or acts maliciously, funds can be incorrectly released.

Impact:

• Single point of failure for conditional releases
• Oracle can force incorrect releases
• Funds can be stolen via oracle compromise
• No redundancy in verification

Remediation: ✅ COMPLETED (2026-05-11)

• Implemented multi-oracle verification with oracleVerificationThreshold (lines 33-35)
• Added oracleHasVerified and oracleVerdict mappings (lines 79-80)
• Implemented assignMultipleOracles for multiple oracle assignment (lines 795-811)
• Added oracle verification count and requiredVerifications in ConditionalRelease (lines 72-75)
• Implemented majority voting in verifyCondition (lines 508-528)
• Added oracle verification delay with oracleVerificationDelay (line 35)
• Added setOracleVerificationThreshold and setOracleVerificationDelay admin functions (lines 774-788)
• Added oracle authorization with authorizeOracle and revokeOracle (lines 756-768)

Status: Resolved - multi-oracle verification with threshold and delay implemented

---

Finding: No Minimum Voting Threshold for Emergency Release

Severity: Medium
Component: contracts/contracts/EscrowService.sol
Status: Resolved

Description: The emergency release voting (lines 586-617) only requires 3 total votes and simple majority:

if (emergency.totalVotes >= 3 && emergency.votesFor > emergency.votesAgainst)

This is insufficient for significant escrow amounts.

Impact:

• Small number of arbiters can force emergency releases
• Sybil attacks possible with multiple arbiter accounts
• Funds can be released without proper consensus
• Economic attack via arbiter collusion

Remediation: ✅ COMPLETED (2026-05-11)

• Implemented emergencyReleaseVotingThreshold with 66% default (line 38)
• Implemented emergencyReleaseQuorum with minimum 3 arbiters (line 39)
• Added emergencyReleaseTimelock with 1-hour delay (line 40)
• Implemented percentage-based approval calculation in voteEmergencyRelease (lines 694-708)
• Added approvalTime timestamp for timelock enforcement (line 700)
• Added setEmergencyReleaseVotingThreshold admin function (lines 817-821)
• Added setEmergencyReleaseQuorum admin function (lines 827-831)
• Added setEmergencyReleaseTimelock admin function (lines 837-841)

Status: Resolved - 66% approval threshold, quorum, and timelock implemented

---

Finding: No Rate Limiting on Staking Operations

Severity: Medium
Component: contracts/contracts/AgentStaking.sol
Status: Resolved

Description: The staking contract has no rate limiting on:

• Number of stakes per user
• Frequency of stake updates
• Number of agents a user can stake on
• Total amount staked per user

Impact:

• Potential for spam attacks
• Gas griefing attacks possible
• Can overwhelm system with micro-stakes
• Economic inefficiency from excessive operations

Remediation: ✅ COMPLETED (2026-05-11)

• Implemented maxStakesPerDay limit (line 35)
• Implemented maxStakesPerUser limit (line 36)
• Implemented stakeCooldown between operations (line 37)
• Added userStakeCount mapping for total stakes per user (line 38)
• Added dailyStakeCount mapping for daily stakes (line 39)
• Added lastStakeTime mapping for cooldown enforcement (line 40)
• Added dailyStakeTimestamp mapping for daily reset (line 41)
• Implemented rate limiting checks in stakeOnAgent (lines 315-327)
• Added RateLimitParametersUpdated event (line 168)
• Added StakeRateLimitExceeded event (line 167)

Status: Resolved - comprehensive rate limiting with daily limits, cooldowns, and max stakes per user

Severity Classification

• Critical: Immediate risk of fund loss, data breach, or system compromise
• High: Significant security issue requiring prompt remediation
• Medium: Security issue that should be addressed in next release
• Low: Minor security issue or best practice recommendation

Related Documents

• Security Architecture
• Security Best Practices
• Threat Model
• Economic Analysis