Daily risk stack

12 approved risks today. 13 bounded experiments total.

The desk is taking one sharper commercial risk today: Onchain Agent Identity Readiness makes ApexScout easier for public buyer agents and x402 services to inspect and trust from our own public surfaces. It keeps Base x402 as the proven paid rail, does not auto-register onchain, does not store private keys, does not contact third parties, does not scrape or scan, and does not fake demand.

Payment rails Dashboard Risk JSON
#13 intense-active-today

IdentityScout / medium risk

Onchain Agent Identity Readiness

Agent-native buyers increasingly need identity, reputation, and trust signals before paying. ApexScout can publish ERC-8004-ready metadata and a clear inbound review path without changing settlement rails or contacting third parties.

Today

Publish /agent-identity, /api/agent-identity, /.well-known/apexscout-identity.json, /agent-discovery, and /api/agent-discovery as own-surface review paths only.

Guardrails

  • Do not auto-register ApexScout onchain.
  • Do not send agent-to-agent messages automatically.
  • Do not store private keys, seed phrases, or registry credentials.
  • Do not change the seller wallet, facilitator, endpoint paths, or Base x402 settlement rail.
  • Do not make paid external calls or paid upstream calls.
  • Do not send DMs, emails, posts, replies, or follow-ups automatically.
  • Do not inspect third-party domains, scrape, scan, or collect outside pages.
  • Do not claim onchain registration, discovery traction, paid completions, or feedback before verified evidence exists.
  • Keep public results aggregate-only and buyer-level data redacted.

Success

  • Onchain identity readiness is visible on /agent-identity and machine-readable at /api/agent-identity.
  • Public agent card links to the identity metadata without claiming registration is complete.
  • The legacy /agent-discovery path explains only ApexScout-owned public docs, cards, onboarding, and manual test routes.
  • The public review path does not send messages, contact third parties, make paid calls, or claim traction.
  • Unpaid protected requests still return HTTP 402 and Base x402 remains active.

Stop if

  • Any public surface claims ERC-8004 registration before a verified transaction exists.
  • Private keys, seed phrases, wallet secrets, or registry credentials appear in the app or data files.
  • Automatic sends, third-party contact, scraping, scanning, or paid external calls appear.
  • Protected paid routes stop returning 402.
  • Base x402 payment rail, seller wallet, facilitator, endpoint paths, or prices drift unexpectedly.
  • Public pages expose buyer prompts, wallet-level history, raw feedback, watched subjects, or paid response bodies.
Open related surface
#1 intense-active-today

RevenueKit / medium risk

Inbound Revenue Kit

The service already has x402 payment proof. The next real step is making ApexScout easier for inbound buyer agents and builders to understand, test, and pay without external automation.

Today

Publish the public agent card, $5 Agent Revenue Audit route, 402 rescue updates, aggregate Cash Register, and inbound listing kit while keeping the release inbound-only.

Guardrails

  • No automatic contact.
  • No outside-domain lookup or third-party scanning.
  • No contact scraping.
  • No fake visits, feedback, paid completions, or revenue.
  • No paid upstream calls.
  • No settlement rail switch.
  • Base mainnet remains active.
  • Polygon remains experimental.
  • Solana remains watch-only.
  • Public metrics remain aggregate-only.

Success

  • One external paid completion.
  • One Agent Revenue Audit purchase.
  • Three useful feedback items.
  • Five source-tagged unpaid 402 challenges.
  • One repeat paid buyer.

Stop if

  • Public buyer wallet appears.
  • Protected paid routes stop returning 402.
  • Base x402 breaks.
  • Public pages expose buyer-level data.
  • Outbound automation appears.
  • Paid upstream calls appear.
  • Fake metrics appear.
Open related surface
#2 intense-active-today

InboxBridge / medium risk

Agent Inbox Bridge Sprint

Other agents need a durable way to find and contact ApexScout. An inbox bridge can increase qualified agent-to-agent testing and 402-to-paid conversion without giving ApexScout spending or outbound autonomy.

Today

Publish /agent-inbox, /api/agent-inbox, /.well-known/apexscout-inbox.json, and /api/agent-message-intake while keeping outbound automation and Messenger payments disabled.

Guardrails

  • No automatic outbound messaging.
  • No contact scraping.
  • No paid upstream calls.
  • No agent spending.
  • No Messenger payments.
  • No settlement rail switch.
  • Base mainnet remains active.
  • Polygon remains experimental.
  • Solana remains watch-only.
  • Public metrics remain aggregate-only.

Success

  • At least 3 source-tagged inbox or intake tests.
  • At least 1 public-agent or inbox test reaches a 402 challenge.
  • At least 1 paid completion sourced from the inbox or inbound tester flow.
  • At least 1 useful feedback item from another agent or builder.
  • Actual errors stay flat.

Stop if

  • Public surfaces imply automatic outreach happened.
  • Public surfaces imply Masumi payments are production settlement.
  • Public surfaces expose buyer-level data.
  • Protected routes stop returning 402.
  • Base x402 production rail changes unexpectedly.
Open related surface
#3 approved-extra-today

CheckoutPilot / medium risk

Paid Retry Sprint

The service already receives unpaid 402 challenges. The fastest path to more revenue is making the first paid retry obvious, cheap, and useful.

Today

Keep a 15-path zero-contact source cap, keep /instant-x402 and /402-rescue visible, and measure real inbound 402-to-paid movement.

Guardrails

  • No auto-spend.
  • No paid upstream calls.
  • No auto-outreach.
  • No scraping.
  • No fake traction.
  • No rail switching.
  • Base mainnet remains active.
  • Polygon remains experimental.
  • Solana remains watch-only.
  • Public metrics remain aggregate-only.

Success

  • 3 paid completions.
  • 3 useful feedback records.
  • 1 repeat paid buyer signal.
  • Actual errors stay flat.

Stop if

  • Actual errors increase.
  • Protected-route paid flow breaks.
  • Unpaid protected calls stop returning 402.
  • Public surfaces imply fake or automatic contact.
  • Buyer-level privacy boundary breaks.
Open related surface
#4 approved-extra-today

SignalRouter / medium risk

Qualified Tester Sprint

The next meaningful commercial proof is not more passive traffic; it is a small, better-qualified tester wave that can produce real route attempts, payment friction feedback, or paid retries.

Today

Keep the next zero-contact exposure cap at 15 source-tagged owned paths and require real aggregate movement before widening.

Guardrails

  • Do not auto-send DMs, posts, emails, community messages, or replies.
  • Do not scrape contacts or infer private buyer identities from source traffic.
  • Do not make paid purchases, paid upstream calls, or payment-rail changes from this sprint.
  • Do not manufacture visits, feedback, 402 challenges, paid completions, revenue, or social proof.
  • Keep public results aggregate-only: source visits, unpaid 402 challenges, paid 200 completions, feedback count, and actual errors.

Success

  • /api/apexscout-distribution exposes the higher qualified tester cap and source-tagged paths.
  • The dashboard shows the tester sprint as today's active risk without claiming outreach happened automatically.
  • At least one qualified source produces a real tagged visit, route attempt, 402 challenge, paid completion, or feedback before widening again.
  • Base remains the active paid rail and unpaid protected requests still return HTTP 402.
  • Actual errors remain flat at zero during the sprint.

Stop if

  • Tagged visits rise but protected route attempts, feedback, and paid retries stay flat.
  • Any public surface implies messages were sent automatically or paid tests were run automatically.
  • Actual errors increase after the sprint copy or source routing change.
  • Any public surface leaks buyer-level prompts, wallet history, raw feedback, watched subjects, or paid response contents.
Open related surface
#5 approved-extra-today

LinkGuard / medium risk

Stripe Link Agent Wallet Readiness

If Link becomes a mainstream buyer wallet for agents, ARD should explain how Link-controlled agents can discover and pay for ARD without implying ARD has switched away from x402 Base settlement.

Today

Publish a Link Agent Wallet readiness page and API pack that separates buyer-side Link approvals, one-time-use cards, and shared payment tokens from ARD's proven Base mainnet x402 checkout.

Guardrails

  • Do not add Stripe Checkout, Stripe secret keys, Link OAuth, or card settlement to the live ARD payment flow.
  • Do not create Link spend requests, issue cards, approve purchases, or run paid purchases from this service.
  • Do not change Base mainnet x402, the facilitator, seller wallet, endpoint paths, or listed route prices.
  • Do not expose buyer prompts, wallet-level history, raw feedback comments, watched company names, or paid response bodies.
  • Require a separate Stripe/Link proof design before any public claim that ARD accepts Link card or token settlement.

Success

  • /link-agent-wallet and /api/link-agent-wallet-readiness explain the readiness lane clearly.
  • Docs JSON and dashboard link the Link lane without changing checkout behavior.
  • Base remains the active settlement rail and unpaid protected requests still return HTTP 402.
  • The public copy says Link is watched and buyer-side compatible, not production-settled by ARD.

Stop if

  • Any public surface implies ARD accepts Stripe card settlement today.
  • Any public surface implies Link spending is automatic or controlled by ARD.
  • Payment mode, facilitator, seller wallet, endpoint paths, prices, or active settlement rail drift unexpectedly.
  • Any public surface leaks buyer-level data, prompts, wallet history, raw feedback, watch subjects, or paid response contents.
Open related surface
#6 approved-extra-today

PassportScout / medium risk

Kite Agent Passport Readiness

If Kite Passport becomes a meaningful agent identity and delegated-payment layer, ARD should already explain how buyer agents can use it without pretending the service accepts a new settlement rail.

Today

Publish a Kite Passport readiness page and API pack that separates buyer-side Passport compatibility from ARD's proven Base mainnet x402 settlement rail.

Guardrails

  • Do not accept Kite mainnet settlement in production.
  • Do not create Passport sessions, delegate spending, or run paid purchases from this service.
  • Do not change Base mainnet x402, the facilitator, seller wallet, endpoint paths, or listed route prices.
  • Do not expose buyer prompts, wallet-level history, raw feedback comments, watched company names, or paid response bodies.
  • Require a separate proof run before any public claim that Kite settlement is accepted.

Success

  • /kite-passport and /api/kite-passport-readiness explain the readiness lane clearly.
  • Docs JSON and dashboard link the Kite lane without changing checkout behavior.
  • Base remains the active settlement rail and unpaid protected requests still return HTTP 402.
  • The public copy says Kite is watched and buyer-side compatible, not production-settled by ARD.

Stop if

  • Any public surface implies ARD accepts Kite settlement today.
  • Any public surface implies Passport spending is automatic or controlled by ARD.
  • Payment mode, facilitator, seller wallet, endpoint paths, prices, or active settlement rail drift unexpectedly.
  • Any public surface leaks buyer-level data, prompts, wallet history, raw feedback, watch subjects, or paid response contents.
Open related surface
#7 approved-extra-today

CheckoutPilot / medium risk

Instant x402 Testbench

The shortest path to more paid completions is making the 402 to paid 200 loop feel immediate, copy-pasteable, and safe for buyer agents.

Today

Publish /instant-x402 and /instant as a route chooser with copy-paste payloads, unpaid probe instructions, and buyer-controlled x402 paid retry guidance.

Guardrails

  • Do not run paid purchases from the public page.
  • Do not change Base mainnet x402, the facilitator, seller wallet, endpoint paths, or listed route prices.
  • Do not expose buyer prompts, wallet-level history, raw feedback comments, watched company names, or paid response bodies.
  • Do not manufacture visits, feedback, paid completions, market demand, or social proof.
  • Keep Polygon proof-pack work separate from the active production checkout rail.

Success

  • /instant-x402 and /instant render a clear route chooser for buyer agents.
  • Docs JSON includes the testbench routes, prices, sample payloads, and 402 to paid 200 sequence.
  • Dashboard links the testbench as a conversion surface while public metrics remain aggregate-only.
  • Unpaid protected requests still return HTTP 402 and actual errors stay flat.

Stop if

  • Any public surface implies this page executes paid purchases automatically.
  • Any public surface leaks buyer-level data, prompts, wallet history, raw feedback, watch subjects, or paid response contents.
  • Payment mode, facilitator, seller wallet, endpoint paths, prices, or active settlement rail drift unexpectedly.
Open related surface
#8 approved-extra-today

ApexScout / medium risk

Marketplace Exposure Pack

The highest useful risk now is sharper marketplace exposure: make the public agent-facing package easier to inspect, easier to route, and harder to ignore without creating fake demand or touching settlement.

Today

Push the public exposure surfaces harder around /apexscout-launch, /agentic-alpha, /agentic-market-listing.json, /agent-capabilities.json, and /docs.json, then measure only aggregate visits, 402 challenges, checkout starts, paid completions, and actual errors.

Guardrails

  • Do not send automatic posts, DMs, emails, community messages, or contact-scraped outreach.
  • Do not run paid purchases or paid upstream calls from this risk.
  • Do not change Base mainnet x402, the facilitator, seller wallet, endpoint paths, or listed route prices.
  • Do not expose buyer prompts, wallet-level history, raw feedback comments, watched company names, or paid response bodies.
  • Do not manufacture visits, feedback, paid completions, market demand, or social proof.

Success

  • Marketplace Exposure Pack appears as today's intense active risk in /risk-experiments and /api/risk-experiments.
  • Dashboard keeps the risk visible while public metrics remain aggregate-only.
  • Docs keep Base as the accepted settlement rail and keep Polygon/Solana honest.
  • Unpaid protected requests still return HTTP 402 and actual errors stay flat.
  • The next inbound exposure move is tied to real aggregate signal instead of excitement.

Stop if

  • Any public surface leaks buyer-level data, prompts, wallet history, raw feedback, watch subjects, or paid response contents.
  • Actual errors increase after the exposure-pack change.
  • Payment mode, facilitator, seller wallet, endpoint paths, prices, or active settlement rail drift unexpectedly.
  • The service implies outreach, sales, or paid tests happened automatically.
Open related surface
#9 approved-extra-today

TrustLooper / small risk

Company Watch Activation Loop

The safest revenue risk is to move useful Company Intel results into a repeat trust loop, because Company Watch can create follow-on value without changing the proven x402 payment rail.

Today

Make Company Watch the active repeat-use experiment: watch aggregate Company Intel pressure, route buyers toward /company-watch when a named company should stay warm, and measure whether watch activation improves repeat revenue.

Guardrails

  • Do not auto-buy Company Watch or any other paid route.
  • Do not expose watched company names, buyer prompts, wallet-level history, or paid response contents publicly.
  • Do not change the live Base mainnet x402 rail, facilitator, seller wallet, endpoint paths, or prices.
  • Treat Company Watch as a justified follow-on only after a real named-company decision exists.

Success

  • Company Watch is visible as today's active repeat-use risk in /risk-experiments and /api/risk-experiments.
  • Dashboard and docs continue to show aggregate-only watch activity.
  • Base remains active on eip155:8453 and unpaid protected requests still return HTTP 402.
  • Operators get a clearer reason to push repeat-use revenue without creating fake demand.

Stop if

  • Any public page exposes watch subjects, buyer prompts, wallet history, or raw paid response contents.
  • Actual errors increase after the watch activation change.
  • The service implies Company Watch was purchased or activated automatically.
Open related surface
#10 active-today

VaultGuard / small-medium risk

Polygon Rail Proof Lab

Polygon could become the first expansion rail because it is EVM-compatible and x402 uses the same eip155 network family.

Today

Publish the Polygon rail proof pack and keep production on Base while staging Polygon behind X402_ENABLE_EXPERIMENTAL_RAILS=true for a separate proof run.

Guardrails

  • Do not change the live Base mainnet rail automatically.
  • Do not run a paid Polygon purchase from this public flow.
  • Do not treat this proof pack as production readiness or a paid settlement proof.
  • Require X402_ENABLE_EXPERIMENTAL_RAILS=true before Polygon can be configured.
  • Require separate unpaid 402, paid 200, settlement, discovery, and dashboard checks before calling Polygon production-ready.

Success

  • Polygon rail appears in /payment-rails and /api/payment-rails.
  • Base remains active on eip155:8453 in production.
  • Operators have a clear proof checklist before any real Polygon settlement test.
  • The proof pack makes the next paid test approval explicit instead of implied.

Stop if

  • Base 402 behavior changes.
  • Any endpoint path changes.
  • Payment facilitator or seller wallet config drifts unexpectedly.
Open related surface
#11 watch-only

Apex Sentinel / small risk

Solana Settlement Watch

Solana can matter for future agent wallets, so the service now stages an official @x402/svm proof lane without claiming production Solana settlement.

Today

Track Solana as a guarded SVM proof candidate and keep copy honest: wallet support is not the same as this service accepting proven Solana settlement.

Guardrails

  • Do not advertise Solana as accepted settlement.
  • Do not add Solana to production paid route requirements until the flagged SVM lane has a separate unpaid-402, paid-200, and USDC-settlement proof.
  • Do not treat recommended Solana sources as verified settlement proof.

Success

  • Solana appears as a guarded proof lane in the rail map.
  • Docs separate wallet awareness from accepted settlement.
  • No buyer is routed into a fake Solana checkout.

Stop if

  • Public docs imply Solana paid calls are accepted.
  • A Solana network is inserted into the active x402 middleware without a proof run.
Open related surface
#12 approved-extra-today

SignalRouter / small risk

Discovery Exposure Pressure

A safer daily growth risk is to widen discovery pressure and measure whether qualified agent traffic turns into 402 challenges and paid retries.

Today

Tighten the public discovery surfaces, source-tag the clearest buyer paths, and read only aggregate visits, 402 challenges, paid completions, feedback, and actual errors before any wider owned-surface exposure.

Guardrails

  • No automatic DMs, posts, community messages, or contact scraping.
  • No fake visits, fake feedback, or fake revenue.
  • No public buyer-level history or prompts.
  • No paid purchases and no production settlement rail switch.

Success

  • Dashboard shows aggregate route pressure.
  • ApexScout-owned docs, route metadata, and public agent cards remain easy to inspect.
  • Unpaid 402 challenges remain clearly separated from actual errors.
  • The next inbound exposure move is capped by real aggregate signal, not excitement.

Stop if

  • Public pages expose private buyer behavior.
  • Actual errors increase after a distribution change.
  • Buyer agents lose the clear Base checkout path.
Open related surface