Skip to main content

Goldsky

RPC and indexed data for a payments blockchain

Talk to our team

What is RPC and indexed data for a payments blockchain?

RPC and indexed data for a payments blockchain is the data access a payments company arranges for a chain it runs, also called a stablecoin chain.

The operator needs it twice over: partners and app builders need RPC and queryable data to build on the chain, and the operator’s own finance and operations teams need every payment in the systems that book it.

Goldsky serves RPC through Edge RPC, decodes events into the operator’s database with Turbo Pipelines and hosts subgraphs for partners, while the operator runs the chain, its ledger and its partner program.

You can provide RPC and indexed data for a fintech chain two ways: serve RPC, stream payments to your back office and host subgraphs for partners, or serve RPC and stream everything into your own database behind your own partner API.

Who uses RPC and indexed data for a payments blockchain?

Payments companies, stablecoin issuers and brokerages that run their own chain for settlement and want partners building on it.

How a fintech chain serves its partners and its back office

The diagram follows payments from settling on the fintech’s chain to the operator’s back office booking them and partners building apps on the same data. Your setup may differ.

Blockchains, step 1: Payments settleTransactions settle on your chain
Goldsky, step 2: EdgeServe RPCArchive RPC for your apps and partners
Goldsky, step 3: TurboStream to your databaseDecoded payments land in your own tables
Goldsky, step 4: SubgraphsHost partner APIsBuilders query indexed chain data
Your business, step 5: Run your back officeYour systems book each payment
Your business, step 6: Partners build on itApps launch on your chain
  • Goldsky

Ways to provide RPC and indexed data for a fintech chain

Partners index their own contracts in hosted subgraphs one way; the other way, they call an API your team runs on its own copy of the chain.

Usual setupOption 1: RPC and hosted subgraphs
Best for
An operator that wants partners to index their own contracts
Products
EdgeTurboSubgraphs
What you run
Your own client code
What you write
JSON-RPC calls, and the decoding of what comes back
Where your data lives
Read from the chain
How results reach you
Returned when you call
Option 2: RPC and your own database
Best for
An operator that owns all indexed data and its partner API
Products
EdgeTurbo
What you run
The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
What you write
Pipeline YAML and SQL; TypeScript transforms when needed
Where your data lives
In your own database or systems
How results reach you
Pushed to you

Option 1: Provide RPC and indexed data for a fintech chain with hosted subgraphs

Edge RPC serves the chain to your apps and partners, a pipeline decodes payments into your own database, and partners deploy subgraphs for the indexed APIs their apps need.

When to serve partners with hosted subgraphs

You want partners building on the chain without waiting on your team, each with an indexed API for their own contracts.

What you’ll need

  • Goldsky Edge
  • Goldsky Turbo
  • Goldsky Subgraphs
  • A running chain with at least one archive node
  • A database your back office reads from
  • The contract ABIs for the payment events you book
  • A ledger or back-office system that books each payment

  1. Settle payments on your chain

    The chain is where payments between your customers and partners become final, so it’s the source every other record follows.

    Each payment is recorded in a block, and for a short time the newest blocks can still be replaced. Your back office and your partners both need to treat a payment as final only once your chain’s finality rule says so.

  2. Serve RPC to your apps and partners

    Handled by Goldsky Edge

    Wallets, partner apps and your own services read balances and send payments through RPC.

    The endpoint has to serve current and historical blocks and stay up when a node fails. If it goes down, partners’ apps stop showing balances and their customers call your support line.

    Edge RPC serves your chain with automatic failover across upstream nodes and cross-checks responses so stale or partial data doesn’t reach apps.

    How Edge RPC handles failover (opens in a new tab)

  3. Decode payments into your database

    Handled by Goldsky Turbo

    Your finance and operations teams need each payment as a row with a sender, recipient, amount and reference, not as raw chain logs.

    The payment contracts’ events have to be decoded with their ABI (the contract’s description of its events) and written to tables your back office reads. Whether you do this is your choice, and if you skip it, someone has to rebuild payments from raw logs before they can be booked.

    With Goldsky, a Turbo Pipelines SQL transform can decode your contracts’ events from raw logs using their ABI and write each payment to your database, keyed on a primary_key so reorg corrections update the same rows.

    Decode contract events with an ABI (opens in a new tab)

  4. Host indexed APIs for partners

    Handled by Goldsky Subgraphs

    Partners building on the chain need their own contracts’ data in a form their apps can query.

    Each partner deploys a subgraph (a schema plus code that turns events into records) and gets a GraphQL endpoint for it. Without hosted indexing, every partner has to run a node and an indexer before they can launch.

    Subgraphs supports custom EVM chains, so partners can deploy subgraphs to your chain and query them over GraphQL, with webhooks available for entity changes.

    How Subgraphs index a chain (opens in a new tab)

  5. Book each payment in your back office

    A payment on the chain is only done for your business once your ledger shows it against the right account.

    Your systems match each decoded payment to a customer account and post it once. Matching is a join in your own database, and a payment booked before it’s final can need reversing.

  6. Bring partners onto the chain

    Partners decide whether to build partly on how fast they can read the chain.

    Publish the RPC URL, chain ID and how to deploy a subgraph in your partner docs. Partners then launch apps that read from the same chain your back office books.

What to know about serving partners with hosted subgraphs

  • Goldsky runs the RPC layer and hosts partners’ subgraphs; you run the chain, your database and your ledger.
  • Partners write and deploy their own subgraphs, so their APIs match their contracts.
  • Whether your back office takes a payment stream is your choice; the RPC and subgraphs work without it.

Option 2: Provide RPC and indexed data for a fintech chain by streaming to your own database

Edge RPC serves the chain, and a pipeline backfills and streams the chain into a database you own, which feeds both your back office and an API your team runs for partners.

When to stream a fintech chain into your own database

You want one copy of the chain’s data, held in your own systems, feeding both your ledger and the API partners call.

What you’ll need

  • Goldsky Edge
  • Goldsky Turbo
  • A running chain with at least one archive node
  • A database or warehouse you run
  • A ledger or back-office system that books each payment
  • A partner API your team builds and runs

  1. Settle payments on your chain

    The chain is where payments become final, so every other record follows it.

    Each payment is recorded in a block, and the newest blocks can still be replaced for a short time. Your systems treat a payment as final only once your chain’s finality rule says so.

  2. Serve RPC to your apps and partners

    Handled by Goldsky Edge

    Wallets, partner apps and your own services read balances and send payments through RPC.

    The endpoint has to serve current and historical blocks and stay up when a node fails. If it goes down, partners’ apps stop showing balances.

    Goldsky’s Edge RPC serves your chain with automatic failover across upstream nodes and routes historical requests to archive nodes.

    What Edge RPC serves (opens in a new tab)

  3. Backfill the chain into your database

    Handled by Goldsky Turbo

    Your ledger and your partner API both need the chain’s history since launch, not only new payments.

    The backfill starts at the first block and needs an archive node behind it. A gap shows up later as payments your ledger never saw.

    A Turbo Pipelines job with an Edge EVM source can read your chain from start_at: earliest to a fixed end_at block and write it to your database, then exit.

    Backfill any EVM chain (opens in a new tab)

  4. Stream new payments as they settle

    Handled by Goldsky Turbo

    After the backfill, every new payment has to reach your tables while it’s still useful to the back office.

    Events have to be decoded into payment rows and corrected when a reorg replaces a block. If corrections aren’t applied, the back office books payments that no longer exist.

    Turbo Pipelines can keep a pipeline streaming decoded events into the same tables, and passes reorg corrections through as updates and deletes to sinks with a primary_key.

    How reorgs reach your tables (opens in a new tab)

  5. Book each payment in your back office

    A payment on the chain is only done for your business once your ledger shows it against the right account.

    Your systems match each payment row to a customer account and post it once. Matching is a join in your database, and a payment booked before it’s final can need reversing.

  6. Serve partners from your own API

    Partners need indexed data for their apps, and in this setup it comes from the tables you already hold.

    Your team builds the API, decides what partners can query and keeps it running under their traffic. Partners then launch apps that read from the same data your back office books.

What to know about streaming a fintech chain into your database

  • You own the tables and the partner API, and your team runs that API.
  • One copy of the data feeds both the back office and partners, so both see the same payments.
  • Tables with a primary key take reorg corrections as updates and deletes; a queue or webhook consumer has to apply correction records itself.

What you control

Your team
  • Book each payment in your back office
  • Bring partners onto the chain

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

More use cases that access chains reliably

Use cases built the same way

Provide RPC and indexed data for a fintech chain with Goldsky

We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.

Talk to our team

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status