@oracle-agent/oracle 0.13.0 → 0.14.0

package/skills/oracle-equities/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: oracle-equities
+description: Use when comparing on-chain equity venues (HIP-3, Arcus, RH Uniswap, Solana xStocks, TON). Cross-chain best execution for tokenized equities, prepare-only.
+---
+
+# Crossbook (on-chain equities best execution)
+
+On-chain equities are not one venue. HIP-3 builder DEXes discover price, Arcus/RH list spot and perps on Robinhood Chain 4663, Solana xStocks and TON ston.fi list tokenized spots. Rank **net of known costs**, never the loudest mid.
+
+## Get the comparison
+
+MCP (data plane, in-process, no desk required):
+
+```
+equity_venues
+equity_quote { ticker, sizeUsd?, horizonHours? }
+equity_prepare { ticker, recipient, sizeUsd? }
+```
+
+CLI:
+
+```bash
+oracle equities venues
+oracle equities quote NVDA --size 1000
+oracle equities quote SPY --size 500 --json
+oracle equities prepare NVDA --recipient 0xYourWallet
+```
+
+Library:
+
+```js
+import { bestEquityRoute, equityVenues, prepareEquityRoute } from "@oracle-agent/oracle/equities";
+```
+
+## Read the result properly
+
+- **`rankedOn`** — `net-of-cost` only when fees/gas/impact are known. Usually `gross` today because HIP-3 fees/gas and DexScreener floats are unmeasured. Say so.
+- **`costAccounted`** per route — `false` means that route is flattered by missing costs.
+- **`improvementBps`** — `null` when no honest same-class costed pair exists. Do not invent one.
+- **`bestPreparable`** is independent of `winner`. A quote-only HIP-3 or Solana mid can win discovery without being actionable here.
+- **`excluded[]`** is not `failed[]`. Dormant HIP-3 dexs and crossed Arcus books land in excluded with reasons.
+- **`darkWindow`** — outside NYSE core hours, marks are not real price discovery. Surface it.
+
+## Tiers
+
+| Venue | Tier | Can prepare? |
+| --- | --- | --- |
+| hyperliquid_hip3 | quote-only | no |
+| arcus_perp / arcus_spot | quote-only | no |
+| solana_xstocks | quote-only | no |
+| ton_stonfi | quote-only | no |
+| rh_uniswap | prepare | yes, unsigned only |
+
+v1 only prepares RH Uniswap on chain 4663. Everything else is discovery and carry comparison.
+
+## Rules
+
+- Never present a quote-only winner as something the user can sign here.
+- Never treat unknown gas/fees as zero.
+- Horizon mode compares spot vs perp with funding carry held constant and labeled as an estimate.
+- Prepare requires the real wallet as `recipient`. Placeholders are rejected by the RH prepare path when applicable.
+- A comparison is not an execution. Preparing is separate. Signing is the user's wallet.

package/skills/oracle-grants/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: oracle-grants
+description: Use when arming, widening, or refusing an agent action against a bound grant. Defines what authorization means on this desk.
+---
+
+# Bound grants
+
+The model proposes. The owner authorizes. A grant is the authorization.
+
+## What a grant is
+
+An owner-signed permission with hard bounds:
+
+```
+chain        which chain id, exactly one
+actions      read:chain | simulate:tx | prepare:* — never "broadcast:*"
+targets      destination allowlist: the addresses value may reach
+maxValueWei  spend cap
+maxGasWei    gas cap — gas is separate money
+expiresAt    unix timestamp; after this the grant is dead
+```
+
+Your reasoning is not authorization. A convincing argument that an action is safe
+does not widen a grant.
+
+## Refusing correctly
+
+When an action falls outside the grant, refuse and **name the bound that broke**:
+
+> Refused. Grant covers chain 8453; this route settles on 42161.
+
+> Refused. Destination 0xabc… is not in the allowlist for chain 8453.
+
+> Refused. Grant expired 14 minutes ago.
+
+A vague "I can't do that" teaches the user nothing. A specific refusal tells them
+exactly what to change if they still want it.
+
+## Fail closed, always
+
+An **empty** destination allowlist means *refuse everything*. It never means
+"nothing specified, so allow anything." This inverts under pressure — a partially
+configured chain looks like an unconfigured one. Fail closed.
+
+## Gas is separate money
+
+A grant that caps `value` but not gas is not capped. Unbounded gas limit or fee
+drains the wallet outside the value ceiling. Both caps or neither is meaningful.
+
+## The caps are not negotiable mid-task
+
+If a route needs more slippage than the cap allows, the answer is block, requote,
+or split — **not** widen. A cap that yields under pressure is decoration.
+
+Likewise a hard ceiling stays hard: a caller-supplied tolerance is a *maximum*, not
+the selected value.
+
+## Authorization expires
+
+Prefer short TTLs. A permanent broad grant is a hot wallet with extra steps. When a
+grant lapses, the lane returns to reading — that is the system working, not a
+regression to route around.
+
+## Re-check at the boundary
+
+Validate the grant at **sign time and broadcast time**, not only when the plan was
+made. State can change between planning and execution: a stale check is not a
+check. Reject a guard that is missing, stale, wrong-chain, wrong-venue, or
+over-cap.

package/skills/oracle-hypercore-staking/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: oracle-hypercore-staking
+description: Stake, delegate, undelegate, and unstake HYPE on Hyperliquid HyperCore. Prepare-only, user wallet signs.
+---
+
+# HyperCore HYPE staking
+
+Use when someone asks Oracle to stake HYPE, delegate to a validator, undelegate,
+or unstake back to spot on Hyperliquid.
+
+## The four moves, in order
+
+HyperCore keeps staking in two buckets. Know which one holds the HYPE before
+preparing anything.
+
+| Move | Action | From -> To | Timing |
+|---|---|---|---|
+| Stake | `cDeposit` | spot -> staking balance | instant |
+| Delegate | `tokenDelegate` isUndelegate=false | staking balance -> validator | 1 day validator lockup |
+| Undelegate | `tokenDelegate` isUndelegate=true | validator -> staking balance | instant after lockup |
+| Unstake | `cWithdraw` | staking balance -> spot | 7 day queue |
+
+Staking balance earns nothing until it is delegated. "Unstake" almost always
+means two steps: undelegate first, then withdraw.
+
+## Flow
+
+1. `desk.hl.staking.preflight(user)` - read delegated, undelegated, and pending
+   withdrawal balances plus the queue and lockup constants.
+2. `desk.hl.staking.validators()` - pick a validator. Reject jailed ones and
+   surface commission before recommending.
+3. Prepare exactly one move:
+   - `desk.hl.staking.prepareStake({ amountHype, maxHype })`
+   - `desk.hl.staking.prepareDelegate({ validator, amountHype, isUndelegate })`
+   - `desk.hl.staking.prepareUnstake({ amountHype })`
+4. Hand back the EIP-712 typed data. The user's wallet signs and submits.
+
+## Rules
+
+- Amounts are decimal HYPE strings at 8 decimals. `hypeToWei("1.5")` is
+  `150000000`. More than 8 decimals is rejected, not rounded.
+- `maxHype` is a hard cap checked before anything is built. No cap, no size
+  discipline on an agent path.
+- Never claim a stake happened. These functions return `broadcastReady: false`
+  and `requiresUserSignature: true`. There is no submit function in the module
+  on purpose.
+- Warn about the 7 day unstaking queue every time you prepare a `cWithdraw`.
+  The HYPE is illiquid for the whole queue.
+- Warn about the 1 day validator lockup before a delegate.
+- Check `undelegated` balance before preparing a withdraw. Withdrawing more than
+  the undelegated bucket fails on chain, and the failure costs the user a round
+  trip.
+
+## Verification
+
+`npm run e2e:hypercore-staking` hits live validator/delegator reads and asserts
+every prepare path stays unsigned with caps enforced.

package/skills/oracle-hyperliquid/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: oracle-hyperliquid
+description: Use for Hyperliquid perps and spot — funding, books, positions, liquidation distance via the public info API.
+---
+
+# Hyperliquid
+
+Read through Oracle's data plane (`hl-info` provider, public `/info` endpoint). No
+key required for reads.
+
+## Ops worth knowing
+
+| Need | Op |
+|---|---|
+| all mids | `allMids` |
+| order book | `l2Book` |
+| perp metadata + live ctx | `metaAndAssetCtxs` |
+| spot metadata | `spotMeta` |
+| account state | `clearinghouse` / `userState` |
+| fills | `userFills` |
+| open orders | `openOrders` / `frontendOpenOrders` |
+| candles | `candleSnapshot` |
+
+`metaAndAssetCtxs` is the efficient one: it returns funding, open interest, mark and
+oracle price for every asset in a single call. Prefer it over per-asset loops.
+
+## The three numbers that matter
+
+**Liquidation distance.** In percent. Always state it for a leveraged position. A
+"20x position" is really "a 5% adverse move ends this."
+
+**Funding.** Annualize it. A position paying 40% annualized is losing steadily even
+when directionally right. Funding flips sign — check the current rate, not the
+average.
+
+**Depth at your size.** The mid is a fiction for anything but the smallest clip.
+Walk the `l2Book` to your notional and quote the real average fill.
+
+## Mark vs oracle price
+
+Liquidations reference the **oracle** price; PnL references the **mark**. They
+diverge during volatility, which is exactly when it matters. Say which one you used.
+
+## Spot and perps are different assets
+
+The same ticker exists in both with different liquidity and no automatic
+relationship. Never quote a perp book for a spot question.
+
+## Hard rules
+
+1. State liquidation distance for every leveraged position — not optional.
+2. Annualize funding, always.
+3. Quote fills from book depth, not the mid.
+4. Never size to "max leverage" without naming the wipeout move.
+5. You prepare; the user's wallet signs.
+6. Receipts or it didn't happen.

package/skills/oracle-meme-token-sniper/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: oracle-meme-token-sniper
+description: Scan and prepare guarded meme-token launch/sniping trades across configured chains; fail-closed, user-signed, sell-sim first.
+---
+
+# Oracle meme-token sniper
+
+Use when a user asks Oracle to find, monitor, or prepare buys for meme tokens,
+new launches, liquidity adds, bonding curves, or "snipe" opportunities on any
+supported chain.
+
+## Scope
+
+Oracle may scan every configured venue/chain for meme-token launch signals:
+
+- EVM factory/pair/pool creation logs across configured chains.
+- Liquidity additions, first swaps, tax/owner-risk changes, holder distribution.
+- Solana SPL/token-launch feeds and Jupiter-route availability when configured.
+- Chain-specific launchpads/bonding curves only after the venue is verified.
+- Smart-wallet early-entry overlap and repeat deployer history.
+
+Unsupported chain/venue means `UNAVAILABLE`, not fake coverage. A chain with no
+verified executable route can still be analyzed, but cannot be prepared for buy.
+
+## Required gate before any prepared buy
+
+1. Resolve exact chain, token mint/contract, pool, quote asset, router/venue.
+2. Verify token identity from live chain data, not only a ticker/social link.
+3. Check deployer/owner controls, mint/freeze/blacklist/tax/proxy risks where
+   the chain exposes them.
+4. Confirm liquidity exists and is not only a fake/self pool.
+5. Run sellability / reverse-route simulation when the chain/venue supports it.
+6. Quote fresh, net of gas, and bind slippage/deadline to the prepared artifact.
+7. Enforce user caps: per-trade spend, chain, venue, token, max fee, and TTL.
+8. Return unsigned/user-signable transaction only. No model-authored calldata
+   bypass, no raw user calldata, no backend custody by default.
+
+## Autonomous mode
+
+Autonomous meme sniping is allowed only as a capped local-user signer loop:
+
+- separate burner/session key, never main wallet
+- explicit user opt-in and scope
+- max spend per token and per day
+- denylist/allowlist support
+- retry ceiling and kill switch
+- first-run paper/shadow mode
+- receipt/balance reconciliation after every fill
+
+Default public posture is advisory/prepare-only. "Snipe" in UI copy means fast
+scan + prepared ticket; it does not mean blind broadcast.
+
+## Output contract
+
+For every candidate, return:
+
+- `chain`, `token`, `pool`, `venue`
+- `signal`: launch/liquidity/smart-wallet/social/etc.
+- `risk`: PASS/WARN/BLOCK/UNKNOWN with evidence
+- `sellability`: PASS/FAIL/UNKNOWN/UNAVAILABLE
+- `route`: quote source and freshness
+- `prepared`: true only if a guarded unsigned artifact exists
+- `whyBlocked` when not prepared
+
+## Pitfalls
+
+- Treating ticker match as identity.
+- Buying before sell-sim/reverse-route proof.
+- Using scanner membership as an execution allowlist.
+- Calling a launchpool real when reserves are virtual/stale.
+- Ignoring gas: on small meme trades, gas can dominate edge.
+- Letting "every chain" become "every venue is executable". Coverage must be
+  capability-labeled per chain.

package/skills/oracle-multichain-nft-launch/SKILL.md

@@ -0,0 +1,338 @@
+---
+name: oracle-multichain-nft-launch
+description: Use when planning, building, reviewing, or preparing an NFT collection launch across EVM, Solana, Bitcoin Ordinals, Cosmos, Move, HyperEVM, or another chain family. Fail closed on unsupported adapters; preserve metadata provenance; prepare only; the user signs every side effect.
+---
+
+# Multichain NFT collection launch
+
+## Contract
+
+Use this skill for collection contracts or programs, metadata and media manifests,
+allowlists, public mints, royalties, reveals, editions, inscriptions, and collection
+verification.
+
+"Every chain" means classify the chain family and use a verified native standard.
+There is no universal NFT transaction. An ERC-721, a Metaplex collection, a Bitcoin
+parent inscription, a CW721 contract, and a Move object are different products.
+
+Oracle researches, scaffolds, tests, simulates, and prepares unsigned actions. The
+user signs collection creation, mint, metadata, authority, treasury, marketplace,
+and reveal actions separately. Never broadcast from this skill.
+
+When loaded by the `oracle` router, use this skill to classify the request, then
+route chain research to the relevant specialist and build/prepare work to
+`protocol-builder`. The router remains read and simulate only.
+
+If the launch uses randomized packs or loot mechanics, load
+`oracle-nft-gacha-launch` as an additional safety layer.
+
+## Support status language
+
+Use exactly one status before building:
+
+| Status | Meaning |
+|---|---|
+| `TEMPLATE_READY` | Oracle ships a gated collection template and prepare adapter for the exact standard. |
+| `ADAPTER_READY` | A chain-specific creation/mint encoder exists and passed simulation or testnet verification. |
+| `GUIDED_BUILD` | Oracle can scaffold and test the project, but no generic transaction adapter is shipped. |
+| `RESEARCH_ONLY` | Oracle can verify standards and produce a launch plan, not a deployable bundle. |
+| `UNSUPPORTED` | Required primitives or trustworthy tooling cannot be verified. Stop. |
+
+Do not call marketplace read or mint-bot support a collection-deployment adapter.
+Buying an NFT, minting from an existing contract, and creating a collection are
+three separate capabilities.
+
+## Current family matrix
+
+| Family | Collection primitive | Default status | Required path |
+|---|---|---|---|
+| EVM | ERC-721, ERC-1155, ERC-2981 | `GUIDED_BUILD` until a gated Oracle collection template ships | Foundry tests, metadata/reveal tests, fork simulation, unsigned deploy |
+| Solana | Metaplex Core, Token Metadata collection, Candy Machine/drop programs | `GUIDED_BUILD` | Select one standard, validate authorities, simulate ordered unsigned transactions |
+| Bitcoin | Ordinals parent/child inscriptions and indexer collection manifests | `GUIDED_BUILD` for content and commit/reveal planning; adapter evidence required for `ADAPTER_READY` | Provenance manifest, parent link, UTXO/fee/reveal safety |
+| Cosmos | CW721 or chain-native NFT module | `RESEARCH_ONLY` by default | Verify chain-specific instantiate/execute messages and migration admin |
+| Sui | object-based collection and kiosk ecosystem | `RESEARCH_ONLY` by default | Move package, object capabilities, display metadata, testnet publish |
+| Aptos | Digital Asset standard or chain-native collection objects | `RESEARCH_ONLY` by default | Collection/mint refs, mutation permissions, testnet publish |
+| HyperEVM | ERC-721 or ERC-1155 | EVM status | Exact HyperEVM chain id and verified RPC/toolchain |
+| Hyperliquid L1 | no generic NFT contract path assumed | `UNSUPPORTED` unless an official native primitive is verified | Route to HyperEVM when the product is EVM-native |
+| Other | chain-native | `UNSUPPORTED` until classified | Add and verify a dedicated adapter before preparing transactions |
+
+## 1. Build the collection manifest
+
+Do not generate contract or metadata artifacts until this manifest is complete:
+
+```yaml
+collection:
+  name: ""
+  symbol: ""
+  chain_family: ""
+  chain_name: ""
+  chain_id_or_genesis: ""
+  network: mainnet|testnet|devnet|local
+  standard: ""
+  supply: 0
+  edition_size: 1
+  onchain_media: false
+  license: ""
+  content_rating: ""
+mint:
+  price: ""
+  currency: ""
+  treasury: ""
+  per_wallet: 0
+  allowlist_root: none
+  allowlist_start: null
+  public_start: null
+  public_end: null
+  reveal: immediate|delayed|commit-reveal|vrf
+metadata:
+  base_uri: ""
+  storage: ipfs|arweave|onchain|other
+  mutable: false
+  provenance_root: ""
+  placeholder_uri: none
+royalties:
+  bps: 0
+  recipients: []
+authorities:
+  owner: ""
+  mint: ""
+  metadata_update: none
+  freeze: none
+  pause: none
+  withdraw: ""
+  upgrade: none
+```
+
+Validate supply against generated metadata count. Record raw payment units and
+human-readable units. Royalty splits must reconcile exactly.
+
+## 2. Set rights, metadata, and provenance first
+
+1. State who owns the media and which license collectors receive.
+2. Hash every final media and metadata file.
+3. Validate token IDs or asset indexes are unique and contiguous when required.
+4. Pin or upload content only after the user approves that side effect.
+5. Build a deterministic provenance root over the final ordered assets.
+6. Separate placeholder metadata from final metadata.
+7. State whether metadata can change, who can change it, and how that authority is
+   transferred or revoked.
+8. Never promise immutable media when the JSON points to mutable HTTP storage.
+
+Metadata upload, contract deployment, first mint, reveal, marketplace verification,
+and authority revocation are separate actions.
+
+## 3. Force an authority and economics review
+
+Before preparing transactions, print a table for:
+
+- contract, package, or program upgrade authority
+- collection owner
+- mint authority
+- freeze or transfer-restriction authority
+- metadata update authority
+- reveal authority
+- pause authority
+- treasury withdrawal authority
+- royalty recipient and royalty update authority
+- allowlist root setter
+- supply increase or edition authority
+
+For each, state initial holder, mutability, transfer/revoke action, and operational
+consequence of revocation.
+
+Also disclose:
+
+- total supply and reserved supply
+- mint phases and wallet caps
+- mint price and payment token
+- treasury destination
+- creator/team allocation
+- royalties and whether marketplaces can ignore them
+- upgradeability
+- delayed reveal and randomness assumptions
+- estimated deploy, storage, mint, and reveal costs
+
+Never market royalties as guaranteed income. Many marketplaces treat them as
+optional.
+
+## 4. Family-specific build paths
+
+### EVM
+
+Choose ERC-721 for unique items and ERC-1155 for editions or mixed fungibility.
+Add ERC-2981 only as a royalty signal, not enforcement.
+
+Prefer reviewed OpenZeppelin bases and minimal immutable deployment. If a proxy is
+required, show proxy admin, implementation upgrade authority, and timelock.
+
+Required Foundry coverage:
+
+- maximum supply and reserved supply cannot be exceeded
+- per-wallet and per-phase caps
+- exact payment and refund behavior
+- treasury withdrawal and reentrancy resistance
+- allowlist proof validation and replay boundaries
+- reveal ordering and provenance
+- metadata freeze or update permissions
+- royalty values and recipients
+- pause behavior
+- owner cannot mint hidden supply
+- ERC-721 or ERC-1155 interface conformance
+
+Run `forge test`, static analysis when available, fork or RPC simulation, and dry-run
+deploy. Prepare contract verification separately. Initial mint, public mint opening,
+base URI change, reveal, and ownership transfer are separate unsigned actions.
+
+### Solana
+
+Choose one product shape before code:
+
+- Metaplex Core for a modern asset/collection model
+- Token Metadata collection for compatibility with legacy NFT tooling
+- Candy Machine or another audited drop program for staged public mints
+
+Do not mix models casually. Print all collection, update, freeze/delegate, mint,
+rule-set, and candy-machine authorities.
+
+Prepare ordered unsigned transactions for:
+
+1. create the collection asset or collection mint
+2. create and verify collection metadata
+3. create drop/mint configuration when used
+4. fund storage/rent accounts
+5. mint or reserve initial assets
+6. verify items into the collection
+7. transfer or revoke update/mint authorities
+
+Simulate against the intended cluster. Validate account owners, rent, compute units,
+address lookup tables, and transaction size. Rebuild expired blockhashes rather than
+editing signed data.
+
+### Bitcoin Ordinals
+
+A Bitcoin collection is normally an indexer-recognized group of inscriptions, not a
+collection smart contract. Build:
+
+- canonical collection metadata and provenance manifest
+- parent inscription plan
+- child inscription relationships when supported
+- exact content type and content hash for every item
+- deterministic inscription order
+- commit and reveal PSBT plan
+- postage, fee rate, reveal destinations, and recovery addresses
+
+Protect commit UTXOs from accidental spends. Account for fee changes, reorgs,
+inscription ordering, and cursed/unbound outcomes. Do not promise stable inscription
+numbers before confirmation. Collection listing with an indexer or marketplace is a
+separate side effect after confirmed inscription IDs exist.
+
+### Cosmos
+
+First identify the target's actual NFT primitive. CW721, a chain-native NFT module,
+and an EVM runtime are not interchangeable.
+
+For CW721, verify the exact code artifact, checksum, instantiate message, minter,
+metadata extension schema, royalty extension if any, migration admin, and chain gas
+model. For a native module, verify current protobuf messages and authority behavior
+from the running chain version. Use the EVM path only for a proven EVM runtime.
+
+### Sui
+
+Model collection, item objects, treasury or publisher capabilities, display
+metadata, transfer policy, royalties/kiosk behavior, package upgrade policy, and
+shared versus owned objects. Test package publish, collection creation, mint,
+transfer, and authority transfer on testnet before any mainnet prepare.
+
+### Aptos
+
+Use the current Digital Asset or chain-native collection standard verified against
+the target network. Define collection mutability, token mutability, mint refs,
+burn/transfer refs, royalty data, supply caps, and module upgrade policy. Publish and
+exercise the lifecycle on testnet first.
+
+### Hyperliquid
+
+HyperEVM NFT launches use the EVM path. Do not assume Hyperliquid L1 has a generic
+NFT collection primitive because HyperCore supports spot, perps, staking, or outcome
+markets. Without a verified official L1 standard and adapter, mark it `UNSUPPORTED`.
+
+## 5. Mint phases and randomness
+
+For allowlists:
+
+- bind proofs to chain, contract/program, phase, wallet, allowance, price, and expiry
+- publish the snapshot method and Merkle root
+- prevent proof reuse across phases or contracts
+- test wallet caps across allowlist and public phases together
+
+For delayed reveal or randomized assignment:
+
+- commit the final provenance before mint
+- do not use timestamp, recent block hash, predictable block fields, or validator
+  discretion as sole randomness
+- use a verified randomness source or a deterministic disclosed assignment
+- show who can trigger reveal and whether they can reroll
+- publish gacha odds when rarity is randomized
+
+Load `oracle-nft-gacha-launch` for packs, loot boxes, or paid random outcomes.
+
+## 6. Marketplace and launch-page setup
+
+Marketplace listing is not deployment. Only prepare it after contract/program or
+inscription identifiers are final.
+
+Before a mint page can claim ready:
+
+- wallet and network switching work
+- contract/program and payment destinations are exact
+- total and per-wallet cost include gas/fees
+- sold-out and phase transitions read chain state
+- failed/rejected transactions surface clearly
+- mint count cannot exceed the approved cap
+- metadata preview comes from the pinned manifest
+- no private key or seed phrase is requested
+
+Never fabricate floor price, bids, volume, rarity, or sold count.
+
+## 7. Required artifacts
+
+A completed prepare run returns:
+
+1. `collection-manifest.yaml`
+2. ordered metadata/media checksums and provenance root
+3. rights/license statement
+4. authority and mutability table
+5. source/package hash and dependency lock
+6. test and static-analysis results
+7. target-chain simulation or an explicit missing-capability note
+8. fee, rent, postage, and treasury estimate as applicable
+9. ordered unsigned transaction or PSBT bundle with payload hashes
+10. source/program verification payload
+11. separate metadata upload, marketplace, reveal, and authority-revoke actions
+12. final user approval checklist, one side effect per line
+
+Do not emit signed transactions, private keys, seed phrases, keystore passwords, or
+broadcast commands with signing enabled.
+
+## Refusals
+
+Refuse stolen media, hidden supply, owner-only rerolls, fake randomness, metadata
+rugs, undisclosed upgrades, wash trading, fake floor/volume, deceptive rarity,
+royalty claims presented as guaranteed, and wallet-draining mint pages.
+
+## Completion gate
+
+A collection is only `PREPARED` when:
+
+- chain and standard are exact
+- support status is honest
+- supply matches metadata
+- rights and storage are explicit
+- all authorities and mutable fields are disclosed
+- tests pass
+- simulation passes or the missing capability is explicit
+- every destination and payload hash is recorded
+- no signing, upload, marketplace listing, or broadcast occurred without separate
+  user approval
+
+Anything less is `DRAFT`, `RESEARCH_ONLY`, or `UNSUPPORTED`.