DEV Community: Beduil Dauis

Skip the Node — A Developer's Quickstart for Kaspa with Crypto APIs

Beduil Dauis — Mon, 27 Apr 2026 15:51:58 +0000

One REST endpoint and signed webhooks for Kaspa — Node.js and Python examples inside.

Kaspa is a proof-of-work Layer 1 with one-second block times and BlockDAG (GHOSTDAG) consensus. It is fast, settled in seconds, and very developer-friendly — once you have access to a node. Running your own kaspad node, keeping it in sync, indexing transactions, and turning that into a clean payment flow is real work that distracts you from shipping product.

Crypto APIs now supports Kaspa mainnet behind a single REST API, with signed webhooks for incoming, outgoing, and confirmed transactions. No node, no indexer, no infra to babysit.

This post is a copy-paste quickstart for the two flows most teams actually need on day one: tracking an incoming Kaspa payment, and a minimal wallet backend that lists balances and recent activity for a user.

Why skip the node

A self-hosted Kaspa stack means a kaspad node, a separate indexer for address and transaction lookups, a queue for reorg-safe confirmations, an HTTPS service to expose data to your app, and an on-call rotation when blocks slow down or peers misbehave. With Crypto APIs you call one HTTPS endpoint and you're done. Free tier is enough to start; you upgrade when traffic grows.

What you get on Kaspa via Crypto APIs:

Address details and balances
Transaction history per address
Latest block and block-by-height lookups
Fee recommendations
Broadcast of pre-signed raw transactions
Signed webhooks for new confirmed and unconfirmed coin transactions

All endpoints are documented at developers.cryptoapis.io.

Flow 1: track an incoming Kaspa payment with a webhook

When a user is paying you in KAS, you do not want to poll. Subscribe a webhook to the receiving address once and Crypto APIs will POST to your callback URL when a transaction confirms. The payload is signed via your callbackSecretKey, so you can verify it came from Crypto APIs and not a spoofer.

Before going live, register and verify your callback domain in the Crypto APIs dashboard (see Callbacks in the docs). Otherwise the subscription will not deliver.

Node.js example to subscribe an address to "new confirmed coin transactions":

import fetch from 'node-fetch';

const API_KEY = process.env.CRYPTOAPIS_KEY;
const HOST = 'https://rest.cryptoapis.io';
const URL = `${HOST}/blockchain-events/kaspa/mainnet/address-coins-transactions-confirmed`;

async function subscribeIncoming(address, callbackUrl) {
  const res = await fetch(URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json', 'x-api-key': API_KEY },
    body: JSON.stringify({
      context: 'order-1234',
      data: {
        item: {
          address,
          allowDuplicates: false,
          callbackSecretKey: 'whsec_replace_me',
          callbackUrl
        }
      }
    })
  });
  return res.json();
}

subscribeIncoming(
  'kaspa:qr...your-address...',
  'https://api.example.com/webhooks/kaspa'
).then(console.log);

When a payment to that address gets confirmed in a block, your endpoint receives a JSON body with eventType: ADDRESS_COINS_TRANSACTION_CONFIRMED plus the address, txid, amount and confirmation count. Verify the signature with the callbackSecretKey you set, mark the order as paid, and you're done. No polling, no missed transactions on reorgs.

Flow 2: a minimal wallet backend in Python

For a wallet UI you typically need balance and recent transactions for an address. Two endpoints, no node.

import os, requests

API_KEY = os.environ['CRYPTOAPIS_KEY']
HOST = 'https://rest.cryptoapis.io'
HEADERS = {'x-api-key': API_KEY}

def get_balance(address, network='mainnet'):
    url = f"{HOST}/addresses-latest/kaspa/{network}/{address}/balance"
    r = requests.get(url, headers=HEADERS)
    r.raise_for_status()
    return r.json()['data']['item']

def list_txs(address, network='mainnet', limit=20):
    url = f"{HOST}/addresses-latest/kaspa/{network}/{address}/transactions"
    r = requests.get(url, headers=HEADERS, params={'limit': limit})
    r.raise_for_status()
    return r.json()['data']['items']

addr = 'kaspa:qr...your-address...'
print(get_balance(addr))
for tx in list_txs(addr):
    print(tx.get('transactionId'), tx.get('minedInBlockHeight'))

That is enough to render a Kaspa wallet screen. Add fee recommendations and broadcast endpoints when you start sending KAS, and webhooks when you want push instead of pull.

What about sending KAS?

Signing transactions stays in your control — keys never leave your environment, which is how it should be. Crypto APIs gives you the inputs you need and a broadcast endpoint to relay your signed raw transaction to the Kaspa network. You keep custody and security; we handle the network plumbing.

Get started

Grab a free API key at cryptoapis.io, browse the full Kaspa reference at developers.cryptoapis.io, and you have Kaspa indexing and webhooks running in well under an hour. We are actively prioritising the next round of Kaspa endpoints based on developer feedback — if there is something you need that is not there yet, tell us.

Originally published at cryptoapis.io.

Give Your AI Agent Blockchain Superpowers — CryptoAPIs MCP Servers Are Live

Beduil Dauis — Fri, 20 Mar 2026 13:12:08 +0000

Imagine asking your AI assistant: "Has this wallet received any transactions in the last 24 hours?" — and getting an accurate, real-time answer in seconds, with zero integration code.

That works today. Here's how.

The problem with AI agents and blockchain data

If you've tried to give an AI agent access to live on-chain data, you know the friction. You write a custom tool, wrap your API calls, handle chain-specific quirks, manage authentication, and by the time your agent can query a wallet balance, check a transaction, and estimate gas, you're maintaining a sprawling set of connectors.

Model Context Protocol (MCP) — the open standard now adopted by Anthropic, OpenAI, Google, and Microsoft — eliminates that. It's the layer that lets AI models discover and call external tools without custom integration work. CryptoAPIs now has 14 purpose-built MCP servers that plug directly into that standard.

Getting started in 60 seconds

Every server runs with a single npx command. No cloning, no building. Add this to your Claude Desktop, Cursor, or Windsurf config:

{
  "mcpServers": {
    "cryptoapis": {
      "headers": {
        "x-api-key": "YOUR_API_KEY"
      },
      "type": "http",
      "url": "https://ai.cryptoapis.io/mcp"
    }
  }
}

Your agent can now answer questions like:

"What's the current ETH balance of this address?"
"Show me all token transfers for this wallet in the last 7 days"
"What's the current gas fee for a standard EVM transfer?"
"Has this smart contract been called in the last hour?"

If you'd rather skip local setup entirely, connect directly to our remote endpoint:

{
  "mcpServers": {
    "cryptoapis": {
      "type": "http",
      "url": "https://ai.cryptoapis.io/mcp",
      "headers": {
        "x-api-key": "YOUR_API_KEY"
      }
    }
  }
}

One endpoint. All 50 tools. All 14 server packages. Works with any MCP-compatible client.

The 14 servers — organized by what you're actually building

Rather than listing them alphabetically, here's how they map to real workflows:

Querying on-chain state

mcp-address-latest — current balances, nonces, token holdings, and recent transactions across EVM, UTXO, Solana, XRP, and Kaspa
mcp-address-history — sync addresses for continuous tracking and retrieve the complete transaction and token transfer history
mcp-block-data — blocks by height or hash, latest mined block, transactions within a block
mcp-transactions-data — full transaction details, internal transactions, token transfers, and logs

Building and executing transactions

mcp-blockchain-fees — fee recommendations, EIP-1559 estimates, gas estimation for transfers and contract interactions
mcp-simulate — dry-run EVM transactions before broadcasting. See exact outcomes, gas usage, and state changes before spending anything
mcp-prepare-transactions — build unsigned EVM transactions (native coin, ERC-20, ERC-721) ready for signing
mcp-signer — sign locally using your private key. No API calls made, keys never leave your machine
mcp-broadcast — submit signed raw transactions to the network

Market and contract data

mcp-market-data — real-time asset prices and exchange rates between any pair
mcp-contracts — smart contract ABIs and token data from EVM and Solana

Wallet and event management

mcp-hd-wallet — HD wallet management via xPub: sync, derive addresses, retrieve balances and transaction history across EVM, UTXO, and XRP
mcp-blockchain-events — create webhook subscriptions for on-chain events: confirmed transactions, new blocks, token transfers, custom confirmation counts
mcp-utils — address derivation, validation, raw transaction decoding across EVM, UTXO, and XRP

Why the remote vs. local split matters

For most AI agent use cases — querying data, monitoring wallets, checking fees — the remote endpoint at ai.cryptoapis.io/mcp is the right choice. Fast to connect, no local process to manage.

For transaction signing, the local mcp-signer exists for a reason: your private keys should never travel over the network. In a production custody or trading context, you'd combine both — remote for all data queries, local signer for transaction execution. Your keys stay on your infrastructure. Your agent retains full capabilities.

If you only need a subset of tools, the remote server also supports product-scoped endpoints — for example, https://ai.cryptoapis.io/mcp/address-latest exposes only address balance tools, which means faster session initialization and a smaller context window for your AI client.

Chains supported

EVM — Ethereum, Ethereum Classic, BSC, Polygon, Avalanche C-Chain, Tron, Arbitrum, Base, Optimism
UTXO — Bitcoin, Bitcoin Cash, Litecoin, Dogecoin, Dash, Zcash
Other — XRP, Solana, Kaspa
Mainnet and testnet support available.

Full documentation

Complete install instructions, configuration examples for every MCP client, the full tool reference, and HTTP transport setup are in the official docs:
https://developers.cryptoapis.io/v-2.2024-12-12-175/RESTapis/ai-compatibility/mcp-servers

All 14 servers are open source, published on npm under @cryptoapis-io, and compatible with Claude, Cursor, Windsurf, n8n, and any MCP-compatible host.

Get your API key at cryptoapis.io and let us know what you're building.

Originally published at cryptoapis.io