Security Report

Professional Smart Contract Security Assessment
CONTRACT
LampPost Slots v4
AUDIT DATE
April 03, 2026
BLOCKCHAIN
Solana
FRAMEWORK
Anchor

🔍 Executive Summary

AnchorScan conducted a comprehensive security assessment of the LampPost Slots v4 smart contract, an escrow and auction system built on Solana using the Anchor framework. Our analysis identified 8 potential vulnerabilities, of which 2 were confirmed as exploitable security issues requiring immediate attention before mainnet deployment.

The contract implements sophisticated escrow functionality with time-based releases and dispute resolution mechanisms. While the majority of flagged issues were determined to be false positives due to Solana's runtime protections and Anchor's constraint system, we discovered critical flaws in the timeline manipulation logic that could result in complete loss of escrowed funds. Additionally, MEV extraction opportunities exist in the auto-release mechanism.

Primary Concerns: The most severe vulnerability (F005) allows developers to manipulate payment timelines unilaterally, potentially shortening client review periods to as little as 24 hours regardless of original agreements. This represents a complete breakdown of escrow fairness and could result in forced payments without adequate review time.

🎯 Audit Scope and Methodology

Scope

This pre-audit assessment covered the complete LampPost Slots v4 codebase, focusing on:

Methodology

Our assessment employed automated vulnerability detection followed by manual verification of each finding against Solana runtime characteristics and Anchor framework protections. Each issue was evaluated for exploitability, severity, and business impact.

📊 Risk Summary

0
Critical
1
High
1
Medium
0
Low
6
Info
Finding ID Title Severity Exploitable CVSS Score
F005 Unilateral Auto-Release Manipulation HIGH ✅ Yes 7.8
F002 Missing Signer Requirements MEDIUM ✅ Yes 5.3
F001, F003, F004, F006, F007, F008 Various False Positives INFO ❌ No N/A

🚨 Detailed Findings

HIGH SEVERITY
CVSS: 7.8

F005 - Unilateral Auto-Release Manipulation

Description

The request_review() function allows developers to unilaterally modify the auto_release_at timestamp without client consent. This can drastically shorten the client's review window, potentially reducing it from the original agreement to just 24 hours, regardless of when the function is called.

Attack Vector

  1. Developer submits deliverable hash via submit_deliverable()
  2. Just before original auto_release_at deadline, developer calls request_review() with minimum 24 hours
  3. This overwrites auto_release_at to current_time + 24 hours, potentially shortening client's review window drastically
  4. Client loses expected review time and funds auto-release to developer after shortened window
  5. Developer can repeat this manipulation multiple times to minimize client review opportunities

Financial Impact

Complete loss of escrowed funds through timeline manipulation. This vulnerability affects 100% of the job amount by denying fair review periods, potentially forcing payments for inadequate or incomplete deliverables.

Recommended Fix

Modify request_review() to ensure minimum review time from current moment rather than allowing deadline shortening:

let min_review_from_now = clock.unix_timestamp + review_secs;
ctx.accounts.job.auto_release_at = std::cmp::max(
    ctx.accounts.job.auto_release_at,
    min_review_from_now
);

This ensures the deadline can only be extended, never shortened, preserving the client's original review window.

MEDIUM SEVERITY
CVSS: 5.3

F002 - Missing Signer Requirements

Description

The auto_release() function can be called by anyone after the deadline without requiring signatures from client or developer. While this doesn't allow direct fund theft, it enables MEV extraction and forced releases against parties' wishes.

Attack Vector

  1. Wait for any job to reach its auto_release_at timestamp
  2. Call auto_release() from any account as there are no signer restrictions
  3. Extract MEV by timing the call strategically or bundling with other transactions
  4. Force unwanted automatic releases even if parties are negotiating

Financial Impact

No direct fund theft but enables MEV extraction and forced releases against parties' wishes, potentially disrupting ongoing negotiations and allowing third parties to profit from transaction timing.

Recommended Fix

Add constraint requiring either client or developer to sign the transaction:

#[account(constraint = client.key() == job.client || developer.key() == job.developer @ LamppostError::Unauthorized)]

Make one of them a Signer<'info> to ensure only authorized parties can trigger releases.

⚠️
NOT READY FOR MAINNET

Critical vulnerabilities must be resolved before deployment. The contract requires fixes for timeline manipulation and access control issues.

✅ Overall Verdict

Recommendation: NEEDS FIXES FIRST

The LampPost Slots v4 contract demonstrates solid understanding of Solana development practices and proper use of Anchor constraints in most areas. However, the timeline manipulation vulnerability (F005) represents a critical flaw that could result in complete loss of user funds through unfair escrow practices.

Required Actions Before Mainnet:

Once these issues are resolved, the contract shows promise for secure escrow operations on Solana. The development team demonstrated good security awareness in other areas, and most flagged issues were false positives due to Solana's inherent protections.

⚖️ Disclaimer

This is a preliminary security assessment and not a complete audit. This pre-audit report is provided for informational purposes and should not be considered as investment advice or a guarantee of security. Smart contract security is complex and evolving. Additional vulnerabilities may exist that were not identified in this assessment. A comprehensive formal audit by multiple security firms is recommended before mainnet deployment. AnchorScan assumes no liability for any losses resulting from the use of this information or the audited contract.