Update AutoBoy skill before Quotient TGE & to reflect API key now being self-serve

[jeff-computers]

No description provided.

[saltoriousSIG]

High/medium issues I’d block on:

• POST /api-keys returns a long-lived bearer key exactly once, but the workflow does not prevent that response from being printed into the agent transcript, logs, or command output before it reaches the secret store. Please require explicit user approval before provisioning the account/wallet, capture apiKey directly into an approved secret store without displaying or persisting the raw response, redact it from all logs/errors, verify the resulting identity with /me, and document key scope, rotation/revocation, and incident recovery. A globally unique public label should not be treated as proof of identity or ownership.
• The user is told to fund autoboyWalletAddress returned by the API, which is untrusted third-party output and gives The Firm delegated custody. Before any transfer, require local validation of the exact supported chain ID, canonical USDC/USDG contract and decimals, recipient wallet, human/raw amount, native value, gas/fees, and total custodial exposure; cross-check the address through an authenticated identity/wallet call, show that The Firm can spend all deposited assets, and obtain final confirmation. Reject changed/unknown addresses, chains, assets, calldata, or extra transactions, stop on Bankr scanner errors, and verify the mined transfer plus expected token balance before reporting funding success.
• Pre-launch orders authorize a future automatic purchase before the token contract, route, liquidity, and launch conditions are known. Please require each order to have a strict per-order and aggregate spend cap, exact chain, expiry, max FDV, maximum slippage/price impact, allowed venue/router, allowed transaction count, and cancellation behavior. At launch, AutoBoy must validate the deployed token contract against the registered project and reject proxies/changed contracts, honeypot or transfer restrictions, unexpected approvals/value/routes, inadequate liquidity, stale conditions, and any execution exceeding the confirmed limits; otherwise the skill is delegating an effectively blind trade.
• Add a clear speculative-risk disclosure before order confirmation: pre-launch tokens may be scams or become worthless; launch prices and liquidity are uncertain; automated execution may suffer slippage/MEV; Robinhood Chain, bridges, smart contracts, Privy, and The Firm add custody/operational risk; and this is not investment advice. Project metadata, social distribution, API responses, and generated demand simulations must never trigger an order automatically.
• Withdrawal confirmation validates only a syntactically valid EVM address. Require exact chain ID, canonical asset contract, available balance, destination ownership, amount in human/raw units, max expansion, gas/fees, and any custody fee in the preview; reject unknown tokens/chains and changed API-prepared fields. After submission, require a transaction hash, mined receipt, expected transfer event, and destination/balance verification before reporting success or retrying after an ambiguous response.
• Project registration sends contact details and potentially unreleased launch/campaign information to a human reviewer, while buyer orders disclose identity, size, and price to project teams. Please require a field-level preview and explicit confirmation before either disclosure, prohibit credentials/private URLs/personal data not needed for review, and treat buyer lists and project submissions as sensitive untrusted data that must not be shared or acted on without authorization.