Alchemy Continuous Integration Gate

Overview

Gate Alchemy integration changes with deterministic unit, contract, fork, secret, and negative-path checks. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

CI should keep most provider behavior deterministic through fixtures and contract tests. A live read or pinned-chain fork is a separately labeled integration gate with a scoped non-production key, bounded usage, and an unavailable-provider policy. Pull-request testing never implies authorization to deploy or transact.

Authentication

Use a least-privilege CI environment secret with no write or wallet-signing authority. Prevent fork-origin workflows from receiving repository secrets and scan logs, artifacts, bundles, source maps, and built assets for canaries.

Instructions

1. Inventory unit, adapter-contract, fixture, fork, live-read, deployment, and transaction tests and assign each to a trust boundary.
2. Pin runtime and dependencies; validate fixtures against current documented schemas without requiring live credentials for ordinary pull requests.
3. Run secret and deprecated-import gates, including a ban on new alchemy-sdk imports and credential-bearing endpoint literals.
4. Run a scoped live read or pinned-block fork only in an approved trusted context, assert chain identity, cap duration/usage, and retain a redacted receipt.
5. Keep testnet deployment or transaction simulation in a separate protected job with environment approval and no automatic production promotion.
6. Prove invalid-key, wrong-chain, provider-unavailable, rate-limited, partial-response, and secret-canary failures before making the gate required.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Repository/security owners approve secret-bearing CI contexts. Release owners approve protected deployment jobs. External fork pull requests never gain secrets solely because a maintainer runs tests.

Error Handling

Alchemy Error Classification and Recovery

Overview

Classify Alchemy authentication, JSON-RPC, Data API, throughput, and partial-response failures before applying bounded recovery. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Alchemy surfaces transport status, JSON-RPC error objects, product-specific errors, and—in Portfolio workflows—partial errors inside an HTTP 200 response. Recovery depends on idempotency and failure class. Current limits and method availability are account, product, network, and time dependent; static plan tables are not diagnostic authority.

Authentication

Collect only a credential fingerprint or key identifier, never the credential. Verify application state, network, allowlists, endpoint family, and credential class in the dashboard or approved inventory without copying secrets into commands or tickets.

Instructions

1. Capture timestamp, endpoint family, network, method, sanitized parameters, HTTP status, JSON-RPC code, response headers, request ID, attempt count, and affected SLO.
2. Classify the failure as local validation, authentication/policy, unsupported method/network, throughput/quota, provider transient, deterministic RPC rejection, partial response, or downstream parsing.
3. Reproduce with a synthetic or public fixture and the same environment class; compare current service status, feature support, and account usage.
4. Correct invalid inputs or routing without retry; honor retry guidance for transient or throughput failures within an idempotency-aware budget.
5. For partial success, retain successful partitions and retry only failed partitions using their documented fresh-request contract.
6. Verify recovery and the exhaustion path, redact the evidence bundle, and escalate persistent provider failures with the request ID.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Operations owns retry budgets and degraded behavior. Security owns credential incidents. Raising …

Alchemy Multi-Chain Portfolio Workflow

Overview

Design a multi-chain holdings workflow on Alchemy Portfolio APIs with explicit pagination, partial-failure, privacy, and reconciliation contracts. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Portfolio APIs aggregate fungible tokens and NFTs across requested networks. Multi-network fanout can return HTTP 200 while reporting error.partialErrors; failed networks can be absent from pagination. Therefore HTTP success is not completeness, and retries for failed networks begin as fresh bounded requests rather than continuing the successful-network cursor.

Authentication

Use an application API key appropriate to Portfolio APIs and keep it in the approved server boundary. Wallet addresses are personal or customer-linked data when the product context makes them identifiable; apply the declared notice, consent, retention, and logging policy.

Instructions

1. Define the supported network set, address source, freshness SLO, display currency, pagination limit, and completeness status shown to users.
2. Confirm every requested Portfolio network in current documentation and validate each address before provider access.
3. Call the appropriate Portfolio token or NFT endpoint through a response-validating adapter; retain the request's network set with the result.
4. Persist successful network pages and surface top-level error.partialErrors as named unavailable networks rather than dropping them.
5. Continue cursors only for successful result sets; retry each failed network as a fresh request within a bounded budget and reconcile without duplicating holdings.
6. Prove empty, partial, paginated, stale, and total-provider-failure states in the UI/API, then document cache invalidation and data deletion.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Product and privacy owners approve address collection and retention. Operations approves fresh…

Alchemy NFT Discovery and Contract Read Workflow

Overview

Build an NFT discovery workflow with Alchemy NFT API v3 and isolate typed on-chain reads through viem. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

NFT API responses, metadata availability, spam classification, pagination, and supported networks are endpoint-specific. NFT indexing is not chain finality, and cached media is not proof of ownership. Contract state reads use the declared viem chain and ABI; ownership-sensitive decisions require an explicit block/finality policy.

Authentication

Use a scoped application API key in the server boundary. Validate owner and contract addresses before lookup. Treat queried owner addresses, collections, and behavioral analytics under the product's privacy and retention policy.

Instructions

1. Choose owner discovery, collection enumeration, metadata lookup, or contract-state verification and confirm the endpoint's current chain support.
2. Define the response schema, spam/filter policy, metadata and media fallbacks, page-key handling, maximum pages, and freshness label.
3. Fetch through a narrow NFT API v3 adapter, validate every page, and retain provenance for cached versus original media without executing remote media content.
4. For on-chain verification, create a viem public client on the same declared chain, use a reviewed minimal ABI, and record the block context.
5. Reconcile indexer output with contract reads only where the product requires it; represent disagreement and reorganization risk explicitly.
6. Test empty, paginated, malformed metadata, spam-filtered, unsupported-chain, and indexer-versus-chain disagreement before release.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Product/privacy owners approve address use and analytics. Security approves remote-media handling and ABI/source provenance. Transactions, approvals, mints, or marketplace writes are outside this read-only workfl…

Alchemy Usage and Cost Governance

Overview

Govern Alchemy compute usage and spend with current account evidence, workload attribution, budgets, and reversible optimizations. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Alchemy pricing plans, included capacity, compute-unit costs, and elastic-demand terms are mutable. Cost decisions use the current account contract, current method-cost documentation, and observed usage—not embedded plan tables. Admin usage access requires an authorized Admin access key or dashboard owner.

Authentication

Treat billing, application attribution, and usage data as restricted operational data. Keep Admin access keys separate from application keys and never place usage exports or credentials in public repositories.

Instructions

1. Record the account, billing window, plan, approved budget, elastic-demand state, currency, owner, and dated source evidence.
2. Attribute observed usage by application, environment, method family, chain, traffic class, and release using the authorized dashboard or Admin usage interface.
3. Reconcile observed compute units and charges to the current contract; label estimates and unattributed usage explicitly.
4. Rank optimizations by correctness risk: remove duplicate calls, cache immutable data, bound pages, batch where documented, schedule background work, and reserve capacity for critical traffic.
5. Forecast base, burst, and failure/retry scenarios with ranges rather than a false point estimate; set budget alerts and an approved response owner.
6. Canary one change, compare cost and SLO deltas, preserve completeness, and roll back if savings depend on hidden errors or stale data.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Finance/budget owner approves plan, capacity, and elastic spend. Product approves freshness or degraded-mode tradeoffs. Security approves Admin API credential use.

Error Handling

• Do not quote…

Alchemy Redacted Diagnostic Bundle

Overview

Collect a deterministic, secret-safe Alchemy diagnostic bundle for triage and escalation. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

A useful diagnostic bundle captures configuration identity, endpoint class, chain, dependency locks, sanitized request and response envelopes, request IDs, timing, retry history, and status observations. It never contains API keys, Admin keys, Notify tokens, signing keys, private keys, raw customer payloads, or credential-bearing URLs.

Authentication

Use a redaction allowlist, not a blacklist. Replace embedded endpoint credentials with a stable one-way fingerprint only when policy permits correlation. Keep the unredacted source in its existing protected system rather than copying it into the bundle.

Instructions

1. Define the incident window, affected endpoint family, chain, environment, expected behavior, and authorized evidence recipients.
2. Inventory runtime, package lock, adapter version, configured chain ID, feature, deployment SHA, and key identifier without reading or exporting secret values.
3. Collect sanitized request/response shapes, HTTP and JSON-RPC status, selected safe headers, request IDs, duration, attempt count, and partial-error fields.
4. Add current Alchemy status, supported-chain/feature evidence, and account-usage observation from the authorized owner; distinguish observation from inference.
5. Scan the complete bundle for secret and personal-data canaries, manually review it, then hash the immutable artifact.
6. Reproduce once with a synthetic fixture where safe, attach the positive or failed receipt, and specify retention and deletion dates.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

The incident owner approves scope and recipients; security/privacy approve any potentially identifying evidence. Sending a bundle to Alchemy or another external party requires explicit disclosure approval.

Alchemy Deployment and Promotion Control

Overview

Deploy an Alchemy-backed service through environment-scoped credentials, chain assertions, canaries, and rollback gates. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Deployment artifacts are environment-neutral; credentials, application IDs, chain IDs, allowlists, webhook URLs, and account budgets are injected per environment. A health endpoint proves process health, while readiness must prove the intended chain and endpoint family without exposing credentials or creating a transaction.

Authentication

Bind separate development, staging, and production Alchemy credentials through the platform secret manager. Deployment identities may reference secrets but may not read their values unless runtime requires it. Wallet signers remain outside the read-service deploy boundary.

Instructions

1. Inventory artifact SHA, target environment, region, Alchemy application/key identifier, chain, endpoint families, limits, callbacks, and owners.
2. Verify the target chain and feature support and compare the environment manifest against staging; fail on reused credentials or ambiguous chain configuration.
3. Inject secrets by reference, deploy an immutable artifact, and scan build logs, source maps, configuration exports, and images for credential canaries.
4. Run a read-only readiness proof that asserts chain ID and endpoint behavior; separately test partial, rate-limited, and unavailable-provider states.
5. Canary a bounded traffic share while watching latency, error class, completeness, usage, spend, and callback health.
6. Promote only within approved thresholds; otherwise route back to the prior artifact and preserve the deployment and rollback receipts.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Release owns promotion; security owns secret and public-origin configuration; product/operations own degraded behavior and traffic thresholds. Production deployment…

Alchemy Read-Only Connectivity Proof

Overview

Build a minimal, reviewable Alchemy EVM read with viem and prove its network, authentication, and failure behavior. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

The current Ethereum quickstart uses viem. A successful eth_blockNumber proves endpoint connectivity only; it does not prove Enhanced API, NFT API, Portfolio, Wallet API, or Admin entitlement. Chain identity must be checked from the response context rather than assumed from an endpoint string.

Authentication

Use a development application key through the repository's approved server-side secret boundary. Never print the URL when it contains a credential. A browser proof requires the allowlist or short-lived-JWT protections documented in the approved threat model.

Instructions

1. Choose one supported EVM chain and verify its current endpoint and feature support in first-party documentation.
2. Install a repository-approved, pinned viem release and preserve the lockfile review; do not add alchemy-sdk.
3. Create a public client with the declared viem chain and an Alchemy HTTP transport supplied from the server secret boundary.
4. Read the chain ID and latest block number, assert that the chain ID equals the configured chain, and record only redacted timing and block evidence.
5. Exercise an invalid credential and a deliberately mismatched chain expectation so the proof demonstrates fail-closed behavior.
6. Return the source, lockfile, test output, and rollback change without making a transaction or requesting a signing key.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Read-only development proof needs the application owner's scoped key. Installing a dependency follows repository review. Any transaction, wallet connection, browser credential, or production call is outside this skill and requires separate approval.

Error Handling

Alchemy Installation and Authentication Intake

Overview

Select and prove the current Alchemy client, key type, network, and authentication boundary before integration work. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

The legacy alchemy-sdk JavaScript repository is archived and deprecated. New EVM reads use viem or direct documented HTTP APIs; transacting applications and Portfolio support use @alchemy/wallet-apis; Solana work uses Solana Web3.js. An application API key, an Admin access key, a Notify auth token, and a webhook signing key are different credentials and are not interchangeable.

Authentication

Prefer server-side request-header authentication for confidential workloads. A browser key is acceptable only when the current Alchemy guidance, explicit domain allowlists, least privilege, and the product threat model allow it; short-lived JWTs are the stronger frontend option. Store Admin, Notify, webhook, and signing credentials only in approved secret storage.

Instructions

1. Classify the requested capability as Node RPC, Data API, Portfolio, Wallet APIs, Notify management, webhook receipt, Admin usage, or Solana.
2. Confirm the required chain and feature in the live supported-chain and feature-support matrices; do not infer feature parity from RPC support.
3. Select viem, direct HTTP, @alchemy/wallet-apis, or Solana Web3.js from the capability—not from the archived SDK examples.
4. Create or identify a non-production application and a least-privilege key; separately identify any Admin access key or Notify token actually required.
5. Configure the credential through the repository's established secret mechanism and document whether requests use a server header, server URL, or approved restricted browser boundary.
6. Run one read-only chain-specific proof, record the redacted request shape and response, then document rotation, revocation, owner transfer, and environment separation.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deploymen…

Alchemy Deterministic Local Development Loop

Overview

Establish a deterministic local EVM development loop with pinned forks, synthetic fixtures, and bounded Alchemy usage. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

A remote mainnet fork is reproducible only when the chain, block number, dependency versions, and fixture state are pinned. It still consumes account-level throughput and can diverge when historical access, method support, or upstream state is unavailable. Alchemy Sandbox is a separate simulation option and must be evaluated against the required test semantics.

Authentication

Use a development-only app key from local secret injection. Never copy a production key or deployer private key into .env, task output, shell history, fixtures, or committed fork URLs.

Instructions

1. Inventory the project's current Hardhat, Foundry, Anvil, or other EVM test runner and preserve its existing commands.
2. Confirm the target chain and historical method support, then select and record a stable fork block with the business reason for changing it.
3. Inject a development Alchemy endpoint through the established local secret mechanism and ensure configuration fails clearly when it is absent.
4. Use synthetic accounts and deterministic impersonation or funded fixtures; never import a real user or production signer.
5. Run the smallest fork test, a clean-room rerun, and an offline/unit fallback; record request volume and wall time without claiming a universal benchmark.
6. Document how to advance the fork block, refresh fixtures, distinguish provider drift from code failure, and restore the prior block.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

The test owner approves the pinned state and fixture refresh. Security approves secret injection. Forking production state, using customer addresses, or funding a test signer requires data/security approval.

Error Handling

…

Alchemy Performance and Freshness Tuning

Overview

Tune Alchemy-backed reads with measured latency, cache semantics, batching, concurrency, and freshness SLOs. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Performance depends on endpoint family, chain, response size, pagination, account throughput, region, cache state, and application work. There is no universal latency or batch-size guarantee. Optimization must preserve chain context, finality, partial-error semantics, and the product's freshness contract.

Authentication

Telemetry may include key identifiers, wallet addresses, or request metadata; log only approved low-cardinality fields and never credential-bearing URLs or full user payloads.

Instructions

1. Define endpoint-specific latency, completeness, freshness, and cost SLOs plus the user-visible degraded state.
2. Measure an approved baseline by chain, method, payload/page size, cache state, and concurrency; record percentiles rather than a single average.
3. Remove duplicate calls, bound pagination, choose current batch endpoints only where their documented semantics match, and cap concurrency below the shared account budget.
4. Cache immutable block-scoped data longer than head-sensitive data; include chain, method, normalized parameters, block/finality context, and schema version in keys.
5. Propagate partial failures and staleness metadata through caches; never cache a degraded result as complete success.
6. Load-test the proposed envelope, compare against baseline, prove invalidation and rollback, then promote with telemetry and stop thresholds.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Product owns freshness and degraded UX; operations owns capacity and stop thresholds; privacy owns cached address data. Increasing spend or retention requires explicit approval.

Error Handling

• Do not optimize by dropping failed networks, pages, or assets without decla…

Alchemy Production Readiness Decision

Overview

Make an evidence-backed go or no-go decision for an Alchemy-backed production release. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Production readiness is a signed decision over a specific artifact, environment, Alchemy application, chain and feature set, account contract, data path, SLOs, and rollback. A passing connectivity check or testnet transaction does not authorize production traffic or wallet operations.

Authentication

Confirm owners and lifecycle for every application key, Admin key, Notify token, webhook signing key, and signer. Prove environment isolation, least privilege, rotation, revocation, log redaction, and break-glass access.

Instructions

1. Freeze the release SHA and enumerate Node, Data, Portfolio, Wallet, Notify, Admin, chain, address/data, and transaction surfaces in scope.
2. Recheck current first-party feature support, errors, throughput, pricing, and SDK/client guidance; record account-specific observations and dates.
3. Verify deterministic tests, contract fixtures, chain assertions, partial/pagination handling, bounded retries, idempotency, and provider-outage behavior.
4. Review secret, privacy, webhook, wallet-signer, dependency, artifact, and supply-chain evidence plus incident and key-rotation exercises.
5. Review capacity, budget, alerting, runbooks, service ownership, status-page dependency, deployment canary, stop thresholds, and tested rollback.
6. Record each gate as pass, fail, waived-by-owner with expiry, or not applicable; issue go only when blockers are resolved by named authorities.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Release, product, operations, security, privacy/data, and budget owners sign their scopes. A waiver names owner, risk, compensating control, expiry, and follow-up; this skill cannot self-approve.

Error Handling

• Missing evidence is a failed or unresolved gat…

Alchemy Throughput and Backpressure Control

Overview

Design account-aware Alchemy throttling, bounded retries, and admission control from observed throughput rather than stale plan constants. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Alchemy throughput is measured in compute units at the account level using a rolling ten-second token-bucket model. Method costs, plan allowances, and elastic behavior can change. A per-process requests-per-second limiter is therefore insufficient: control must use current account terms, method mix, shared consumers, response signals, and measured demand.

Authentication

Usage inspection requires the authorized dashboard owner or an Admin access key for the documented Admin API; an application key is not an Admin credential. Never export account usage or credential material into public logs.

Instructions

1. Inventory every workload sharing the account by method family, estimated current compute-unit cost, burst shape, priority, idempotency, and SLO.
2. Recheck current method costs, account throughput, plan terms, and elastic-demand behavior; record source date and observed tenant settings.
3. Create a shared admission budget across processes, reserve capacity for critical reads, and shed or defer background work before saturation.
4. Use concurrency limits plus bounded exponential backoff with jitter, honoring provider guidance and retrying only idempotent operations automatically.
5. Emit attempt count, queue time, response class, observed usage, and final disposition without logging credentials or full user payloads.
6. Load-test below, at, and above the approved envelope; prove recovery, exhausted-budget behavior, and rollback before changing production limits.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Operations approves admission and retry policy; product approves degraded behavior. Purchasing capacity, enabling elastic spend, or changing account limits re…

Alchemy Production Reference Architecture

Overview

Design a production Alchemy architecture with capability-specific adapters, explicit trust boundaries, partial-state semantics, and reversible operations. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Current architecture separates EVM RPC through viem, Data APIs through typed HTTP adapters, Wallet APIs v5 through a transaction-policy boundary, Notify intake through authenticated idempotent queues, and Admin usage through restricted operations tooling. No shared archived SDK client or credential should collapse these contracts.

Authentication

Model browser, edge, API, worker, webhook, Admin, and signer identities separately. Application keys may serve permitted reads; Admin access keys, Notify tokens, webhook signing keys, and wallet signing authority remain isolated by runtime, owner, and policy.

Instructions

1. Inventory user journeys, data ownership, chains, Node/Data/Portfolio/Wallet/Notify/Admin capabilities, writes, callbacks, SLOs, and regulatory constraints.
2. Draw trust and data-flow boundaries including browser access, server adapters, queue, cache, database, secret store, observability, signer, provider, and external metadata.
3. Define typed capability adapters with chain assertions, pagination, partial success, finality, idempotency, bounded retry, and unsupported-feature outcomes.
4. Keep read paths and transaction intent/signing paths separate; require simulation, policy, user consent, and audit receipts for writes.
5. Design account-wide backpressure, cache freshness, webhook acknowledgement/replay, provider outage, status reconciliation, privacy deletion, and cost controls.
6. Threat-model and failure-test the design, map owners and approvals, then document incremental rollout and rollback variants.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Architecture, security, product, operations, privacy/data, and budget owners approve t…

Alchemy Client and API Routing Patterns

Overview

Route Alchemy work to viem, direct Data APIs, Wallet APIs v5, or Solana Web3.js without reviving the archived SDK. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

There is no single current JavaScript Alchemy SDK for every product. EVM Node reads belong behind a viem transport adapter, Data APIs behind response-contract adapters, transacting applications behind Wallet APIs v5, and Solana behind Solana Web3.js. The archived alchemy-sdk is migration input, not a new architecture choice.

Authentication

Each adapter declares the credential it accepts and rejects other credential classes. Keep application keys, Admin access keys, Notify tokens, webhook signing keys, and wallet signing authority in separate types and secret paths.

Instructions

1. Inventory each existing call by capability, chain, runtime, side effect, data owner, and credential class.
2. Assign Node RPC calls to a typed viem public client and keep the configured chain adjacent to the transport.
3. Assign NFT, Transfers, Prices, Simulation, or Portfolio calls to a narrow HTTP adapter that validates the documented response and pagination contract.
4. Assign smart-wallet creation and transaction flows to the current Wallet APIs v5 surface; isolate signing policy from data reads.
5. Represent partial success, pagination, retryability, and unsupported-chain outcomes explicitly instead of returning null or an untyped provider exception.
6. Add contract fixtures for success and every documented failure class, then ban new alchemy-sdk imports with a focused repository test.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Architecture owns capability routing and adapter boundaries. Security owns credential types and signing policy. Replacing a production provider or transaction path requires a canary and rollback approval.

Error Handling

Alchemy Credential and Trust-Boundary Security

Overview

Analyze and secure Alchemy credentials, browser access, wallet authority, webhook verification, and untrusted chain data. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

An Alchemy application key identifies and limits provider access but is not a wallet private key. Frontend use is not categorically forbidden: current guidance supports explicit allowlists and recommends short-lived JWTs where appropriate. Admin keys, Notify tokens, webhook signing keys, and transaction signing authority remain server-side and separately controlled.

Authentication

Create a credential matrix covering application keys, access keys, Admin access, Notify management, webhook verification, and wallet signers. Assign owner, storage, runtime, scopes/allowlists, rotation, revocation, monitoring, and incident procedure to each.

Instructions

1. Map browser, edge, server, CI, webhook, admin, and wallet trust boundaries and the data crossing each boundary.
2. Choose server header auth for confidential workloads; if browser access is justified, apply exact allowlists or short-lived JWTs and test bypass conditions.
3. Validate chain IDs, addresses, block selectors, contract ABIs, method allowlists, response sizes, and remote NFT metadata before use.
4. Keep read clients separate from signers; require explicit transaction simulation, user intent, policy checks, and approval in a distinct workflow.
5. Verify Notify payloads against the raw body using HMAC-SHA256 and the per-webhook signing key before parsing or side effects.
6. Run source, artifact, log, browser-bundle, and configuration secret scans; exercise rotation and incident response before production.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Security approves browser keys, JWT issuers, secret stores, signing boundaries, and incident response. Wallet transactions, new allowlists, credential rotation, or revocation r…

Alchemy Archived SDK Migration

Overview

Migrate archived Alchemy JavaScript SDK integrations to current capability-specific clients with parity, canary, and rollback evidence. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

alchemy-sdk is deprecated and its repository is archived. Current migration targets are capability-specific: viem for JavaScript EVM RPC, direct documented Data API adapters, @alchemy/wallet-apis for transacting apps and Portfolio support, and Solana Web3.js for Solana. Wallet APIs v5 has a separate first-party migration guide.

Authentication

Inventory every credential the old client could access and grant each replacement adapter only its needed class. Do not let migration move secrets from a server boundary to browser code or merge read and signing authority.

Instructions

1. Freeze dependency locks and inventory every alchemy-sdk, alchemy-web3, endpoint, namespace, WebSocket, Notify, Data API, Wallet, and signer use by capability and side effect.
2. Route EVM RPC to viem, product HTTP calls to typed adapters, transacting/Portfolio use to Wallet APIs v5 where applicable, and Solana use to Solana Web3.js.
3. Define normalized parity contracts for values, pagination, partial errors, retryability, chain identity, subscriptions, and transaction intent; preserve raw evidence for differences.
4. Build fixtures and dual-read comparison for read-only paths; use simulation/testnet and explicit authorization for transaction paths.
5. Canary one capability at a time with stop thresholds and the old artifact still deployable; remove deprecated imports only after parity and negative paths pass.
6. Update runbooks, CI bans, lockfiles, observability, owners, and rollback; separately follow the current Wallet APIs v5 guide for v4 consumers.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

Architecture approves target routing; securit…

Alchemy Notify Webhook Operations

Overview

Operate Alchemy Notify webhooks with raw-body HMAC verification, idempotent intake, durable processing, and safe lifecycle changes. This workflow produces a reviewable artifact and negative-path evidence before any live side effect.

Prerequisites

• Current first-party Alchemy documentation for the selected product, chain, feature, client, authentication method, limit, and lifecycle.
• Named product, application, security, data/privacy, budget, release, and operations owners appropriate to the requested scope.
• Synthetic or approved non-production fixtures, a credential canary, explicit success criteria, and a tested rollback boundary.

Current Contract

Alchemy signs the exact raw request body with HMAC-SHA256 using the webhook's signing key and sends the digest in X-Alchemy-Signature. Notify management uses its documented auth token, not the signing key. Current docs describe automatic retries/backoff and ordered first-time delivery; consumers still need idempotency because duplicate processing and application retries remain possible.

Authentication

Keep the per-webhook signing key and Notify management token in separate managed secrets. The receiver may read the signing key only for verification; it may not create, update, or delete webhook registrations.

Instructions

1. Select the current webhook type and network from first-party support, define event semantics, confirmation policy, callback SLO, and data retention.
2. Create or modify the registration only through an approved management path; record webhook ID, redacted filter, owner, signing-key version, and rollback configuration.
3. Capture the raw request bytes before JSON parsing, compute HMAC-SHA256, and compare decoded equal-length values with a timing-safe function.
4. Persist the webhook and event identifiers atomically before acknowledging; enqueue work and return success without blocking on downstream side effects.
5. Make consumers idempotent, preserve per-entity ordering where required, and define reorganization, mined, dropped, and duplicate-event behavior.
6. Test valid, invalid, replayed, delayed, out-of-order, and downstream-failure cases; operate a bounded dead-letter replay with explicit approval.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, wallet addresses, customer data, plan changes, spend, key creation or rotation, webhook changes, deployment, replay, transaction construction, signing, broadcast, or deletion.

Approval Boundaries

The product owner approves event scope and user impact. Security approves callback exposure and sec…