Story RPC: Querying the Chain Where IP Is a Protocol Primitive

Story is the chain that treats intellectual property as a first-class protocol object — not a metadata convention, but registration, licensing terms, and royalty flows implemented as on-chain modules. It launched mainnet (codename Homer) in February 2025, raised an a16z-led $80M Series B on the thesis, and has become the default answer to "how do we license training data and creative work on-chain?" For a developer, the good news is that all of this novelty sits behind a completely standard interface: chain ID 1514, ordinary eth_* JSON-RPC, Solidity, viem/ethers unchanged. Here's the map.

The essentials

Story mainnet is chain ID 1514, an EVM Layer 1 with an unusual construction:

• CometBFT consensus underneath, EVM execution on top. Story is built with the Cosmos SDK; validators run CometBFT proof-of-stake while the execution layer speaks EVM. You never touch the Cosmos side for normal work — no abci_query, no Tendermint RPC — it's the same "Cosmos engine, EVM cockpit" arrangement we covered on Kaia and Sei.
• ~2–3 second blocks with single-block BFT finality. A committed block is final. There are no reorgs to defend against — the entire reorg-handling playbook reduces to "confirm once." Index at the tip with confidence.
• IP is the native token (18 decimals): gas, staking, governance.

Connecting is one line:

import { createPublicClient, http, defineChain } from "viem";

const story = defineChain({
  id: 1514,
  name: "Story",
  nativeCurrency: { name: "IP", symbol: "IP", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/story?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: story, transport: http() });
await client.getBlockNumber();   // just works

What makes Story different: the IP graph

Story's reason to exist is its Proof-of-Creativity protocol — a set of smart-contract modules that turn IP into structured, composable on-chain state:

• IP Assets — a registered work (an image, song, character, dataset) is an NFT wrapped in an "IP Account" (an ERC-6551-style container holding its metadata and permissions).
• License modules — programmable license terms attached to an IP Asset: commercial use allowed or not, derivatives allowed or not, royalty percentage, territory. Licenses are minted as tokens against the parent IP.
• Royalty modules — revenue flows back up the derivative tree automatically: a remix owes its parent, which may owe its parent.
• Dispute modules — on-chain challenges to improperly registered IP.

The consequence for a developer: the IP graph is just contract state. Who owns this asset? eth_call. What license terms does it carry? eth_call. Every registration, license mint, and royalty payment? Events — eth_getLogs, filtered by the module contracts' addresses and event signatures, exactly like indexing a DEX. If you've built anything against a lending protocol or an NFT marketplace, you already know how to build against Story; only the domain objects are new (works and licenses instead of pools and loans).

Two practical notes for indexers:

• Derivative trees are deep reads. Answering "what does this remix ultimately owe?" means walking parent links up the graph — batch your eth_calls (JSON-RPC batching) or index the registration events into your own graph store and traverse locally.
• Registration bursts look like mint bursts. Story's traffic profile is registration- and license-event heavy — the same eth_getLogs range-cap discipline applies here as on any high-event chain (page your ranges; see How eth_getLogs range caps bite).

The AI angle (why traffic is growing)

The loudest use case in 2026: AI training-data licensing. Teams register datasets and creative catalogs as IP Assets, attach machine-readable license terms, and let agents or training pipelines mint licenses programmatically — royalties enforced by the chain rather than a PDF. Whether you're building on that thesis or just serving users who are, it changes the RPC workload: lots of automated eth_call license lookups and event tailing from services, not just wallet traffic from humans. Plan for steady programmatic read volume.

What carries over unchanged

• eth_call, eth_getLogs, eth_getBalance, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe — all standard.
• Solidity contracts, ABIs, foundry/hardhat deploy as-is; EIP-1559-style fees; MetaMask connects with chain ID 1514.
• WebSocket subscriptions for newHeads and logs — at 2–3s blocks with instant finality, streaming beats polling.

The one habit to drop is confirmation counting: CometBFT finality means block N committed is block N settled. Code written for probabilistic chains that waits 12 confirmations is just adding 30 seconds of pointless latency here.

The short version

Story (chain ID 1514) is an EVM L1 where IP registration, licensing, and royalties are protocol modules — an "IP graph" you query with ordinary eth_call and index with ordinary eth_getLogs. Underneath it's Cosmos SDK + CometBFT: ~2–3s blocks, single-block finality, no reorgs, with the IP token (18 decimals) for gas. viem/ethers/foundry work unchanged; the traffic profile skews toward programmatic license reads and event indexing, especially from the AI-licensing wave.

Building an IP-aware app, a dataset marketplace, or an agent that licenses content on the fly? A flat-rate Story RPC endpoint gives you chain 1514 alongside 75+ other networks under one key. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/story?key=YOUR_API_KEY