@oracle-agent/oracle 0.11.0 → 0.13.0

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

@@ -1,57 +0,0 @@
----
-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

@@ -1,56 +0,0 @@
----
-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

@@ -1,73 +0,0 @@
----
-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

@@ -1,338 +0,0 @@
----
-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`.