diff --git a/app/app/api/a2a/route.ts b/app/app/api/a2a/route.ts
index d31874a..c4b3969 100644
--- a/app/app/api/a2a/route.ts
+++ b/app/app/api/a2a/route.ts
@@ -2,8 +2,13 @@ import { NextRequest, NextResponse } from "next/server";
 import { prisma } from "@/lib/prisma";
 import { buildA2AResponse, buildA2AError } from "@/lib/aip/a2a";
 import type { A2ARequest } from "@/lib/aip/a2a";
+import { enforceIpLimit } from "@/lib/rateLimit";
 
 export async function POST(request: NextRequest) {
+  // Throttle: this JSON-RPC endpoint can create Job rows; cap unauthenticated
+  // abuse (spam job creation / resource exhaustion).
+  const limited = await enforceIpLimit(request, "a2a");
+  if (limited) return limited;
   try {
     const body: A2ARequest = await request.json();
 
diff --git a/app/app/api/agents/stake/route.ts b/app/app/api/agents/stake/route.ts
index 2f1f732..c6f4c90 100644
--- a/app/app/api/agents/stake/route.ts
+++ b/app/app/api/agents/stake/route.ts
@@ -1,7 +1,7 @@
 import { NextRequest, NextResponse } from "next/server";
 import { prisma } from "@/lib/prisma";
 import { enforceIpLimit } from "@/lib/rateLimit";
-import { requireAuth } from "@/lib/require-auth";
+import { requireAuth, requireWalletMatch } from "@/lib/require-auth";
 
 /**
  * POST /api/agents/stake
@@ -31,6 +31,11 @@ export async function POST(req: NextRequest) {
       );
     }
 
+    // IDOR guard: only the wallet owner may stake under their address.
+    const __guard = requireWalletMatch(__auth, walletAddress);
+    if (!__guard.ok)
+      return NextResponse.json({ error: __guard.reason }, { status: __guard.status });
+
     if (typeof amount !== "number" || amount < 10) {
       return NextResponse.json(
         { error: "Minimum stake is 10 USDC" },
diff --git a/app/app/api/agents/unstake/route.ts b/app/app/api/agents/unstake/route.ts
index 2771cff..e7f3932 100644
--- a/app/app/api/agents/unstake/route.ts
+++ b/app/app/api/agents/unstake/route.ts
@@ -1,6 +1,7 @@
 import { NextRequest, NextResponse } from "next/server";
 import { prisma } from "@/lib/prisma";
 import { enforceIpLimit } from "@/lib/rateLimit";
+import { requireAuth, requireWalletMatch } from "@/lib/require-auth";
 
 /**
  * POST /api/agents/unstake
@@ -19,7 +20,11 @@ export async function POST(req: NextRequest) {
     const limited = await enforceIpLimit(req, "unstake");
     if (limited) return limited;
 
-    const body = await req.json();
+    const __raw = await req.text();
+    const __auth = await requireAuth(req, { rawBody: __raw });
+    if (!__auth.ok)
+      return NextResponse.json({ error: __auth.reason }, { status: __auth.status });
+    const body = __raw ? JSON.parse(__raw) : {};
     const { walletAddress } = body as { walletAddress?: string };
 
     if (!walletAddress || typeof walletAddress !== "string") {
@@ -29,6 +34,11 @@ export async function POST(req: NextRequest) {
       );
     }
 
+    // IDOR guard: unstake/slash/bonus only affects the owner's own stake.
+    const __guard = requireWalletMatch(__auth, walletAddress);
+    if (!__guard.ok)
+      return NextResponse.json({ error: __guard.reason }, { status: __guard.status });
+
     // Check active stake
     const stake = await prisma.agentStake.findUnique({
       where: { walletAddress },
diff --git a/app/app/api/delivery/upload/route.ts b/app/app/api/delivery/upload/route.ts
index ace785f..26cfd39 100644
--- a/app/app/api/delivery/upload/route.ts
+++ b/app/app/api/delivery/upload/route.ts
@@ -1,5 +1,6 @@
 import { NextRequest, NextResponse } from "next/server";
 import crypto from "crypto";
+import { enforceIpLimit } from "@/lib/rateLimit";
 
 /**
  * POST /api/delivery/upload
@@ -15,6 +16,10 @@ import crypto from "crypto";
  * Requires: BLOB_READ_WRITE_TOKEN env var.
  */
 export async function POST(req: NextRequest) {
+  // Throttle: each call writes to Vercel Blob (storage + cost). Cap abuse.
+  const limited = await enforceIpLimit(req, "delivery_upload");
+  if (limited) return limited;
+
   const token = process.env.BLOB_READ_WRITE_TOKEN;
   if (!token) {
     return NextResponse.json(
diff --git a/app/app/api/generate/image/route.ts b/app/app/api/generate/image/route.ts
index bf32a48..5282395 100644
--- a/app/app/api/generate/image/route.ts
+++ b/app/app/api/generate/image/route.ts
@@ -1,5 +1,6 @@
 import { NextRequest, NextResponse } from "next/server";
 import crypto from "crypto";
+import { enforceIpLimit } from "@/lib/rateLimit";
 
 /**
  * POST /api/generate/image
@@ -33,6 +34,11 @@ const SIZE_MAP: Record<string, { width: number; height: number }> = {
 };
 
 export async function POST(req: NextRequest) {
+  // Throttle: each call hits the paid fal.ai API + Vercel Blob. Without a
+  // limit an unauthenticated caller can run up the bill / exhaust quota.
+  const limited = await enforceIpLimit(req, "generate_image");
+  if (limited) return limited;
+
   if (!FAL_KEY) {
     return NextResponse.json(
       {
diff --git a/app/app/api/profile/[wallet]/avatar/route.ts b/app/app/api/profile/[wallet]/avatar/route.ts
index 7121e1c..990caf6 100644
--- a/app/app/api/profile/[wallet]/avatar/route.ts
+++ b/app/app/api/profile/[wallet]/avatar/route.ts
@@ -1,10 +1,24 @@
 import { NextRequest, NextResponse } from "next/server";
 import { prisma } from "@/lib/prisma";
+import { requireAuth, requireWalletMatch } from "@/lib/require-auth";
+import { enforceIpLimit } from "@/lib/rateLimit";
 
 const AGENT_ALPHA_WALLET = process.env.AGENT_ALPHA_WALLET || "";
 const AGENT_OMEGA_WALLET = process.env.AGENT_OMEGA_WALLET || "";
 const MAX_SIZE_BYTES = 500 * 1024; // 500KB
 
+// Raster image types only. SVG (data:image/svg+xml) is intentionally excluded:
+// SVG is an active document that can carry <script>/onload handlers, so storing
+// an attacker-supplied SVG as an avatar is a stored-XSS vector if it is ever
+// rendered outside an <img> sandbox.
+const ALLOWED_IMAGE_PREFIXES = [
+  "data:image/png;",
+  "data:image/jpeg;",
+  "data:image/jpg;",
+  "data:image/webp;",
+  "data:image/gif;",
+];
+
 export async function POST(
   request: NextRequest,
   { params }: { params: Promise<{ wallet: string }> }
@@ -12,6 +26,22 @@ export async function POST(
   try {
     const { wallet } = await params;
 
+    // Throttle: this writes a 500KB blob to the DB; cap abuse per IP.
+    const limited = await enforceIpLimit(request, "profile_avatar");
+    if (limited) return limited;
+
+    // Read the raw body once so the auth check can hash it, then parse.
+    const raw = await request.text();
+    const auth = await requireAuth(request, { rawBody: raw });
+    if (!auth.ok) {
+      return NextResponse.json({ error: auth.reason }, { status: auth.status });
+    }
+    // IDOR guard: the signer must control the wallet whose avatar is being set.
+    const guard = requireWalletMatch(auth, wallet);
+    if (!guard.ok) {
+      return NextResponse.json({ error: guard.reason }, { status: guard.status });
+    }
+
     // Block agent wallets from uploading avatars
     if (
       wallet === AGENT_ALPHA_WALLET ||
@@ -23,8 +53,13 @@ export async function POST(
       );
     }
 
-    const body = await request.json();
-    const { imageData } = body as { imageData?: string };
+    let body: { imageData?: string };
+    try {
+      body = JSON.parse(raw);
+    } catch {
+      return NextResponse.json({ error: "Invalid JSON body" }, { status: 400 });
+    }
+    const { imageData } = body;
 
     if (!imageData || typeof imageData !== "string") {
       return NextResponse.json(
@@ -33,10 +68,10 @@ export async function POST(
       );
     }
 
-    // Validate it's a real image data URL
-    if (!imageData.startsWith("data:image/")) {
+    // Validate it's a real RASTER image data URL (no SVG — stored-XSS vector).
+    if (!ALLOWED_IMAGE_PREFIXES.some((p) => imageData.startsWith(p))) {
       return NextResponse.json(
-        { error: "imageData must be a valid image data URL (data:image/...)" },
+        { error: "imageData must be a base64 data URL of type png, jpeg, webp, or gif" },
         { status: 400 }
       );
     }
diff --git a/app/app/api/profile/[wallet]/route.ts b/app/app/api/profile/[wallet]/route.ts
index e4ee4f3..2a63d04 100644
--- a/app/app/api/profile/[wallet]/route.ts
+++ b/app/app/api/profile/[wallet]/route.ts
@@ -1,5 +1,6 @@
 import { NextRequest, NextResponse } from "next/server";
 import { prisma } from "@/lib/prisma";
+import { requireAuth, requireWalletMatch } from "@/lib/require-auth";
 
 export async function GET(
   _request: NextRequest,
@@ -35,7 +36,15 @@ export async function PATCH(
 ) {
   try {
     const { wallet } = await params;
-    const body = await request.json();
+    const raw = await request.text();
+    const auth = await requireAuth(request, { rawBody: raw });
+    if (!auth.ok)
+      return NextResponse.json({ error: auth.reason }, { status: auth.status });
+    // IDOR guard: you may only edit the profile of the wallet you control.
+    const guard = requireWalletMatch(auth, wallet);
+    if (!guard.ok)
+      return NextResponse.json({ error: guard.reason }, { status: guard.status });
+    const body = raw ? JSON.parse(raw) : {};
     const { displayName, bio, role } = body as {
       displayName?: string;
       bio?: string;
diff --git a/app/app/api/profile/route.ts b/app/app/api/profile/route.ts
index 23ee359..720a314 100644
--- a/app/app/api/profile/route.ts
+++ b/app/app/api/profile/route.ts
@@ -1,9 +1,14 @@
 import { NextRequest, NextResponse } from "next/server";
 import { prisma } from "@/lib/prisma";
+import { requireAuth, requireWalletMatch } from "@/lib/require-auth";
 
 export async function POST(request: NextRequest) {
   try {
-    const body = await request.json();
+    const raw = await request.text();
+    const auth = await requireAuth(request, { rawBody: raw });
+    if (!auth.ok)
+      return NextResponse.json({ error: auth.reason }, { status: auth.status });
+    const body = raw ? JSON.parse(raw) : {};
     const { walletAddress, displayName, bio, role } = body;
 
     if (!walletAddress || !displayName) {
@@ -13,6 +18,11 @@ export async function POST(request: NextRequest) {
       );
     }
 
+    // IDOR guard: a profile may only be created for the wallet you control.
+    const guard = requireWalletMatch(auth, walletAddress);
+    if (!guard.ok)
+      return NextResponse.json({ error: guard.reason }, { status: guard.status });
+
     // Check if profile already exists
     const existing = await prisma.profile.findUnique({
       where: { walletAddress },
diff --git a/app/lib/rateLimit.ts b/app/lib/rateLimit.ts
index e5f9e98..cbc548f 100644
--- a/app/lib/rateLimit.ts
+++ b/app/lib/rateLimit.ts
@@ -181,13 +181,34 @@ export function rateLimited429(result: RateLimitResult): Response {
   );
 }
 
-/** Best-effort client IP from proxy headers. */
+/**
+ * Trusted client IP from proxy headers.
+ *
+ * SECURITY: a client can send an arbitrary `X-Forwarded-For` header, so the
+ * LEFTMOST XFF entry is attacker-controlled and must NOT be used for rate
+ * limiting (an attacker rotates it to a fresh fake IP per request and the
+ * per-IP limit never trips). On Vercel, `x-real-ip` and `x-vercel-forwarded-for`
+ * are set by the platform to the true client IP and overwrite anything the
+ * client sent, so we trust those first, then the RIGHTMOST XFF entry (appended
+ * by the closest trusted proxy) — never the spoofable leftmost value.
+ */
 export function ipFromRequest(req: Request): string {
-  return (
-    req.headers.get("x-forwarded-for")?.split(",")[0]?.trim() ||
-    req.headers.get("x-real-ip") ||
-    "unknown"
-  );
+  const realIp = req.headers.get("x-real-ip");
+  if (realIp) return realIp.trim();
+
+  const vercelFwd = req.headers.get("x-vercel-forwarded-for");
+  if (vercelFwd) {
+    const parts = vercelFwd.split(",").map((s) => s.trim()).filter(Boolean);
+    if (parts.length) return parts[parts.length - 1];
+  }
+
+  const xff = req.headers.get("x-forwarded-for");
+  if (xff) {
+    const parts = xff.split(",").map((s) => s.trim()).filter(Boolean);
+    if (parts.length) return parts[parts.length - 1];
+  }
+
+  return "unknown";
 }
 
 /**
diff --git a/app/lib/require-auth.ts b/app/lib/require-auth.ts
index f3fb7ce..415dba7 100644
--- a/app/lib/require-auth.ts
+++ b/app/lib/require-auth.ts
@@ -21,9 +21,68 @@
 import crypto from "node:crypto";
 import { verifyWalletSignature } from "./wallet-auth";
 
-/** Whether mutating-endpoint auth is enforced. Off by default (non-breaking). */
+/**
+ * Whether mutating-endpoint auth is enforced.
+ *
+ * SECURITY: this is a phased-rollout flag. While it is unset every mutating
+ * route is effectively unauthenticated. It MUST be flipped to "true" in
+ * production once the frontend + SDK sign requests (see docs/SECURITY_AUDIT.md,
+ * "auth enforcement"). When `NODE_ENV==="production"` and the flag is not
+ * explicitly "true", we emit a loud one-time warning so the gap can't ship
+ * silently.
+ */
+let warnedAuthOff = false;
 export function authEnforced(): boolean {
-  return process.env.AUTH_ENFORCED === "true";
+  const on = process.env.AUTH_ENFORCED === "true";
+  if (!on && process.env.NODE_ENV === "production" && !warnedAuthOff) {
+    warnedAuthOff = true;
+    console.error(
+      "[security] AUTH_ENFORCED is not 'true' in production: mutating endpoints " +
+        "accept unauthenticated requests. Enable wallet signing then set AUTH_ENFORCED=true.",
+    );
+  }
+  return on;
+}
+
+/**
+ * Bind an authenticated request to the wallet it claims to act on.
+ *
+ * `requireAuth` proves the caller controls the wallet in `x-wallet`, but it
+ * does NOT check that this equals the wallet the request mutates (the `wallet`
+ * field in the body / path). Without this binding a caller can sign as their
+ * own wallet and act on someone else's — a systemic IDOR. Every mutating route
+ * that takes a wallet from the body/path must call this with the prior
+ * `requireAuth` result and the wallet it is about to act on.
+ *
+ *   const auth = await requireAuth(req, { rawBody: raw });
+ *   if (!auth.ok) return Response.json({ error: auth.reason }, { status: auth.status });
+ *   const guard = requireWalletMatch(auth, body.wallet);
+ *   if (!guard.ok) return Response.json({ error: guard.reason }, { status: guard.status });
+ *
+ * Semantics:
+ *   - mode "disabled" (flag off): no-op pass, so the binding is correct the
+ *     instant AUTH_ENFORCED is flipped on without breaking the pre-signing UI.
+ *   - mode "api_key": trusted automation, allowed to act on any wallet.
+ *   - mode "signature": REQUIRE proven wallet === acting wallet.
+ */
+export function requireWalletMatch(
+  auth: AuthResult,
+  actingWallet: string | null | undefined,
+): { ok: true } | { ok: false; status: number; reason: string } {
+  if (!auth.ok) return { ok: false, status: auth.status, reason: auth.reason };
+  if (auth.mode === "disabled" || auth.mode === "api_key") return { ok: true };
+  // signature mode
+  if (!actingWallet) {
+    return { ok: false, status: 400, reason: "missing acting wallet" };
+  }
+  if (!auth.wallet || !timingSafeEqual(auth.wallet, actingWallet)) {
+    return {
+      ok: false,
+      status: 403,
+      reason: "signer does not control the target wallet",
+    };
+  }
+  return { ok: true };
 }
 
 /** SHA-256 hex of a (possibly empty) request body. */
diff --git a/docs/SECURITY_AUDIT.md b/docs/SECURITY_AUDIT.md
new file mode 100644
index 0000000..0786c72
--- /dev/null
+++ b/docs/SECURITY_AUDIT.md
@@ -0,0 +1,468 @@
+# Covenant Security Audit — Findings
+
+> Produced by an 8-lens multi-agent hunt (on-chain Anchor, authz, payments, injection/SSRF, crypto, DoS, business-logic, web-hardening). The adversarial verification pass was interrupted by transient server rate-limiting, so these are the raw finder outputs; each was triaged by hand before fixing. Counts below are pre-dedup.
+
+**Totals:** {'critical': 3, 'high': 19, 'medium': 19, 'low': 20, 'info': 3}
+
+
+## CRITICAL
+
+### requireAuth never binds the proven signer to the body wallet — systemic IDOR even when AUTH_ENFORCED=true
+- **File:** `app/lib/require-auth.ts:80-121 (consumed by jobs, stake, faucet, disputes, claims/buy, etc.)`
+- **Category:** IDOR / broken access control  ·  **Confidence:** high
+- **What:** requireAuth verifies that the caller controls SOME wallet (valid Ed25519 signature over the request, or a valid API key) and returns { wallet }. But NO route ever compares __auth.wallet to the wallet identity in the request body (posterWallet / takerWallet / walletAddress / buyerWallet / arbitratorWallet). `grep -rn 'auth.wallet' app/api` returns zero matches. The canonical message in canonicalAuthMessage() binds method+path+bodyHash+ts but NOT the acting identity, and the route logic trusts the body field for all authorization decisions (job.posterWallet === posterWallet, takerWallet ownership, faucet target, etc.). So any party holding a single valid keypair (or, worse, any shared API key in API_KEYS) can sign a request and put a DIFFERENT victim wallet in the body, acting as that victim.
+- **Exploit:** 1. Operator flips AUTH_ENFORCED=true believing the app is now safe. 2. Attacker controls wallet A (any keypair) and signs a valid request for POST /api/jobs/[id]/submit. 3. Attacker sets takerWallet=VICTIM in the body. requireAuth passes (signature valid for A), and the route only checks that a JobInterest exists for takerWallet=VICTIM — it never checks that A == VICTIM. Attacker submits/cancels/finalizes/disputes on behalf of arbitrary wallets, drains the faucet to wallets they don't own, mints reputation, etc. With a shared API key the attacker bypasses the signature entirely and impersonates everyone.
+- **Fix:** After requireAuth, when mode==='signature' enforce that __auth.wallet === the body's acting-wallet field for every route (e.g. require __auth.wallet === posterWallet in /jobs/[id]/dispute, === takerWallet in /jobs/[id]/submit, === walletAddress in /faucet & /agents/stake, === buyerWallet in /claims/[id]/buy). Bake the acting wallet into the canonical signed message (add it to canonicalAuthMessage) so it cannot be swapped. For api_key mode, scope the key to specific wallets rather than treating it as a global act-as-anyone credential.
+
+### AUTH_ENFORCED defaults OFF — every 'protected' mutating route is fully unauthenticated in production
+- **File:** `app/lib/require-auth.ts:25-27,84`
+- **Category:** Missing authentication  ·  **Confidence:** high
+- **What:** authEnforced() returns true only when process.env.AUTH_ENFORCED === 'true'. It is not set in .env or .env.example, so requireAuth returns { ok: true, mode: 'disabled' } unconditionally. Every route that relies solely on requireAuth for auth — /api/jobs (POST), /api/jobs/[id]/accept, /submit, /dispute, /finalize, /api/agents/stake, /api/faucet, /api/disputes (POST), /api/claims/[id]/buy — performs no identity check at all by default. The only gate left is IP rate limiting and the on-chain tx verification on routes that have it.
+- **Exploit:** With the shipped/default config, an unauthenticated attacker POSTs directly to e.g. /api/faucet { walletAddress: <any> } (mints 100 test USDC to any wallet, rate-limited only by IP), or /api/agents/stake { walletAddress: <victim>, amount } to inflate/alter a victim's stake record, or /api/jobs/[id]/submit with an arbitrary takerWallet on any agent/bot job that lacks a PDA (isHumanFlow false path skips on-chain check) to forge deliveries and reputation. No signature, key, or wallet proof is required.
+- **Fix:** Default-deny: make authEnforced() return true unless explicitly disabled (e.g. AUTH_DISABLED==='true' for local dev only), or hard-require it in production builds. Fail closed on mutating financial/identity endpoints regardless of the flag.
+
+### Body-supplied wallet identity is never bound to the authenticated signer (auth bypass across all routes)
+- **File:** `app/lib/require-auth.ts:80-121`
+- **Category:** fee-bypass / impersonation  ·  **Confidence:** high
+- **What:** requireAuth returns `{ok:true, wallet}` for the signature path but NONE of the audited routes compare that authenticated `wallet` to the wallet field in the request body. dispute/route.ts checks `job.posterWallet !== posterWallet` where `posterWallet` comes from the body; reviews/route.ts trusts body `posterWallet`/`takerWallet`; claims/[id]/buy trusts body `buyerWallet`; agents/stake trusts body `walletAddress`; faucet trusts body `walletAddress`. Because requireAuth is also a complete no-op unless `AUTH_ENFORCED=true` (line 84), and even when enforced any wallet with a valid signature over the request can pass an arbitrary other wallet in the body, the 'Only the poster can…' / 'Only the seller can…' guards are decorative — they only check that the body string equals a DB column the attacker can read.
+- **Exploit:** With AUTH_ENFORCED unset (default), an attacker calls any mutating endpoint with no auth headers at all and simply sets posterWallet/takerWallet/buyerWallet/walletAddress to the victim's address. e.g. POST /api/reviews with the real poster's wallet to leave reviews; POST /api/agents/stake crediting a victim; POST /api/faucet for any wallet. Even with AUTH_ENFORCED=true, attacker signs with their OWN wallet but puts the victim's wallet in the body — the route never cross-checks signer==body wallet.
+- **Fix:** In each mutating route, after requireAuth succeeds in signature mode, assert auth.wallet === body.<actorWallet> (posterWallet/takerWallet/buyerWallet/sellerWallet/walletAddress). Make AUTH_ENFORCED the default. For faucet/stake/reviews specifically, derive the acting wallet from auth.wallet rather than trusting the body.
+
+
+## HIGH
+
+### Wallet-signature auth has no per-signature replay protection (replayable within 5-minute window)
+- **File:** `app/lib/wallet-auth.ts:33-115 (and app/lib/require-auth.ts:80-121)`
+- **Category:** missing replay/nonce protection  ·  **Confidence:** high
+- **What:** verifyWalletSignature freshness relies solely on a +/-5 minute timestamp skew window (MAX_TIMESTAMP_SKEW_MS, wallet-auth.ts:9,71). There is no nonce, jti, or consumed-signature store. requireAuth() builds a canonical message binding method+path+bodyHash+ts (require-auth.ts:107-117) but never records that a given (signature, ts) was already used. The same signed header (x-wallet, x-signature, x-timestamp) verifies as valid every time it is presented for up to 5 minutes. Because the body hash and path are part of the message, an attacker who captures one authenticated mutating request can replay that EXACT request arbitrarily many times during the window (e.g. resubmit a job, trigger a dispute, fire any idempotency-sensitive state change repeatedly).
+- **Exploit:** 1. Attacker observes/MITMs (or reads logs/proxy with) one authenticated mutating request: headers x-wallet, x-signature, x-timestamp plus the raw body. 2. Within 5 minutes, attacker re-sends the identical HTTP request (same method, path, body, and the three headers) N times. 3. verifyWalletSignature returns ok:true each time because the timestamp is still within skew and the signature matches the message; no nonce/used-signature check exists. 4. Any side-effecting endpoint (dispute open, job submit, profile mutation) is executed N times by the victim's identity.
+- **Fix:** Add a durable, atomic consumed-signature store keyed on the signature (or a hash of wallet|ts|signature), checked-and-inserted via a unique-constraint INSERT (like x402-payments.claimPayment). Reject when the key already exists. Alternatively/additionally require a server-issued single-use nonce in the canonical message. The store entries can expire after the skew window. Wire this into requireAuth before returning ok:true.
+
+### SSRF: TOCTOU / DNS-rebinding gap between assertPublicUrl and the verification fetch in agent registration
+- **File:** `/Users/baturalpguvenc/covenant/app/app/api/agents/register/route.ts:40-90`
+- **Category:** SSRF  ·  **Confidence:** high
+- **What:** POST /api/agents/register validates endpointUrl with assertPublicUrl() (which resolves DNS and rejects private targets) at line 40, then performs a separate fetch(endpointUrl) at line 82. The fetch re-resolves the hostname independently, so the address that was validated is not the address that is connected to. A DNS name whose record flips between the validation lookup and the fetch (DNS rebinding, low-TTL record, or round-robin where only one A record is public) bypasses the guard and lets the server issue a POST to an internal host. The endpoint is reached as a POST with a JSON body, making it a usable SSRF gadget against internal services that accept POST. There is also no authentication on this route, so any anonymous caller can drive these outbound requests.
+- **Exploit:** 1. Attacker controls evil.example.com with a 0-second TTL. 2. Configure it to resolve to a public IP for the first lookup (passing assertPublicUrl) and to 169.254.169.254 / 10.x / 127.0.0.1 for the second lookup. 3. POST /api/agents/register with endpointUrl=http://evil.example.com and valid name/description/capabilities. 4. assertPublicUrl resolves the public IP and passes; fetch() at line 82 re-resolves to the internal IP and the server POSTs to the internal target, reaching cloud metadata or internal-only POST endpoints. The response status leaks via the 422/2xx branch.
+- **Fix:** Resolve the hostname once, assert every returned address is public, and pin the connection to that validated IP (e.g. resolve manually then fetch using the IP with a Host header, or use an HTTP agent with a lookup callback that enforces isBlockedIp on the address actually dialed). Re-validate inside a custom dns.lookup hook on the fetch/undici dispatcher so the address connected to is the address checked. Also require authenticated/wallet-signed registration and rate-limit the outbound test fetch.
+
+### Missing authorization: any user can overwrite any wallet's profile avatar (stored data: URL)
+- **File:** `/Users/baturalpguvenc/covenant/app/app/api/profile/[wallet]/avatar/route.ts:8-67`
+- **Category:** Broken access control / IDOR  ·  **Confidence:** high
+- **What:** POST /api/profile/[wallet]/avatar takes the target wallet from the URL path and writes imageData straight into Profile.avatarUrl (prisma.profile.update where walletAddress = wallet) with no proof the caller owns that wallet — no signature, session, or ownership check. The only gate is a hardcoded block on two agent wallets. The stored value is an attacker-supplied data:image/... string up to ~500KB that is later rendered as <img src> across the app (chat, battle, agents pages). An attacker can deface any user's avatar and persist large blobs in the DB for every wallet.
+- **Exploit:** 1. Pick any victim wallet address W. 2. POST /api/profile/W/avatar with JSON {"imageData":"data:image/png;base64,<attacker image>"}. 3. The server updates W's profile with no ownership check; the victim's avatar is replaced site-wide. Repeat across many wallets to bloat the DB (each row ~500KB) toward the storage quota.
+- **Fix:** Require the caller to prove ownership of `wallet` before writing — verify a wallet signature over a server-issued nonce (the app already does signature verification for payments) or a session bound to that wallet. Reject if the authenticated wallet != path wallet. Additionally cap stored avatar size hard and prefer storing to Blob over inlining base64 in the DB.
+
+### Unauthenticated profile avatar overwrite (IDOR) — any wallet's avatar can be set by anyone, with SVG/HTML payload accepted
+- **File:** `app/app/api/profile/[wallet]/avatar/route.ts:8-67`
+- **Category:** Broken Access Control / IDOR + Stored content injection  ·  **Confidence:** high
+- **What:** POST /api/profile/[wallet]/avatar takes the target wallet purely from the URL path and never verifies the caller controls that wallet. There is no requireAuth() / verifyWalletSignature() call (unlike jobs/disputes/claims routes which all import requireAuth). Any unauthenticated caller can overwrite the avatarUrl of ANY existing profile. The only validation is `imageData.startsWith("data:image/")`, which permits `data:image/svg+xml;base64,...`. The full data URL is stored verbatim in Profile.avatarUrl and later rendered (app/battle/page.tsx:2678,2708 etc. via <img src={agent.avatarUrl}>). SVG inside an <img> tag does not execute script in modern browsers, so this is not a direct DOM-XSS, but it is (a) an authorization break letting attackers deface arbitrary user/agent profiles and (b) stored attacker-controlled markup that becomes dangerous the moment any view switches to <object>/<iframe>/<embed> or a direct link to the data URL.
+- **Exploit:** 1. Attacker enumerates a victim wallet address (public on leaderboard/jobs). 2. `curl -X POST https://app/api/profile/<victimWallet>/avatar -H 'content-type: application/json' -d '{"imageData":"data:image/svg+xml;base64,<base64 of a defacement/phishing SVG up to ~500KB>"}'`. 3. prisma.profile.update succeeds with no auth; victim's avatar is now attacker-controlled across the whole app. Repeat in a loop to mass-deface every profile.
+- **Fix:** Gate the route behind requireAuth() and assert the authenticated wallet equals the path wallet: `const raw = await req.text(); const auth = await requireAuth(req,{rawBody:raw}); if(!auth.ok) return 401; if(auth.mode==='signature' && auth.wallet!==wallet) return 403;`. Additionally reject `data:image/svg+xml` (allowlist raster types png/jpeg/webp/gif only) so no attacker markup is ever stored. Note requireAuth is a no-op until AUTH_ENFORCED=true, so also add an explicit ownership/signature check that does not depend on that flag.
+
+### Unauthenticated, unthrottled file upload to Vercel Blob (delivery/upload) — storage/cost abuse
+- **File:** `app/app/api/delivery/upload/route.ts:17-141`
+- **Category:** Missing authentication / Resource abuse  ·  **Confidence:** high
+- **What:** POST /api/delivery/upload writes arbitrary caller-supplied bytes (up to 5MB) to the project's Vercel Blob store using the privileged BLOB_READ_WRITE_TOKEN, with no authentication, no rate limiting, and no content-type/extension allowlist. file.type and file.name are taken straight from the multipart part (lines 57-58) and used as the stored content-type and as part of the blob path. There is no requireAuth() call. Anyone on the internet can upload unlimited 5MB objects, burning storage and bandwidth billing, and can set an arbitrary Content-Type (e.g. text/html) on a stored object.
+- **Exploit:** Loop: `for i in $(seq 1 100000); do curl -F file=@5mb.bin https://app/api/delivery/upload; done` — fills the blob store and runs up Vercel storage/egress bills with zero credentials. Or upload `file` with name `x.html` and type `text/html` to host arbitrary HTML on the blob domain.
+- **Fix:** Wrap in requireAuth() (read raw body once) and add per-IP/per-wallet rate limiting. Enforce a content-type allowlist and sanitize/normalize filename + extension (do not trust file.type / file.name). Consider deriving content-type server-side from magic bytes rather than the client header.
+
+### Unauthenticated, unthrottled image generation (generate/image) — paid fal.ai API abuse
+- **File:** `app/app/api/generate/image/route.ts:35-152`
+- **Category:** Missing authentication / Resource abuse  ·  **Confidence:** high
+- **What:** POST /api/generate/image calls the paid fal.ai API (using FAL_KEY) and then writes to Vercel Blob (BLOB_READ_WRITE_TOKEN) on every request. There is no requireAuth(), no rate limit, and the only input gate is prompt length >= 5. An anonymous attacker can drive unlimited paid generations and blob writes, directly converting to money against the project's fal.ai and Vercel accounts.
+- **Exploit:** `while true; do curl -s -X POST https://app/api/generate/image -H 'content-type: application/json' -d '{"prompt":"any text here"}'; done` — each call spends fal.ai credits and stores a blob, with no credentials required. Trivially scriptable to exhaust the API budget.
+- **Fix:** Require authentication (requireAuth / wallet signature or API key) and add strict per-caller rate limiting and a daily quota. Optionally restrict to callers who hold an open job, since the endpoint is meant for design-category agents fulfilling a specific job.
+
+### POST /api/profile — create profile for any wallet, no proof of control
+- **File:** `app/app/api/profile/route.ts:4-51`
+- **Category:** Missing authentication / impersonation  ·  **Confidence:** high
+- **What:** POST takes walletAddress + displayName from the body and creates a Profile row with zero authentication, no requireAuth, no signature. Anyone can create/squat a profile for any wallet address.
+- **Exploit:** Attacker POSTs { walletAddress: VICTIM, displayName: 'phish', bio: '...' }. Since the row is created with no owner check and PATCH/avatar key off walletAddress, the attacker front-runs a real user to squat their identity, or seeds misleading display names/bios for high-profile wallets. The 409 'already exists' also leaks which wallets have profiles.
+- **Fix:** Require requireAuth and enforce __auth.wallet === walletAddress (signature-bound). Reject creation for any wallet the caller has not proven control of.
+
+### PATCH /api/profile/[wallet] — edit any user's profile, no auth
+- **File:** `app/app/api/profile/[wallet]/route.ts:32-80`
+- **Category:** IDOR / missing authentication  ·  **Confidence:** high
+- **What:** PATCH updates displayName/bio/role for the wallet in the URL path with no authentication and no ownership check. The wallet is taken straight from the route param and used as the Prisma where clause.
+- **Exploit:** curl -X PATCH /api/profile/<VICTIM_WALLET> -d '{"displayName":"hacked","bio":"..."}' overwrites any victim's public profile. No signature, key, or session required.
+- **Fix:** Add requireAuth and enforce __auth.wallet === params.wallet before update. Reject otherwise with 403.
+
+### POST /api/profile/[wallet]/avatar — set any user's avatar, no auth
+- **File:** `app/app/api/profile/[wallet]/avatar/route.ts:8-75`
+- **Category:** IDOR / missing authentication  ·  **Confidence:** high
+- **What:** Updates avatarUrl for the path wallet with only an agent-wallet denylist and a 500KB size/data-URL check — no authentication or ownership proof. Stores an attacker-controlled data:image/... URL directly into the victim's profile.
+- **Exploit:** Attacker POSTs a data:image URL to /api/profile/<VICTIM>/avatar and replaces the victim's avatar (defacement); large/abusive payloads up to ~500KB are stored per call. No proof of wallet control.
+- **Fix:** Require requireAuth with __auth.wallet === params.wallet. Keep the SSRF/data-URL validation but gate the whole route on ownership.
+
+### POST /api/agents/stake — write/increment stake for any wallet (auth is no-op + unbound)
+- **File:** `app/app/api/agents/stake/route.ts:12-62`
+- **Category:** IDOR / missing authentication  ·  **Confidence:** high
+- **What:** Calls requireAuth (no-op by default; unbound even when enforced) then upserts AgentStake keyed by the body walletAddress with amount increment. No check that the caller owns walletAddress. The stake record is later read by /agents/unstake to compute bonus/slash and gate unstaking.
+- **Exploit:** Default config: attacker POSTs { walletAddress: VICTIM, amount: 10 } to create or inflate a stake record for a wallet they don't own, corrupting the victim's stake accounting (e.g. set status active, increment amount) and downstream unstake math. Even with AUTH_ENFORCED, any valid signer can target any wallet (see systemic IDOR finding).
+- **Fix:** Enforce __auth.wallet === walletAddress and make AUTH_ENFORCED default-on. Treat stake as a financial mutation requiring proven ownership.
+
+### POST /api/agents/unstake — no auth at all; trigger unstake/slash/bonus for any wallet
+- **File:** `app/app/api/agents/unstake/route.ts:17-116`
+- **Category:** Missing authentication / IDOR  ·  **Confidence:** high
+- **What:** Unlike stake, this route does not even call requireAuth — only enforceIpLimit. It takes walletAddress from the body and mutates the AgentStake row (status -> returned/slashed, sets slashedAmount/bonusEarned) for that wallet. Anyone can force-unstake any agent.
+- **Exploit:** Attacker POSTs { walletAddress: VICTIM }. If the victim has an active stake and no active jobs, the route flips their stake to 'returned' (or 'slashed' if they lost a dispute), permanently changing their stake state and computed payout without their consent — a griefing/financial-integrity attack. Repeatable across all staked agents.
+- **Fix:** Add requireAuth and enforce __auth.wallet === walletAddress. Default AUTH_ENFORCED on.
+
+### POST /api/agents/register — register agents under any wallet, no auth + SSRF probe primitive
+- **File:** `app/app/api/agents/register/route.ts:17-150`
+- **Category:** Missing authentication / impersonation  ·  **Confidence:** high
+- **What:** No requireAuth and no rate limiter. walletAddress comes from the body and the agent is persisted with verified:true after a server-side test POST to endpointUrl. The 5-agents-per-wallet cap is keyed on the attacker-supplied walletAddress, providing no protection.
+- **Exploit:** Attacker registers up to 5 'verified' agents under any victim wallet (reputation/impersonation), or repeatedly across many wallets without limit. The server-side fetch to endpointUrl (assertPublicUrl mitigates SSRF to private IPs, but) can still be used as an unauthenticated outbound HTTP request primitive against arbitrary public hosts (10s timeout, attacker-controlled URL) — an open request relay / amplification surface.
+- **Fix:** Require requireAuth with __auth.wallet === walletAddress, add a durable rate limit (per-wallet and per-IP), and reconsider performing outbound fetches on behalf of unauthenticated callers.
+
+### PATCH/DELETE /api/hosted-agents/[id] — ownership check is spoofable (compares stored wallet to body wallet, no auth)
+- **File:** `app/app/api/hosted-agents/[id]/route.ts:17-75`
+- **Category:** IDOR / broken access control  ·  **Confidence:** high
+- **What:** PATCH and DELETE 'authorize' by reading the agent row and checking agent.walletAddress === body.walletAddress. Since the attacker supplies walletAddress in the body and the owner wallet is readable (GET /api/hosted-agents/[id] and GET /api/hosted-agents return walletAddress), the attacker simply sets walletAddress to the real owner's address. There is no signature/key proving control of that wallet.
+- **Exploit:** Attacker GETs /api/hosted-agents/<id>, reads walletAddress=OWNER, then PATCHes the same id with { walletAddress: OWNER, systemPrompt: '<malicious/exfiltrating prompt>', minPrice: 0, model: ... } — fully rewriting another user's hosted agent (including its system prompt and pricing), or DELETEs (soft-deactivates) it. The equality check passes because the attacker echoed the owner's address.
+- **Fix:** Replace the body-wallet comparison with requireAuth and compare agent.walletAddress to the cryptographically-proven __auth.wallet, never to a body field.
+
+### Expensive fal.ai image generation endpoint has no auth and no rate limit
+- **File:** `app/app/api/generate/image/route.ts:35`
+- **Category:** unauthenticated-expensive-call  ·  **Confidence:** high
+- **What:** POST /api/generate/image accepts an arbitrary prompt and, on every request, calls fal.ai's flux/schnell model (paid per generation), then downloads the result, hashes it, and uploads it to Vercel Blob (paid storage + egress). There is no authentication, no payment gate, and no rate limit anywhere in the handler. The only input check is `prompt.length >= 5`. This is a public Next.js route, so it is directly reachable by anyone.
+- **Exploit:** An attacker runs `for i in $(seq 1 100000); do curl -X POST https://host/api/generate/image -d '{"prompt":"anything here"}' & done`. Each call burns a paid fal.ai inference and a Vercel Blob PUT. Thousands of concurrent calls run up the FAL_KEY bill, exhaust the fal.ai quota (denying the legitimate design-agent flow that depends on it), and fill Blob storage — a direct financial-DoS / quota-exhaustion attack with no credential required.
+- **Fix:** Gate the route: require an authenticated session or an internal-only secret (it is only called server-side from hosted-agents chat via internal fetch, so it can be locked to an internal secret / same-origin check), AND add a durable per-IP and per-wallet rate limit via `enforceIpLimit(req, ...)` / `rateLimitDurable`. Add a hard cap on prompt length and reject when FAL quota guard trips.
+
+### A2A JSON-RPC endpoint creates Job rows with no auth and no rate limit
+- **File:** `app/app/api/a2a/route.ts:6`
+- **Category:** unauthenticated-write-dos  ·  **Confidence:** high
+- **What:** POST /api/a2a is a public JSON-RPC endpoint with no authentication and no rate limiting. The `task/create` method inserts a new Job row (`prisma.job.create`) for every request, with attacker-controlled `capability`, `input`, `minWords`, and `specJson`. Nothing limits how many jobs a caller can create or how large `input` is (it is round-tripped through `JSON.parse(JSON.stringify(input))` and stored as JSON).
+- **Exploit:** An attacker loops `curl -X POST https://host/api/a2a -d '{"jsonrpc":"2.0","id":"x","method":"task/create","params":{"input":{...huge blob...}}}'`. Each call writes a Job row with `posterWallet:"aip-external"`. Unbounded calls flood the Job table (storage exhaustion, pollutes the open-jobs feed that autonomous/arena bots scan, drives DB row-count toward the quota the cron/db-quota job watches), and large `input` payloads bloat each row. No spoofing or credential needed.
+- **Fix:** Add `enforceIpLimit(req, ...)` (durable per-IP limit) at the top of the handler, authenticate the caller (the a2a protocol supports DIDs/signatures — verify them), bound the size of `params.input` before persisting, and cap jobs-per-window per caller.
+
+### Per-IP rate limits on expensive AI routes are defeated by a spoofed X-Forwarded-For header
+- **File:** `app/lib/rateLimit.ts:185`
+- **Category:** rate-limit-bypass  ·  **Confidence:** medium
+- **What:** `ipFromRequest()` and the inline IP extraction in several routes take the client IP from `x-forwarded-for` (first element) / `x-real-ip` with no trust boundary. Every expensive AI route keys its rate limiter solely on this value: hosted-agents chat (route.ts:52-56 `chat:${ip}`), hosted-agents test (route.ts:25-26 `agent-test:${ip}`), autonomous/run (route.ts:46-48 `autonomous:${ip}`), arena/run (route.ts:75-78 `arena:${ip}`), battle/run (route.ts:72-74 `battle:${ip}`). On Vercel the platform overwrites XFF at the true edge, but if the app is ever fronted by another proxy, run on a different host, or the value is otherwise client-influenced, the header is attacker-controlled. Each of these routes makes one or more Anthropic API calls per request.
+- **Exploit:** Attacker sends each request with a fresh forged header: `curl -X POST https://host/api/hosted-agents/test -H 'x-forwarded-for: 1.2.3.4' ...` then `5.6.7.8`, etc. Because the limiter bucket is `agent-test:<spoofed-ip>`, every request lands in a brand-new bucket and the 10/min cap never triggers. The attacker drives unlimited Claude (Haiku/Sonnet/Opus) inferences across chat/test/arena/autonomous/battle, exhausting the Anthropic credit/quota and racking up cost — financial DoS. The same applies to faucet_ip and battle-chat keys.
+- **Fix:** Derive the client IP from a trusted source only: use the platform-provided connection IP (`req.ip` on Vercel / the right-most XFF hop after the known proxy count), not the left-most client-supplied entry. Combine IP with an authenticated principal (wallet + verified signature) in the rate-limit key so an anonymous attacker cannot mint unlimited buckets, and prefer requiring auth/payment on every route that calls the LLM.
+
+### Off-chain dispute on demo/no-PDA jobs is free and permanently blocks finalize (griefing)
+- **File:** `app/app/api/jobs/[id]/dispute/route.ts:124-168`
+- **Category:** dispute-griefing  ·  **Confidence:** high
+- **What:** The on-chain raise_dispute verification (verifyTxInvokedCovenant + JobEscrow status/bond/reasonHash checks) is gated entirely on `if (job.pda)` (line 136). Jobs created via the `demoMode` path in app/app/api/jobs/route.ts:389-420 and all SOL jobs (line 282-310) are persisted with NO `pda` and `escrowLocked:false`. For those jobs the txHash is still 'required' (line 124) but `verifyTxInvokedCovenant(txHash)` is called with an attacker-supplied string, and because there is no pda the on-chain JobEscrow assertions are skipped. Worse: the bond is only recorded in the DB (`bond: providedBond`), never actually escrowed on-chain for these jobs, so a dispute costs the challenger nothing. Once the dispute row is created the job is set to `Disputed`, and finalize (app/app/api/jobs/[id]/finalize/route.ts:69-74) hard-rejects any job with a dispute. There is no off-chain path to resolve a dispute on a no-pda job (resolve route also only mirrors on-chain state), so the payout is blocked forever.
+- **Exploit:** 1. Attacker is the poster of a demo-mode/SOL job (or any job lacking pda). 2. After the taker delivers, attacker POSTs /api/jobs/[id]/dispute with reasonText>=10 chars and any txHash string. 3. verifyTxInvokedCovenant runs against the bogus txHash; if it throws, the catch at line 159 only returns 400 — but if the attacker passes a real (unrelated) confirmed Covenant tx signature it passes, and since job.pda is null the bond/status checks never run. 4. Job becomes Disputed with a fake/zero bond. 5. Taker can never be paid; finalize permanently returns 409.
+- **Fix:** Reject disputes on jobs without an on-chain escrow (require job.pda and escrowLocked before allowing a dispute), OR require and verify the on-chain bond unconditionally. Do not record a Disputed status from an unverifiable off-chain claim. Additionally, verify the supplied txHash actually corresponds to *this* job's escrow even when pda is present, and bind the challenger to the authenticated wallet.
+
+### Reputation self-dealing: jobsCompleted/totalEarned inflate freely via agent jobs and self-posted jobs
+- **File:** `app/app/api/jobs/[id]/finalize/route.ts:229-243`
+- **Category:** reputation-gaming  ·  **Confidence:** high
+- **What:** On finalize the taker's Reputation is incremented (jobsCompleted +1, totalEarned += job.amount) with no check that poster != taker and no check that real funds moved. For agent jobs (isAgentJob, takerWallet starts with 'covenant-agent-') the settlement is a pure record-only marker (line 115-117) — no on-chain transfer — yet reputation/XP are still credited (though to the synthetic agent wallet). More damaging for human wallets: nothing prevents a poster from also being the taker (Sybil/self-dealing). Combined with the demo-mode job path (jobs/route.ts:389) which creates Open jobs with no escrow, an attacker can self-post a job, self-accept/deliver, wait out the challenge window, and finalize. Path C requires pda, but the client-cranked Path B / agent Path A and the totalEarned/jobsCompleted increment in the DB transaction (lines 231-243) run regardless, letting a single wallet farm arbitrarily high jobsCompleted and totalEarned. These metrics directly drive ClaimListing riskGrade (claims/route.ts:120-127), so inflated reputation lets the attacker list factoring claims that grade A+ and sell receivables at low discount.
+- **Exploit:** 1. Create many demo-mode jobs (no escrow, free) as poster wallet P. 2. Self-accept and self-deliver each (taker = P or a controlled wallet). 3. Finalize each after the short challenge window. 4. Reputation.jobsCompleted and totalEarned climb with zero real value moved. 5. List a claim on one of these jobs; claims/route.ts grades the seller A+/A based on the fabricated jobsCompleted>=20, attracting lenders who buy the receivable for near face value.
+- **Fix:** Reject finalize/reputation credit when job.posterWallet === job.takerWallet. Only increment totalEarned by the amount actually settled on-chain (routedToBuyer/taker), and only for jobs with a verified escrow (pda + escrowLocked). Exclude demo/record-only jobs from reputation entirely, or tag them so they cannot back a ClaimListing.
+
+### x402 facilitator path trusts isValid and re-uses the quoted amount; mint/recipient never re-checked server-side
+- **File:** `app/lib/x402-server.ts:512-542`
+- **Category:** x402-verification-bypass  ·  **Confidence:** medium
+- **What:** When a facilitator verifier is configured (env X402_FACILITATOR_URL set, or deps.verifyViaFacilitator injected), verifyPayment short-circuits ALL local on-chain checks. It returns valid:true purely on `fres.isValid === true`. The local amount/mint/recipient inspection (verifyTransfer, which enforces amount>=required AND mint==asset AND recipient==payTo) is skipped entirely on this branch. Worse, the request body POSTed to the facilitator (lines 430-443) includes only `transaction`, `scheme`, `network` in paymentPayload and `paymentRequirements: accepts[0]` — it forwards the requirement but does not itself constrain the asset/payTo, and when the facilitator does not echo amountAtomic the code substitutes the *quoted* amount (`accept.amount`, line 540) as the 'amount actually paid'. So the entire amount>=required / mint / recipient / confirmed guarantee is delegated to an external service with no server-side defense in depth.
+- **Exploit:** 1. Operator (or an attacker who can set the env var in a misconfigured/preview deployment, or any test harness using the injected dep) points X402_FACILITATOR_URL at a permissive or attacker-controlled facilitator. 2. Attacker submits any real Solana tx signature (passes isPlausibleTxSignature) with a Payment-Signature header. 3. Facilitator returns {isValid:true}. 4. verifyPayment returns valid:true with amountAtomic defaulted to the full quoted price, the chat route serves the paid response and books full revenue, despite no USDC of the correct mint having reached the agent wallet. The signature is then the only thing consumed once.
+- **Fix:** Even on the facilitator path, re-run verifyTransfer against the fetched transaction (or require the facilitator to return the settled mint, recipient and atomic amount and assert amountAtomic>=accept.amount, mint==accept.asset, recipient==accept.payTo before accepting). Never fall back to accept.amount as the 'paid' amount — treat a missing amountAtomic as a verification failure. Include the asset and payTo in the facilitator request and reject if the facilitator response does not confirm them.
+
+
+## MEDIUM
+
+### Webhook signature verification defaults to NO replay protection unless caller passes a replayCache
+- **File:** `app/lib/webhooks.ts:114-176`
+- **Category:** missing replay protection / unsafe default  ·  **Confidence:** medium
+- **What:** verifyWebhookSignature only enforces replay protection if the caller supplies args.replayCache; requireDeliveryId defaults to !!args.replayCache (line 149). With no replayCache (the default, and no caller in the repo wires one), a valid webhook is accepted any number of times within the 5-minute tolerance (line 148). The signed delivery id (d=) is parsed but ignored for dedup when no cache is present. The code comment itself (lines 121-133) admits an in-memory Set is TOCTOU-unsafe under concurrency and useless across serverless instances, yet no atomic cache implementation is provided or required.
+- **Exploit:** 1. Attacker captures one valid webhook POST (body + X-Covenant-Signature header) destined for a receiver that calls verifyWebhookSignature without a replayCache. 2. Attacker re-POSTs the identical body+signature to the receiver repeatedly within 5 minutes. 3. Each call returns true, so a receiver that, e.g., credits a balance or marks a claim settled on job.finalized/claim.settled events processes the same event multiple times (double-credit / double-fulfillment).
+- **Fix:** Make replay protection mandatory: require a deliveryId (d=) and an atomic replayCache (unique-constraint INSERT in the DB) by default, and reject if absent. Provide a DB-backed WebhookReplayCache implementation and document that bare in-memory Sets are not acceptable. Do not return true unless the delivery id was newly inserted.
+
+### Unauthenticated, unrate-limited image generation drives unbounded cost on fal.ai and Vercel Blob
+- **File:** `/Users/baturalpguvenc/covenant/app/app/api/generate/image/route.ts:35-135`
+- **Category:** Resource abuse / DoS  ·  **Confidence:** high
+- **What:** POST /api/generate/image has no authentication, no rate limiting, and no payment gate. Each request spends the FAL_KEY budget (a paid third-party API) and writes a PNG to Vercel Blob storage. The only input check is prompt length >= 5. An attacker can loop this endpoint to exhaust the fal.ai credit balance and fill Blob storage, and the user-supplied prompt is forwarded verbatim to the external model (prompt-to-external-API). The hosted-agents chat route calls this internally, but the route itself is publicly reachable and self-serve.
+- **Exploit:** 1. Script a loop: POST /api/generate/image with {"prompt":"x x x x x"} thousands of times. 2. Each call bills fal.ai and uploads a blob. 3. FAL_KEY budget is drained and Blob storage/quota is consumed, causing financial loss and potential outage of legitimate design-agent flows.
+- **Fix:** Gate the endpoint behind the same x402 payment/auth used by hosted-agent chat, or restrict it to internal calls only (verify an internal token / same-origin server call). Add per-wallet and per-IP rate limiting (the codebase already has rateLimitDurable). Keep enable_safety_checker and additionally bound prompt length.
+
+### delivery/upload accepts arbitrary file type with no auth, turning the app into an open file host
+- **File:** `/Users/baturalpguvenc/covenant/app/app/api/delivery/upload/route.ts:17-141`
+- **Category:** Unrestricted file upload  ·  **Confidence:** high
+- **What:** POST /api/delivery/upload has no authentication and stores whatever is uploaded to Vercel Blob, trusting the client-supplied content-type (file.type, line 58) and filename (line 57) with no allowlist of types or extensions and no magic-byte validation. Only a 5MB size cap is enforced. Because contentType is echoed into the Blob PUT headers (line 98), an attacker can upload HTML/SVG/JS with content-type text/html and get a public, app-domain-adjacent Blob URL that serves active content — usable for phishing or, if served from a sensitive origin, stored XSS. It is also a free, anonymous file-hosting/dumping primitive.
+- **Exploit:** 1. POST multipart/form-data to /api/delivery/upload with a file named payload.html whose type is text/html containing <script>...</script>. 2. The server stores it and returns a public deliveryUri serving it as text/html. 3. Distribute the URL for phishing/malware hosting under the project's storage domain. Repeat to abuse storage quota anonymously.
+- **Fix:** Require authentication (wallet signature / session) and tie uploads to a job the caller owns. Enforce an allowlist of content types and validate by sniffing magic bytes rather than trusting file.type. Force a safe stored content-type (e.g. application/octet-stream or text/plain) and Content-Disposition: attachment so blobs are never served as active HTML. Sanitize filename.
+
+### Unauthenticated hosted-agent avatar upload with no real size guard ordering and SVG acceptance
+- **File:** `app/app/api/hosted-agents/avatar/route.ts:5-18`
+- **Category:** Missing authentication / Stored content injection  ·  **Confidence:** high
+- **What:** POST /api/hosted-agents/avatar accepts a multipart 'avatar' file with no authentication and no rate limiting. The type check `file.type.startsWith("image/")` is satisfied by `image/svg+xml`, and file.type is fully attacker-controlled (it is echoed back into the returned `data:${file.type};base64,...` URL). The result is a base64 data URL the client stores/renders. Combined with the unauthenticated profile/hosted-agent surfaces, this lets anyone mint arbitrary image/SVG data URLs; SVG markup is attacker-controlled and only safe as long as it is rendered exclusively via <img>.
+- **Exploit:** `curl -F 'avatar=@payload.svg;type=image/svg+xml' https://app/api/hosted-agents/avatar` returns `{"url":"data:image/svg+xml;base64,..."}` with attacker SVG markup, no auth required. The MIME label is whatever the attacker sends. Also unthrottled, so usable for memory/CPU pressure with 2MB bodies.
+- **Fix:** Add requireAuth() + rate limiting. Restrict accepted types to a raster allowlist (png/jpeg/webp/gif) and reject svg+xml. Do not trust file.type — verify magic bytes and emit a normalized MIME.
+
+### POST /api/referral/claim — create referral edges for arbitrary wallets, no auth
+- **File:** `app/app/api/referral/claim/route.ts:12-66`
+- **Category:** Missing authentication / abuse  ·  **Confidence:** high
+- **What:** Takes referredWallet + referrerWallet from the body, only checks self-referral and a one-time 'already referred' constraint. No authentication and no proof that the caller controls either wallet. XP is awarded later on first job completion based on this referral edge.
+- **Exploit:** Attacker binds any victim wallet as 'referred' by an attacker-controlled referrerWallet (referredWallet=VICTIM, referrerWallet=ATTACKER). This permanently consumes the victim's one-time referral slot (denying them a legitimate referrer) and sets the attacker up to harvest referral XP/rewards when the victim completes a job. Mass-creatable across wallets.
+- **Fix:** Require the referred party to prove control of referredWallet via requireAuth (__auth.wallet === referredWallet). Add per-IP rate limiting.
+
+### POST /api/reviews — taker reputation/avgRating writable by impersonating the poster
+- **File:** `app/app/api/reviews/route.ts:9-104`
+- **Category:** IDOR / missing authentication  ·  **Confidence:** high
+- **What:** Enforces job.posterWallet === posterWallet (so only the 'poster' can review) but performs NO authentication that the caller actually controls posterWallet. posterWallet is purely body-supplied. The review then recomputes and writes the taker's Reputation.avgRating/reviewCount.
+- **Exploit:** Anyone who knows a finalized jobId and its posterWallet (both exposed via GET /api/jobs and GET /api/disputes includes) submits a review on the poster's behalf — e.g. a 1-star review to tank a competing taker's avgRating, or a 5-star to inflate an ally — without controlling the poster wallet. One-review-per-job is the only limiter.
+- **Fix:** Require requireAuth and enforce __auth.wallet === posterWallet === job.posterWallet before writing the review and reputation aggregate.
+
+### POST /api/disputes and /api/jobs/[id]/dispute — 'only poster' check is unauthenticated; default config has no on-chain guard on the generic route
+- **File:** `app/app/api/disputes/route.ts:57-187 and app/app/api/jobs/[id]/dispute/route.ts:26-202`
+- **Category:** IDOR / missing authentication  ·  **Confidence:** medium
+- **What:** Both require job.posterWallet === posterWallet but posterWallet is body-supplied and requireAuth is a no-op by default and never bound to it. /api/jobs/[id]/dispute additionally requires a real on-chain raise_dispute txHash and verifies the PDA, which blocks fund-moving abuse for on-chain jobs; but /api/disputes (the generic fallback) accepts txHash as optional and writes the Dispute row + flips job.status to 'Disputed' without mandatory on-chain verification.
+- **Exploit:** For a Delivered job whose poster wallet is known (exposed in job listings), an attacker calls POST /api/disputes with that posterWallet and a fabricated reason, flipping the job to 'Disputed' and blocking finalize (/finalize returns 409 while a dispute exists). This is a denial-of-settlement / griefing vector against the legitimate taker, requiring no poster credentials. For jobs without a pda the on-chain branch in /jobs/[id]/dispute is also skipped.
+- **Fix:** Bind requireAuth: __auth.wallet === posterWallet === job.posterWallet. Make on-chain txHash verification mandatory (not optional) on /api/disputes for any job that has a pda, matching the per-job route.
+
+### POST /api/jobs/[id]/accept & /submit — taker identity body-supplied; bot/agent jobs skip on-chain proof entirely
+- **File:** `app/app/api/jobs/[id]/accept/route.ts:42-150 and app/app/api/jobs/[id]/submit/route.ts:42-264`
+- **Category:** IDOR / impersonation  ·  **Confidence:** medium
+- **What:** takerWallet is taken from the body; requireAuth is unbound/no-op. On accept, the on-chain check only runs if acceptTxHash is supplied (optional). On submit, on-chain verification is required only when isHumanFlow (poster wallet not starting with 'covenant-agent-') OR commitmentTxHash present; for agent/bot-posted jobs the route writes Delivery + flips job to Delivered + withdraws competitors + writes a Submission and reputation with NO signature and NO on-chain proof.
+- **Exploit:** Attacker accepts a job as an arbitrary takerWallet (no tx), then for any agent-posted job submits work as an arbitrary takerWallet without commitmentTxHash — forging a delivery, knocking out competing interests (set to 'withdrawn'), and becoming the official taker. On human jobs lacking a pda the submit on-chain block is also bypassable. This corrupts the competitive multi-taker race and lets an attacker steal the 'winner' slot.
+- **Fix:** Bind __auth.wallet === takerWallet. Require a verified on-chain commitment for every settle-eligible job (do not special-case agent jobs into a no-proof path on a route that mutates winner assignment and reputation).
+
+### POST /api/hosted-agents — create hosted agents under any wallet, no auth
+- **File:** `app/app/api/hosted-agents/route.ts:43-140`
+- **Category:** Missing authentication / impersonation  ·  **Confidence:** high
+- **What:** Creates a HostedAgent with walletAddress from the body and awards 50 XP to that wallet, with no requireAuth and no rate limit. (avatarUrl is SSRF-checked, the only guard.)
+- **Exploit:** Attacker mass-creates hosted agents attributed to victim wallets (or floods the marketplace), each awarding 50 XP to an attacker-chosen walletAddress — an unauthenticated XP/reputation inflation and spam primitive.
+- **Fix:** Require requireAuth with __auth.wallet === walletAddress and add per-wallet/per-IP rate limiting.
+
+### POST /api/disputes/[id]/resolve — arbitrator identity is body-supplied, not signature-verified
+- **File:** `app/app/api/disputes/[id]/resolve/route.ts:33-152`
+- **Category:** Broken access control / authorization  ·  **Confidence:** high
+- **What:** The route checks ARBITRATORS.includes(arbitratorWallet) where arbitratorWallet is taken from the body — there is no proof the caller controls that whitelisted arbitrator wallet. requireAuth is not used here at all. The fund-moving threshold path (line 168+) does require a real on-chain resolve_dispute txHash, which prevents direct theft; but the pre-threshold votes mutate dispute.resolution/approvedBy/approvalCount with only a spoofed arbitrator name.
+- **Exploit:** Knowing the public arbitrator addresses (COVENANT_ARBITRATORS), an attacker submits a vote as arbitratorWallet=<known arbitrator> for a chosen resolution (e.g. FavorPoster). This records a fraudulent approval and LOCKS the pending resolution: once currentResolution !== 'Pending', any genuine arbitrator wanting a different outcome is rejected with 409 ('cannot approve X without a new dispute'). One spoofed vote can therefore censor/steer the real arbitration outcome and grief the resolution flow.
+- **Fix:** Verify the caller controls arbitratorWallet via a signature (requireAuth bound to arbitratorWallet, or a per-arbitrator API key), before recording any vote — not just at the on-chain settlement step.
+
+### Helius webhook iterates an unbounded payload array, issuing 2-3 DB round-trips per element
+- **File:** `app/app/api/helius/webhook/route.ts:154`
+- **Category:** unbounded-loop-dos  ·  **Confidence:** medium
+- **What:** After auth, POST /api/helius/webhook parses the JSON body into `payload` (an array; a single object is wrapped to length 1) and loops over every element with no cap on `payload.length`. For each element it runs a `jobEvent.findUnique` (idempotency), then up to two `job.findFirst` lookups, then a `jobEvent.create` and possibly a `job.update` — i.e. 2-5 sequential awaited Prisma queries per array entry, all in series. There is no limit on the number of transactions per request and no overall request body-size limit (no `bodyParser.sizeLimit` configured anywhere; confirmed absent from next.config).
+- **Exploit:** An attacker who learns/obtains HELIUS_WEBHOOK_SECRET (or any party able to replay a captured webhook auth header) POSTs a single request with a JSON array of, say, 200k tx objects. The handler walks all of them sequentially, doing hundreds of thousands of DB queries in one request, holding a serverless function open until it times out while saturating the Postgres connection/pool and starving every other request. Even without the secret, the unbounded `await req.json()` lets a large body consume memory before auth checks complete on the JSON parse path.
+- **Fix:** Cap `payload.length` (e.g. reject > 1000 entries with 413), enforce a request body-size limit, batch the idempotency check (`findMany({ where:{ txSignature:{ in: sigs } } })`) and the job lookups instead of per-element awaits, and process in bounded chunks. Helius batches are small in practice, so a few-hundred cap is safe.
+
+### Unbounded findMany on home-stats and per-wallet dashboard (no take)
+- **File:** `app/app/api/stats/dashboard/route.ts:69`
+- **Category:** unbounded-query  ·  **Confidence:** high
+- **What:** Several public GET endpoints run `prisma.job.findMany` with a where clause but no `take`/limit, so the result set grows with table size. stats/dashboard/route.ts:21 (recentJobs, 7-day window but unbounded count) and :69 (allUserJobs — ALL jobs ever for a wallet, no time bound, no take) load every matching row into memory just to compute category counts. stats/route.ts:26 (lockedJobs — every Open/Accepted job) does the same to sum amounts. As the Job table grows, a single request transfers and materializes the entire matching set.
+- **Exploit:** An attacker first inflates the Job table cheaply (e.g. via the unauthenticated /api/a2a task/create, or arena/autonomous self-posting), concentrating many jobs on one wallet or in Open/Accepted status. Then they repeatedly hit `GET /api/stats/dashboard?wallet=<that wallet>` and `GET /api/stats`. Each call pulls the full unbounded row set into the Node process, spiking memory and DB egress; concurrent calls amplify it into an OOM / DB-transfer DoS. stats/dashboard has no caching, so every request re-runs the scan.
+- **Fix:** Replace the in-memory aggregation with DB-side `groupBy`/`aggregate` (count per category, sum of amount) so only aggregates cross the wire, or add a bounded `take` plus a time window. Add the same `memoize()` wrapper stats/route.ts uses to stats/dashboard.
+
+### Reputation upsert in reviews wipes job/earning history; review route has no auth, rate limit, or finalize-time binding
+- **File:** `app/app/api/reviews/route.ts:9-104`
+- **Category:** review-manipulation  ·  **Confidence:** medium
+- **What:** POST /api/reviews has no requireAuth and no IP rate limit (unlike most other mutating routes). It trusts body posterWallet/takerWallet. The only guard is that body.posterWallet must equal job.posterWallet, but with no auth the caller can read the poster wallet from the public jobs API and submit on their behalf. Because there is exactly one review per job (unique on jobId) it cannot be spammed per-job, but an attacker controlling job creation (self-posted demo jobs) can manufacture unlimited finalized jobs and leave unlimited 5-star reviews for a target taker to inflate avgRating, or 1-star reviews to defame a competitor taker. Separately, the reputation upsert at lines 80-91 uses `create` with only avgRating/reviewCount — fine for create — but on `update` it sets avgRating/reviewCount; that part is OK. The real issue is the avg is computed over ALL reviews for the takerWallet with no weighting and no proof the reviewer transacted, enabling rating farming.
+- **Exploit:** Attacker self-posts demo jobs (free), self-finalizes them (reputation farm above), then POSTs /api/reviews with rating:5 for their own taker wallet on each, driving avgRating to 5.0 and reviewCount high — boosting their claim-marketplace credibility. Or targets a competitor: spin up jobs naming the competitor as taker is not possible directly, but any job they legitimately took can be 1-starred since the route only checks the body poster matches the job poster (readable publicly) with no signer binding.
+- **Fix:** Add requireAuth + bind auth.wallet === posterWallet, add IP/wallet rate limiting, and only allow reviews on jobs with a verified on-chain settlement (escrowLocked) so fabricated demo jobs cannot seed ratings. Consider weighting avgRating by settled value.
+
+### Faucet drainable across unlimited wallets from one origin (per-IP cap on a free 100-USDC mint)
+- **File:** `app/app/api/faucet/route.ts:39-60`
+- **Category:** faucet-draining  ·  **Confidence:** medium
+- **What:** The faucet mints 100 test USDC per call, rate-limited 1/hour/wallet and 10/hour/IP. There is no global/day cap and no proof-of-work or captcha. Wallets are unlimited and free to generate, so the only real limiter is the per-IP 10/hour. An attacker rotating IPs (proxies, IPv6 /64 rotation, serverless egress) mints unbounded test USDC. While this is devnet 'test' USDC, the same USDC mint backs escrow amounts and totalEarned analytics; a flood of faucet mints lets an attacker fund large self-dealing jobs and inflate TVL/reputation metrics cheaply. ipFromRequest relies on x-forwarded-for which is client-spoofable if not behind a trusted proxy.
+- **Exploit:** Script: for i in N: generate fresh keypair; POST /api/faucet {walletAddress}. Per-IP cap of 10/hr is bypassed by rotating X-Forwarded-For or source IP. Each mint = 100 USDC to a fresh wallet. Use the proceeds to fund escrow on self-posted jobs and farm reputation/claims.
+- **Fix:** Add a global daily mint ceiling and a per-IP cap that uses a trusted proxy header only (validate X-Forwarded-For against known proxy, or use the platform-provided client IP). Consider requiring a small PoW or a minimum wallet age/activity. Cap total faucet mints per wallet lifetime, not just per hour.
+
+### Referral farming: no auth, no wallet validation, self-referral check trivially bypassed via address variants
+- **File:** `app/app/api/referral/claim/route.ts:12-58`
+- **Category:** referral-farming  ·  **Confidence:** medium
+- **What:** POST /api/referral/claim has no requireAuth, no rate limit, and no validation that referredWallet is a real/distinct human. The self-referral guard is a raw string equality `referredWallet === referrerWallet` (line 28). Solana base58 addresses are case-sensitive so simple casing won't bypass, but the attacker simply uses two different wallets they both control (Sybil). The unique constraint on referredWallet only stops referring the same wallet twice. XP is later awarded on first job completion in agents/fulfill (30 to referrer, 15 to referred, lines 179-180), and that fulfill path can be triggered by the attacker's own self-posted demo jobs. So an attacker farms referral XP at will: generate wallet B, claim referral (A refers B), then have B post+fulfill a demo job to trigger the 30/15 XP payout to A and B.
+- **Exploit:** 1. Attacker controls wallets A and B. 2. POST /api/referral/claim {referredWallet:B, referrerWallet:A}. 3. As B, POST a demo-mode job and call /api/agents/fulfill; fulfill finds the referral and awards 30 XP to A + 15 XP to B. 4. Repeat with fresh B wallets to farm unlimited referral XP and climb leaderboards.
+- **Fix:** Require auth and bind referredWallet to the authenticated signer. Rate-limit per IP. Only award referral XP when the referred wallet completes a real, on-chain-settled job (escrowLocked, poster != taker). Add velocity/Sybil heuristics (e.g. cap referrals per referrer per day).
+
+### agents/stake records arbitrary unbacked stake amounts; no on-chain transfer verification
+- **File:** `app/app/api/agents/stake/route.ts:12-54`
+- **Category:** reputation-gaming / integer-abuse  ·  **Confidence:** medium
+- **What:** POST /api/agents/stake upserts an AgentStake row crediting `amount` (with `increment`) purely from the request body. There is no on-chain USDC transfer verification — the comment claims it records a 'USDC stake' but nothing proves funds were locked. The only checks are amount is a number >= 10 and walletAddress is a string. With auth unbound (see auth finding), an attacker stakes any amount for any wallet. Stake is commonly used as a Sybil/anti-spam signal or to grant agent privileges; a fabricated large stake can unlock gated behavior or boost trust scoring at zero cost. Also, because amount is a Float with only a lower bound and uses `increment`, repeated calls inflate stake unboundedly, and a non-integer/huge float (e.g. 1e308) can be supplied.
+- **Exploit:** POST /api/agents/stake {walletAddress:<any>, amount:1000000} repeatedly. Each call increments the recorded stake with no funds moved. The wallet now appears heavily staked to any feature that reads AgentStake.
+- **Fix:** Require an on-chain stake/transfer tx signature and verify it (like claims do via verifyTxInvokedCovenant + account read) before recording. Bind walletAddress to the authenticated signer. Add an upper sanity bound and store atomic integer units, not Float.
+
+### finalize Path B marks job Finalized + books reputation/revenue/fees from an unrelated program tx when job.pda is null
+- **File:** `app/app/api/jobs/[id]/finalize/route.ts:118-141`
+- **Category:** finalize-crank-abuse  ·  **Confidence:** medium
+- **What:** On the client-cranked path, the only on-chain checks are verifyTxInvokedCovenant(callerTxSig) (tx landed + touched the Covenant program + didn't revert) and a JobEscrow status==Finalized check that is gated behind `if (job.pda)`. For any job whose DB row has a null pda (demo / legacy / record-only jobs created via the demoMode bypass in /api/jobs), the status check is skipped completely. The callerTxSig is never bound to THIS job's escrow PDA, beneficiary, or amount — any confirmed transaction that invoked the program at all satisfies the check. The route then flips status to Finalized, upserts taker Reputation (jobsCompleted/totalEarned += job.amount), writes a ProtocolFee row, awards XP, and records a finalize Transaction, all off-chain, with no real settlement having occurred for this job.
+- **Exploit:** 1. Create a record-only job (demoMode path) so job.pda is null but job.amount is large and status Delivered, takerWallet = attacker. 2. Wait out the challenge window. 3. POST /api/jobs/{id}/finalize with txSignature = any real signature of any tiny Covenant-program instruction the attacker made (e.g. a 1-lamport list_claim on an unrelated job). verifyTxInvokedCovenant passes; the pda-gated Finalized check is skipped. 4. Job is marked Finalized and attacker's Reputation.totalEarned / jobsCompleted inflate and a finalize Transaction is recorded — reputation farming and fabricated settlement records with no escrow release.
+- **Fix:** Require job.pda to be present for Path B and make the JobEscrow status==Finalized check unconditional. Additionally bind the verification to the job: re-derive the JobEscrow PDA from poster+specHash and assert the callerTxSig's account keys include that PDA (or that fetchJobEscrow(job.pda) transitioned to Finalized as a result of this tx by checking deliveredAt/finalize markers), so an arbitrary program tx for a different job cannot satisfy finalize for this one.
+
+### Escrow token account is never re-derived from its canonical PDA seed; cancel_job can be tricked into closing the job while orphaning real escrow funds
+- **File:** `/Users/baturalpguvenc/covenant/programs/covenant/src/instructions/cancel_job.rs:35-40 (also finalize_payment.rs:45-50, resolve_dispute.rs:44-49)`
+- **Category:** missing PDA/account constraint  ·  **Confidence:** high
+- **What:** The escrow token account is created in create_job with seeds=[b"escrow_token", job_escrow.key()] (create_job.rs:44). Every downstream instruction (cancel_job, finalize_payment, resolve_dispute) re-accepts it as a plain TokenAccount validated ONLY by `escrow_token_account.owner == job_escrow.key()` and `mint == job_escrow.token_mint`. The canonical PDA seed is never re-derived or enforced. The token-account `owner` (authority) field is attacker-settable: anyone can create a brand-new SPL token account and set its authority to the job_escrow PDA. cancel_job is the dangerous case because it moves the *runtime balance* of whatever account is passed (`escrow_balance = escrow_token_account.amount`, cancel_job.rs:97) and then closes that account, while closing the JobEscrow PDA via `close = poster`.
+- **Exploit:** 1. Poster (or any signer on an Open job they own, or poster/taker on an Accepted-past-deadline job) creates a fresh empty SPL token account ATK with mint = job's mint and authority = job_escrow PDA (authority is just a data field, no signature needed). 2. They call cancel_job passing ATK as escrow_token_account instead of the real escrow PDA token account. All constraints pass (owner==job_escrow, mint matches). 3. escrow_balance is 0, the transfer is skipped, ATK is closed, the JobEscrow PDA is closed to poster, status set Cancelled. 4. The real escrow token account (still holding `amount`) is now orphaned: its authority was the job_escrow PDA, whose state account no longer exists, so no instruction can ever sign for it again. Funds are permanently locked. For a poster cancelling their own Open job this is self-harm, but for the Accepted-past-deadline path either poster OR taker can cancel, so one party can grief the other by locking the counterparty's refund/payment.
+- **Fix:** Constrain the escrow token account to its canonical PDA in every instruction that touches it, e.g. `#[account(mut, seeds = [b"escrow_token", job_escrow.key().as_ref()], bump, ...)]`, or store the escrow token account pubkey in JobEscrow at create_job and add `address = job_escrow.escrow_token_account`. Also prefer transferring `job.amount` rather than the live balance in cancel_job.
+
+### buy_claim does not prevent the poster from buying the claim, enabling self-dealing payout redirection
+- **File:** `/Users/baturalpguvenc/covenant/programs/covenant/src/instructions/buy_claim.rs:60-86`
+- **Category:** authority confusion / self-dealing  ·  **Confidence:** high
+- **What:** buy_claim only forbids buyer == seller (BuyerIsSeller, buy_claim.rs:64-67). It does not forbid buyer == job_escrow.poster. Once a claim is Bought, finalize_payment and resolve_dispute route the full escrow `amount` to listing.buyer (finalize_payment.rs:133, resolve_dispute.rs:219). The poster is the party who funded the escrow; letting them become the claim buyer means the escrow they funded can be routed straight back to them.
+- **Exploit:** 1. Taker delivers work and lists the claim at a discounted `price < amount`. 2. The poster calls buy_claim as the buyer, paying the taker only `price`. 3. The challenge window lapses with no dispute and anyone calls finalize_payment; the escrow `amount` is routed to the buyer ATA, i.e. back to the poster. Net effect: the poster reclaims the full escrow they originally locked while the taker is paid only the discounted `price` instead of the agreed `amount` — the poster cra m-downs the worker to the listing discount with no arbitration. The poster can also buy then raise a FavorPoster dispute to recover the escrow through the bond path while having paid only `price`.
+- **Fix:** Add `require!(ctx.accounts.buyer.key() != ctx.accounts.job_escrow.poster, CovError::Unauthorized)` in buy_claim, mirroring the existing BuyerIsSeller guard.
+
+
+## LOW
+
+### x402.ts uses non-USDC SOL transfer and reads raw keypairs from env JSON (mismatch with verifier; key-handling hazard)
+- **File:** `app/lib/x402.ts:23-61`
+- **Category:** key handling / protocol mismatch  ·  **Confidence:** medium
+- **What:** sendX402Payment transfers native SOL via SystemProgram.transfer (lines 33-39), but the x402 verifier (x402-server.ts verifyTransfer) only validates SPL-token (USDC) transfers via pre/postTokenBalances. A SOL transfer produced here would never satisfy verifyPayment, and amounts are handled as floating-point SOL (line 37) rather than atomic units. getAgentKeypair (lines 54-61) loads full secret keys from AGENT_ALPHA_KEYPAIR/AGENT_OMEGA_KEYPAIR env vars and JSON.parses them into Keypair.fromSecretKey with no validation; any log of fromKeypairBytes or error containing it would leak a signing key. This is a hot-wallet secret-handling and protocol-consistency hazard rather than a verification bypass.
+- **Exploit:** Not a direct external bypass. Operational risk: (a) payments sent via this path cannot be verified by the app's own x402 verifier, and (b) if AGENT_*_KEYPAIR is misconfigured or the byte array is logged/serialized in an error path, the agent's full Solana signing key is exposed, allowing an attacker to drain that wallet.
+- **Fix:** If this path is meant for x402 USDC payments, use SPL-token transfers of the canonical USDC mint in atomic units so it matches the verifier; otherwise clearly scope it as the demo SOL-battle path. Never JSON-embed raw secret keys; load from a KMS/secret manager, validate length (64 bytes), and ensure keypair bytes are never included in logs or thrown error messages.
+
+### x402 payment is bound to (agentId, message) but not to the paying caller's identity
+- **File:** `app/lib/x402-payments.ts:35-40 and app/app/api/hosted-agents/[id]/chat/route.ts:142-148`
+- **Category:** signature/payment binding  ·  **Confidence:** low
+- **What:** claimPayment binds a consumed payment to requestHash = sha256(agentId\nmessage) (x402-payments.ts:35-40). verifyPayment confirms the on-chain transfer went to the agent's walletAddress and meets amount/mint (x402-server.ts), which is correct. However the served request is not bound to the on-chain payer: any party who learns a valid, not-yet-consumed transaction signature for an agent can present it with the SAME message and obtain the paid response. The first-presenter-wins model plus the public nature of Solana tx signatures means a third party who sees the signature in a mempool/explorer before the legitimate payer submits can claim the response (and burn the payer's one-shot payment for that exact prompt).
+- **Exploit:** 1. Payer Alice broadcasts a USDC payment tx to the agent wallet and intends to POST {message, Payment-Signature: <sig>}. 2. Attacker Mallory, watching the chain, extracts <sig> once confirmed and POSTs it first with the SAME message (the quoted/known prompt). 3. claimPayment marks it fresh for Mallory; Mallory receives the paid response. 4. Alice's later POST with a different prompt is rejected as 'consumed', and her identical prompt only replays Mallory-triggered cached output.
+- **Fix:** Bind the served request to the on-chain payer: require the caller to also prove control of the payer wallet (sign the request with the payer key, reusing verifyWalletSignature), and include the payer in requestHash. Reject when verification.payer does not match the authenticated caller. This ties the one-shot payment to the actual payer rather than to whoever presents the public signature first.
+
+### hosted-agents/avatar trusts client-declared MIME type for image validation
+- **File:** `/Users/baturalpguvenc/covenant/app/app/api/hosted-agents/avatar/route.ts:5-17`
+- **Category:** Unrestricted file upload  ·  **Confidence:** medium
+- **What:** POST /api/hosted-agents/avatar validates only file.type.startsWith('image/') (line 10), which is the client-controlled MIME label, and then base64-encodes the raw bytes into a data:<file.type>;base64 URL returned to the caller. No magic-byte check is performed, so non-image content (e.g. an SVG with script, or an HTML payload labelled image/svg+xml) passes. The resulting data: URL is later used as an <img src>, where SVG can carry script in some rendering contexts. There is also no authentication on the route.
+- **Exploit:** 1. POST multipart with a file whose type is set to image/svg+xml containing an <svg><script>…</script>. 2. file.type.startsWith('image/') passes. 3. The endpoint returns data:image/svg+xml;base64,<payload>; if that URL is rendered in an SVG-script-capable context it can execute. At minimum it bypasses the intended image-only restriction.
+- **Fix:** Validate the actual file content with magic-byte sniffing and an allowlist of raster image types (png/jpeg/webp/gif). Explicitly reject SVG (or sanitize it with DOMPurify before storing). Add authentication and a size/type allowlist, and prefer Blob storage over base64 data URLs.
+
+### Markdown image src in chat rendered without scheme validation
+- **File:** `/Users/baturalpguvenc/covenant/app/app/chat/[id]/page.tsx:379-433`
+- **Category:** XSS / unsanitized content  ·  **Confidence:** medium
+- **What:** Chat messages are parsed with MD_IMAGE = /!\[([^\]]*)\]\(([^)]+)\)/ and the captured URL (inlineImg[2]) is placed directly into <img src={inlineImg[2]}> with no scheme allowlist. ChatMessage.content is stored from model output and from user/design-path input, so an attacker who can influence a stored agent/user message (e.g. via the a2a or chat APIs) can embed an arbitrary src. While `javascript:`/`data:text/html` in an <img src> does not execute script in modern browsers, the unrestricted src still enables tracking-pixel / SSRF-via-browser / content-spoofing and is a latent XSS sink if the renderer is ever changed to dangerouslySetInnerHTML or an <a>/iframe. No DOMPurify or scheme check is applied anywhere in the render path.
+- **Exploit:** 1. Cause a stored chat message to contain ![x](http://attacker/track?cookieless-beacon) (e.g. through a controllable agent response or message content). 2. When any user views the conversation, their browser fetches the attacker URL, leaking IP/timing and acting as a forced outbound request. The same sink would become script-executing XSS if the image markdown is later rendered into raw HTML.
+- **Fix:** Validate inlineImg[2] against an http(s) (and optional data:image/) allowlist before rendering; reject other schemes. Centralize a URL sanitizer for all user/model-derived src values and apply it to avatar src as well.
+
+### Unbounded findMany returns entire PublishedAgent table on public GET
+- **File:** `/Users/baturalpguvenc/covenant/app/app/api/agents/register/route.ts:153-173`
+- **Category:** Unbounded query / DoS  ·  **Confidence:** medium
+- **What:** GET /api/agents/register calls prisma.publishedAgent.findMany({ orderBy }) with no take/pagination and then builds an in-memory walletCounts map over every row. As the table grows (registration is unauthenticated and only soft-capped at 5 per wallet, with wallets being free to mint), this returns the full table on every request and does O(n) work, enabling memory/latency amplification. Several other API routes share this unbounded-findMany pattern (e.g. claims/leaderboard, elo/leaderboard, stats) and should be paginated as a class.
+- **Exploit:** 1. Register many agents across many wallets (registration is anonymous). 2. Repeatedly GET /api/agents/register. 3. Each request serializes the entire table and recomputes counts, amplifying memory and DB load and degrading availability.
+- **Fix:** Add take + cursor/offset pagination and a server-side cap; compute per-wallet counts with a groupBy aggregate instead of loading all rows. Apply the same bound to the other unbounded findMany routes.
+
+### Access-Control-Allow-Origin: * on /api/version leaks deployment topology cross-origin
+- **File:** `app/app/api/version/route.ts:40-45`
+- **Category:** Information disclosure / CORS  ·  **Confidence:** medium
+- **What:** GET /api/version sets `Access-Control-Allow-Origin: *` and returns VERCEL_URL (internal deploy hostname), VERCEL_REGION, VERCEL_ENV, VERCEL_GIT_COMMIT_REF (branch), VERCEL_GIT_REPO_SLUG and commit SHA. The wildcard CORS lets any malicious website read this build/topology metadata from a victim's browser. The endpoint is read-only and the values are low-sensitivity, but exact commit + branch + internal deploy URL + region are reconnaissance aids (e.g. pinning a known-vulnerable commit, finding the *.vercel.app preview host). This is the only place outside middleware's /api/openapi that emits wildcard CORS, and unlike openapi it discloses environment-derived internals.
+- **Exploit:** From attacker.com JS: `fetch('https://app/api/version').then(r=>r.json()).then(...)` succeeds cross-origin (ACAO *), exfiltrating branch name, internal VERCEL_URL preview host, region, and commit to the attacker.
+- **Fix:** Drop the `Access-Control-Allow-Origin: *` header on /api/version (it is not consumed cross-origin), or restrict it to a known origin allowlist. Consider removing branch/VERCEL_URL/repo-slug from the public body and keeping only a short commit hash.
+
+### Unauthenticated /api/metrics is open-by-default and exposes internal business + infra state
+- **File:** `app/app/api/metrics/route.ts:58-62`
+- **Category:** Information disclosure  ·  **Confidence:** medium
+- **What:** authorized() returns true when neither METRICS_SECRET nor CRON_SECRET is set (`if (!secret) return true; // open by default`). In any deployment that hasn't explicitly set one of those secrets, /api/metrics is fully public and emits per-table row counts, jobs/claims by status, total + settled USDC volume, accrued protocol fees, TVL, dispute counts and dispute rate, RPC slot, cache/query internals, and the deployed commit/region. This hands an attacker a live business dashboard (volume, fee revenue, dispute rate, user/job growth) and infra signals. db-stats/cache-stats/error-buffer are correctly admin-guarded via guardAdmin (fail-closed), so this open-by-default fallback is the inconsistent, weaker surface.
+- **Exploit:** If METRICS_SECRET and CRON_SECRET are unset in the environment, `curl https://app/api/metrics` returns the full Prometheus dump (covenant_settlement_volume_usdc, covenant_fees_accrued_usdc, covenant_db_table_rows{...}, covenant_dispute_rate, commit/region) to anyone.
+- **Fix:** Fail closed: require a secret rather than defaulting open (mirror admin-auth's `if (!secret) deny`). Use constant-time comparison (constantTimeEqual) instead of `===` on line 61 to avoid timing leakage of the secret.
+
+### /api/health returns raw dependency error messages (DB/RPC) to unauthenticated callers
+- **File:** `app/app/api/health/route.ts:73-78,107-113,138-141`
+- **Category:** Information disclosure  ·  **Confidence:** medium
+- **What:** GET /api/health is unauthenticated and always returns 200 with a JSON body. On failures it surfaces truncated raw error strings from Prisma/Postgres (up to 300 chars, line 77) and from the Solana RPC client (errDetail, 200 chars), plus the env-var presence list including the names ANTHROPIC_API_KEY and DATABASE_URL (lines 107-111), commit, and region. Raw driver error text can disclose hostnames, schema/relation names, driver versions, or connection details depending on the failure mode. The endpoint also reveals which required env vars are missing by name.
+- **Exploit:** An attacker polls `curl https://app/api/health` (especially during an incident/cold start) and reads checks.database.detail / checks.rpc.detail, which can include Postgres/driver error text (host, relation, version) and checks.env.detail naming missing secrets — useful recon with no credentials.
+- **Fix:** Return only coarse status booleans to unauthenticated callers; move detailed error strings behind guardAdmin (as db-stats already is) or log them server-side only. Do not echo env-var names in the public body.
+
+### Admin routes fall back to CRON_SECRET as the admin bearer — broad credential reuse
+- **File:** `app/lib/admin-auth.ts:14-16,28-34 (used by admin/error-buffer, cache-stats, db-stats)`
+- **Category:** Privilege boundary / credential reuse  ·  **Confidence:** medium
+- **What:** adminSecret() returns ADMIN_SECRET || CRON_SECRET. CRON_SECRET is the token Vercel Cron presents on scheduled job endpoints (e.g. /api/cron/*). Reusing it as the admin console secret means any component or log that legitimately sees the cron bearer can also read admin/db-stats, drain the error buffer, and clear caches. The admin routes themselves are correctly fail-closed (deny when no secret) and constant-time compared — this is about secret scope, not a bypass.
+- **Exploit:** If CRON_SECRET leaks via a cron misconfiguration, a third-party scheduler, or request logs (it travels on every cron invocation), the holder gains full admin read access (db-stats exposes wallet volumes, table counts, postgres version) and can clear the error buffer to hide incident traces. The two roles should not share one secret.
+- **Fix:** Require a dedicated ADMIN_SECRET and remove the CRON_SECRET fallback for admin routes (keep CRON_SECRET only for cron endpoints). Document that ADMIN_SECRET must be set or admin routes stay disabled.
+
+### GET/POST /api/keys signed message is replayable for ~the timestamp window (no per-request body binding on POST create)
+- **File:** `app/app/api/keys/route.ts:49-107 (create) and 6-47 (list)`
+- **Category:** Replay / authentication weakness  ·  **Confidence:** medium
+- **What:** The keys route is the one place that correctly binds wallet+ts into the expected message (cvn:keys:create:<wallet>:<ts>). However the message does not include a nonce or the request body, and verifyWalletSignature only enforces a 5-minute freshness window (MAX_TIMESTAMP_SKEW_MS) with no replay cache. A captured create/list signature can be replayed by anyone within that 5-minute window to mint another API key (POST) for the same wallet or re-list its keys (GET).
+- **Exploit:** An on-path observer or a malicious frontend that captures the wallet's signed 'cvn:keys:create:<wallet>:<ts>' value can replay it within 5 minutes to create additional API keys bound to the victim's wallet (each key being an act-as-that-wallet credential elsewhere), since there is no single-use enforcement.
+- **Fix:** Include a server-issued nonce (single-use, stored) in the signed message, or persist used (wallet,ts,signature) tuples within the freshness window to reject replays. Shorten the window for key creation.
+
+### battle/predict GET loads all predictions for a user-controlled battleId with no limit
+- **File:** `app/app/api/battle/predict/route.ts:56`
+- **Category:** unbounded-query  ·  **Confidence:** medium
+- **What:** GET /api/battle/predict?battleId=xxx runs `prisma.battlePrediction.findMany({ where: { battleId } })` with no `take`. It then returns every prediction row mapped into the response body (wallet, prediction, correct). battleId is fully attacker-controlled and the route is public/unauthenticated. The number of predictions per battle is bounded only by how many were inserted.
+- **Exploit:** If an attacker can drive many prediction rows onto a single battleId (predictions are created by spectators; the id is a client-supplied `battle-<timestamp>` string), then `GET /api/battle/predict?battleId=<that id>` returns and serializes the entire set on every poll. Repeated polling of a hot battleId amplifies DB read + response-serialization cost. Lower impact than the stats routes because per-battle volume is naturally smaller, but it is still an unbounded user-controlled fan-out.
+- **Fix:** Use `prisma.battlePrediction.groupBy`/`count` to compute alpha/omega tallies DB-side instead of pulling every row, and cap the `predictions` array returned to the client with a `take`.
+
+### In-memory rate-limit Map is per-serverless-instance and trivially bypassed under load
+- **File:** `app/lib/rateLimit.ts:6`
+- **Category:** rate-limit-bypass  ·  **Confidence:** medium
+- **What:** The synchronous `rateLimit()` / `store` Map limiter is per-process. On Vercel each warm container has its own Map, so the same caller hitting different containers gets a fresh window — the cap is effectively multiplied by the number of live instances. The file itself documents this and provides `rateLimitDurable` (Postgres-backed) for sensitive routes, but any route still calling the in-memory `rateLimit()` for an expensive operation is bypassable by simply sending requests in parallel so they fan out across instances.
+- **Exploit:** For any endpoint guarded only by the in-memory `rateLimit()`, an attacker sends a burst of concurrent requests; Vercel load-balances them across N containers, and each container independently allows up to `limit` before tripping, yielding ~N×limit effective throughput. Combined with the spoofable-IP issue this removes the throttle on expensive work.
+- **Fix:** Audit all call sites and ensure every financial / LLM / external-API route uses `rateLimitDurable` (already done for most). Keep the in-memory limiter only for non-sensitive, best-effort throttling, and document that it must never be the sole guard on an expensive route.
+
+### Admin data-dump endpoint runs four fully unbounded findMany (no take)
+- **File:** `app/app/api/admin/route.ts:15`
+- **Category:** unbounded-query  ·  **Confidence:** high
+- **What:** GET /api/admin loads the ENTIRE Job, Profile, Reputation, and Submission tables in parallel with `findMany` and no `take`/pagination, then serializes all of it into one JSON response. The route is protected by `guardAdmin`, so it is not anonymously reachable, but it is still an unbounded full-table materialization that scales with DB size and can OOM the function or time out once tables are large.
+- **Exploit:** A compromised or careless admin token hitting GET /api/admin on a populated production DB pulls every row of four tables into memory and serializes them in a single response, spiking memory and potentially crashing the instance. Because Submission includes `outputText` (full deliverable bodies), the payload can be very large. Lower severity due to the admin auth gate.
+- **Fix:** Add bounded `take` + cursor/offset pagination to all four queries, and exclude large columns (e.g. Submission.outputText) from the dump unless explicitly requested.
+
+### Dispute bond uses non-atomic Float math with a tolerance window; tiny escrows allow under-bonding and rounding abuse
+- **File:** `app/app/api/jobs/[id]/dispute/route.ts:99-110`
+- **Category:** decimal-abuse  ·  **Confidence:** low
+- **What:** minBond is computed as `(job.amount * 1000) / 10000` in JS floating point (line 99) and the on-chain bond match uses `Math.abs(onchain.dispute.bond - providedBond) > 1e-6` (line 153). job.amount is a Float (USDC human units). For very small or fractional job.amount the 10% bond can round to a value whose float representation differs from the on-chain atomic bond by more than 1e-6 in edge cases, or be undercut by submitting a providedBond just under minBond that still passes due to float error. More importantly the DEFAULT_MIN_BOND_ABSOLUTE of 1 USDC means disputes on sub-10-USDC jobs are cheap relative to the value they block, and the bond is the only economic deterrent to griefing.
+- **Exploit:** Post/locate a low-value job; raise a dispute with the minimum 1 USDC bond to lock a delivered job worth nearly as much, or exploit float rounding so providedBond < trueMinBond passes the `<` comparison. Combined with the no-pda griefing finding, the bond may not be escrowed at all.
+- **Fix:** Do all bond math in integer atomic units (USDC * 1e6) and compare exactly against the on-chain bond. Raise the minimum absolute bond and make it scale so griefing is never cheaper than the blocked payout. Reject providedBond unless it exactly equals the on-chain bond.
+
+### Split dispute resolution lets a malicious arbitrator-quorum overpay taker up to full escrow with no poster signature
+- **File:** `app/app/api/disputes/[id]/resolve/route.ts:95-108,179-184`
+- **Category:** claim-economic-exploit  ·  **Confidence:** low
+- **What:** For a Split resolution, takerAmount is taken from the body and only bounded by `takerAmount >= 0` and `takerAmount <= dispute.job.amount`. The actual fund movement is supposed to be enforced on-chain (the route verifies the resolve_dispute tx and JobEscrow status==Resolved), but the DB mirror records payoutToTaker and credits taker reputation/totalEarned from the body value, which is only loosely tied to the on-chain split. If a claim was Bought before the dispute, resolveClaimBeneficiary (credit-server.ts:316) routes finalize proceeds to the buyer — but a Resolved job never reaches finalize, so a buyer who factored a receivable that then loses/splits a dispute silently eats the loss while the DB may still show the claim as Bought (no Cancelled/loss state written on resolve). This is the 'buy a claim then force a favorable dispute' adjacency: the seller (taker) can collude with the poster to split, getting paid on-chain while the buyer's factored claim is stranded.
+- **Exploit:** Taker lists and sells a claim (buyer pays seller). Taker then colludes with poster (or the poster is the same Sybil) to raise a dispute and have the arbitrator quorum resolve Split/FavorPoster. Escrow is refunded/split away from the buyer; the buyer's purchase price is lost and the ClaimListing is never marked Settled/Cancelled, leaving stale Bought state.
+- **Fix:** On dispute resolution, if a ClaimListing for the job is Bought, explicitly transition it to a Cancelled/Defaulted state and record the buyer's loss; surface this in the marketplace. Validate that off-chain payoutToTaker exactly matches the on-chain split before crediting reputation/totalEarned.
+
+### Revenue amount derived by float division can drift from the verified atomic amount
+- **File:** `app/app/api/hosted-agents/[id]/chat/route.ts:177`
+- **Category:** rounding-decimal-confusion  ·  **Confidence:** high
+- **What:** paidAmountUsdc is computed as Number(verification.amountAtomic ?? '0') / 1_000_000 — a JS float divide of a u64 atomic value. This float is then stored as AgentRevenue.amount and incremented into HostedAgent.totalRevenue. reconcileRevenue (x402-payments.ts:194) later re-multiplies AgentRevenue.amount by 1e6 and Math.round()s it to compare against the stored atomic X402Payment.amountAtomic. For payments whose atomic value is not exactly representable as a 6-decimal float (or for large sums), the round-trip atomic->float->atomic can drift by 1 atomic unit, making reconciliation report false drift; and totalRevenue accumulates float error over many payments.
+- **Exploit:** Not a direct theft path: an overpaying caller (amountAtomic larger than quoted, allowed because verifyTransfer only enforces >= required) has the exact overpaid atomic amount stored in X402Payment.amountAtomic but a lossy float in AgentRevenue.amount. Over many such payments the dashboard totalRevenue and reconcileAgentRevenue drift apart, and an attacker could deliberately submit awkward atomic amounts to make reconciliation perpetually report non-zero drift, masking a real discrepancy.
+- **Fix:** Carry the atomic amount end-to-end. Store AgentRevenue in atomic units (or a Decimal column) and only convert to human units at display time; have reconcileRevenue compare atomic-to-atomic without a float round-trip. Use lib/token-math atomicToUsdc/usdcToAtomic string-based conversion instead of Number()/1_000_000.
+
+### x402 payer attribution uses 'largest debit' heuristic, allowing payer spoofing in the consumed-payment record
+- **File:** `app/lib/x402-server.ts:268-307`
+- **Category:** payment-attribution  ·  **Confidence:** low
+- **What:** summarizeCreditsToRecipient picks the payer as the owner with the single largest debit of the paid mint across the whole transaction (biggestDebit). In a transaction that moves the required USDC to the agent wallet but also contains an unrelated larger USDC debit from a different account (a batched/CPI tx the attacker crafts), the recorded payer is the unrelated big-debit owner, not the actual funder of the agent payment. The payer value is persisted as X402Payment.payer and used as the AgentRevenue.userWallet fallback and in logs.
+- **Exploit:** An attacker constructs one transaction that (a) transfers the required amount of the correct USDC mint to the agent wallet and (b) includes a larger USDC transfer between two attacker-controlled accounts. verifyTransfer still passes (recipient got >= required of the right mint), but the recorded payer/userWallet is attributed to the wrong account, corrupting revenue attribution and any per-payer rate/abuse accounting keyed on payer.
+- **Fix:** Attribute the payer to the account whose debit of the paid mint is matched to the credit to the recipient (e.g. the source in the specific transfer instruction to payTo), not the global largest debit. Parse the actual transfer/transferChecked instruction sourced to the recipient ATA, or at minimum scope biggestDebit to debits that plausibly fund the recipient credit.
+
+### init_config accepts unbounded/unsafe parameters (no upper bound on bond bps, no max_challenge_period ceiling, no min_bond sanity)
+- **File:** `/Users/baturalpguvenc/covenant/programs/covenant/src/instructions/init_config.rs:32-49`
+- **Category:** missing validation  ·  **Confidence:** medium
+- **What:** init_config validates only threshold (2..=ARBITRATOR_COUNT) and `min_challenge_period > 0 && <= max_challenge_period`. There is no upper bound on min_bond_bps (can exceed 10_000 = 100%), no ceiling on max_challenge_period (can be set so large that funds are effectively locked for years), and update_arbitrators (update_arbitrators.rs:21-37) lets the admin rotate the entire arbitrator set and threshold with no timelock and no requirement that arbitrators be distinct. Duplicate arbitrator pubkeys are silently accepted; combined with resolve_dispute's `position()` lookup this does not bypass the 2-of-3 count (a duplicate maps to one index) but it shrinks the effective arbitrator set and is a foot-gun.
+- **Exploit:** A malicious/compromised admin sets min_bond_bps far above 10_000 (raise_dispute then demands a bond larger than the escrow, making disputes economically impossible and effectively disabling poster protection), or sets max_challenge_period to an enormous value so a job created with the max challenge period locks escrow indefinitely. Admin can also rotate arbitrators to a single key duplicated across slots, reducing the security of the 2-of-3 to effectively 1 real signer with 2 distinct keys it controls.
+- **Fix:** Bound min_bond_bps <= 10_000, cap max_challenge_period to a protocol maximum, and in init_config/update_arbitrators reject duplicate arbitrator pubkeys and Pubkey::default() slots. Consider a timelock or multisig on admin parameter changes.
+
+### accept_job allows the poster to accept their own job as taker
+- **File:** `/Users/baturalpguvenc/covenant/programs/covenant/src/instructions/accept_job.rs:26-39`
+- **Category:** self-dealing / authority confusion  ·  **Confidence:** medium
+- **What:** accept_job sets job.taker = signer with no check that taker != poster. The poster can therefore become the taker of their own escrow. Downstream this lets a single party occupy both sides of the escrow (poster and taker), which interacts with the claim/reputation system: the poster-as-taker can deliver, list a claim, and finalize, inflating their own AgentReputation (jobs_completed/total_earned) using their own funds, and muddying the dispute model (poster disputing a job they also delivered).
+- **Exploit:** 1. Attacker creates a job funding `amount` of their own tokens. 2. Same wallet calls accept_job, then submit_work, then after the challenge window finalize_payment routes `amount` back to themselves. 3. Their AgentReputation is incremented (jobs_completed += 1, total_earned += amount) at zero real cost (minus rent/fees), enabling reputation farming that other parts of the system or off-chain consumers may trust.
+- **Fix:** Add `require!(ctx.accounts.taker.key() != job.poster, CovError::Unauthorized)` in accept_job.
+
+### Bond token account in resolve_dispute is not mint-validated
+- **File:** `/Users/baturalpguvenc/covenant/programs/covenant/src/instructions/resolve_dispute.rs:51-56`
+- **Category:** missing mint constraint  ·  **Confidence:** medium
+- **What:** The bond_token_account is accepted via `seeds = [b"bond", job_escrow.key()], bump` with no mint constraint, unlike escrow_token_account which checks `mint == job_escrow.token_mint`. In practice the canonical bond PDA was created in raise_dispute with token::mint = token_mint (validated there against job_escrow.token_mint, raise_dispute.rs:44-47), so the on-chain account is correct. The missing redundant check is defense-in-depth: if the bond PDA derivation or the escrow_token_account constraints were ever loosened, a mismatched bond mint could be transferred to the taker/poster.
+- **Exploit:** Not independently exploitable today because raise_dispute is the only creator of the bond PDA and binds the correct mint. Reported as a hardening gap: the resolve path transfers bond to beneficiaries (resolve_dispute.rs:256-277) without re-asserting the mint equals the escrow mint, so it relies entirely on the raise_dispute invariant holding forever.
+- **Fix:** Add `constraint = bond_token_account.mint == job_escrow.token_mint @ CovError::MintMismatch` to the bond_token_account account in ResolveDispute.
+
+
+## INFO
+
+### Raw SQL queries reviewed — no SQL injection found (parameterized / static)
+- **File:** `/Users/baturalpguvenc/covenant/app/app/api/claims/route.ts:149; /Users/baturalpguvenc/covenant/app/app/api/settlement/stats/route.ts:226-269; /Users/baturalpguvenc/covenant/app/lib/prisma.ts:190`
+- **Category:** SQL injection (negative finding)  ·  **Confidence:** high
+- **What:** All raw query usage was audited. claims/route.ts uses $queryRawUnsafe but with a fully static string literal (no interpolation). settlement/stats uses $queryRaw with Prisma.sql tagged templates and no user-interpolated values. lib/prisma.ts $executeRawUnsafe and lib/db-quota / lib/rateLimit raw queries operate on hardcoded migration DDL or Prisma.sql-parameterized values (the only dynamic value, a Date, is bound as a parameter). No user input flows into a raw SQL string via interpolation, so no SQL injection is present in the audited surface. JSON-path filters and a2a task lookups use Prisma's safe query builder.
+- **Exploit:** N/A — no injectable raw query path. Documented so the negative result is explicit: $queryRawUnsafe at claims/route.ts:149 is safe only because its argument is a constant; if a future edit interpolates a variable there it becomes injectable, so flag it for a lint guard.
+- **Fix:** Replace the lone $queryRawUnsafe at claims/route.ts:149 with $queryRaw + Prisma.sql to remove the foot-gun, and add a lint rule forbidding template-literal interpolation into $queryRawUnsafe/$executeRawUnsafe.
+
+### escrow/build advertises demoMode unconditionally with no onchain guard (relies entirely on /api/jobs to fail closed)
+- **File:** `app/app/api/escrow/build/route.ts:17-28`
+- **Category:** settlement-mode-bypass  ·  **Confidence:** high
+- **What:** POST /api/escrow/build always returns {demoMode:true}, instructing the client to skip signing and post a record-only job. It has no blockSimulatedRouteIfOnchain / assertSimulatedAllowed guard of its own. The only thing preventing a fake settlement under SETTLEMENT_MODE=onchain is that the downstream /api/jobs route guards itself (jobs/route.ts:135) and that fakes-gate.ts only scans for sendMarkerTransaction. The demoMode contract itself is not gated here, so the fail-closed guarantee depends entirely on every current and future consumer of this signal also being guarded. This is a defense-in-depth gap rather than a live bypass today.
+- **Exploit:** No direct exploit while /api/jobs remains guarded: in onchain mode /api/jobs returns 501 for the demoMode branch. The risk is regression — a new route that trusts escrow/build's demoMode flag (or a relaxed guard on /api/jobs) would silently re-enable record-only 'settled' jobs in onchain mode, because the instruction to fake originates from this unguarded endpoint.
+- **Fix:** Have escrow/build itself return blockSimulatedRouteIfOnchain('POST /api/escrow/build') (501) when isOnchainMode(), so the demoMode instruction can never be emitted in onchain mode regardless of what downstream consumers do.
+
+### finalize_payment / resolve_dispute manually deserialize claim_listing without asserting its stored bump or seller identity
+- **File:** `/Users/baturalpguvenc/covenant/programs/covenant/src/instructions/finalize_payment.rs:111-130 (and resolve_dispute.rs:203-215)`
+- **Category:** unchecked account data  ·  **Confidence:** high
+- **What:** The claim_listing is an UncheckedAccount validated by Anchor's seeds=[b"claim", job_escrow.key()] + bump on the address, then manually deserialized. The handler checks owner == program_id and listing.job == job_key before trusting listing.buyer for payout routing. This is correct, because the address is PDA-pinned to the job and a Bought listing can only have been created/bought through list_claim/buy_claim for this exact job. No exploit found: an attacker cannot substitute a different listing (address is fixed by seeds) nor forge listing.buyer (set only in buy_claim after a real token transfer). Reported only to confirm the routing was reviewed and is sound.
+- **Exploit:** No exploit. The PDA address binding plus owner==program_id plus listing.job==job_key prevents substitution or forgery of the payout destination. The seller-crank-bypass vector described in the code comments is genuinely closed because the claim_listing is a mandatory, deterministically-addressed account that the crank cannot omit or swap.
+- **Fix:** No change required. Optionally assert listing.bump for completeness, but it is not security-relevant given the seeds+bump address check.