Skip to main content

Goldsky

Stablecoin distributor revenue share

Talk to our team

What is stablecoin distributor revenue share?

Stablecoin distributor revenue share is paying the wallets, exchanges and apps that distribute your coin a share of its revenue, based on the holdings, mints and burns attributed to each distributor’s wallets on every chain; issuers also call it stablecoin revenue sharing.

Issuers and issuance platforms need that attribution to be exact and traceable, because each partner’s payment is calculated from it and partners check it against their own records.

Goldsky watches every distributor’s wallets, decodes their activity on every chain and streams it to your database, while matching wallets to distributors, the totals and the payout run stay with you.

You can build it two ways: stream every distributor wallet’s activity into your database with Turbo Pipelines, or call the Feeds balances and transfers APIs for each wallet when you run the numbers.

Who pays stablecoin distributor revenue share?

Stablecoin issuers, issuance platforms and wallets with their own coin that share revenue with the wallets, exchanges and apps that distribute it, including bank consortiums that plan one coin for many member banks.

How stablecoin holdings are attributed to distributors

The diagram follows one distributor from onboarding, when its wallets go on your watch list, to the revenue-share payout built from its holdings and activity. Your setup may differ.

Your business, step 1: Onboard a distributorIts wallets go on your watch list
Goldsky, step 2: TurboWatch its walletsAdded live, no redeploy
Blockchains, step 3: Holdings changeMints, burns and transfers through it
Goldsky, step 4: TurboSpot its activityEvery watched wallet, every chain
Your business, step 6: Total per distributorHoldings and flows, by chain
Goldsky, step 5: TurboStream to your databaseRows you join to each distributor
Your business, step 7: Pay revenue shareYour payout run uses the totals
  • Goldsky

Ways to attribute stablecoin holdings to distributors

The pipeline pushes every change in a watched wallet to your database as it happens; the balances and transfers APIs return data only when your code calls them, so holdings between calls come from readings you store.

Usual setupOption 1: Stream to your database
Best for
Many distributors and wallets, every change on record
Products
Turbo
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 2: Balances and transfers APIs
Best for
A short list of wallets, checked at set times
Products
Feeds
What you run
Nothing; you call an endpoint and keep what you need
What you write
REST requests
Where your data lives
Hosted by Goldsky
How results reach you
Returned when you call

Option 1: Attribute stablecoin holdings to distributors by streaming to your database

A pipeline watches every distributor wallet on your list, decodes its mints, burns and transfers of your coin on each chain and streams them, with the wallet’s balance after each change, to your database. You join the rows to distributors, total them and run the payout.

When to stream distributor wallet activity

You have many distributors with many wallets across chains, and payouts depend on holding time, so every balance change needs to be on record.

What you’ll need

  • Goldsky Turbo
  • Your coin’s contract address on each chain
  • Your list of distributor wallets, and which distributor owns each
  • A database
  • Your revenue-share terms and payout process

  1. Sign up the distributor and its wallets

    Activity can only be credited to a distributor once you know which wallets are theirs.

    The agreement sets the share rates and the wallets that count, and the wallet list has to stay current as the distributor adds wallets. A wallet missing from the list earns the distributor nothing, and a dispute follows.

  2. Add its wallets to the watch list

    Handled by Goldsky Turbo

    Only wallets on the list are followed, so each new wallet has to go on it.

    The list has to update as soon as a wallet is added, without stopping anything. A gap between signing up a wallet and watching it leaves its first activity unattributed.

    With Goldsky, the watch list can be a Turbo Pipelines dynamic table, which lives in a Postgres database; add a row and the running pipeline starts matching that wallet, with no redeploy.

    Watch wallets with dynamic tables (opens in a new tab)

  3. Move the coin through distributor wallets

    A distributor’s holdings change when coins are minted to, burned from or transferred in and out of its wallets, on any chain.

    Each chain records only its own activity. For a short time the newest blocks can still be rewritten, so a change seen once isn’t final yet.

  4. Catch every change in a watched wallet

    Handled by Goldsky Turbo

    Every mint, burn and transfer touching a watched wallet changes what that distributor is credited with.

    Each change needs its wallet, chain, amount, block and the wallet’s balance afterwards, so holding time can be worked out later. Reading balances on a timer misses the changes between reads.

    In Turbo Pipelines, a SQL transform keeps only transfers of your coin where the sender or recipient passes dynamic_table_check(), and _gs_eth_call reads that wallet’s balanceOf at the same block; UNION ALL combines the chains.

    Filter transfers against a watch list (opens in a new tab)

  5. Stream the activity to your database

    Handled by Goldsky Turbo

    Attribution is a join in your database, so the activity has to land there as rows.

    Each row needs a stable ID, because delivery can repeat after a restart and a transfer counted twice overpays a partner.

    Turbo Pipelines writes each row to a database table keyed on id, and passes reorg corrections through as updates and deletes to the same rows.

    Set up the Postgres sink (opens in a new tab)

  6. Total each distributor’s holdings and activity

    Revenue share is paid on each distributor’s totals: holdings over time, plus mints and burns, by chain.

    Join each row to its distributor through your wallet list, then work out holdings over the period the way the agreement defines them, such as each wallet’s balance at a set time every day or a time-weighted average. Keep the query and its inputs, because partners will ask how their figure was reached.

  7. Pay each distributor its revenue share

    The payout closes each period, and it’s the figure the distributor sees.

    Your payout run applies the agreed rates to each distributor’s totals and pays them, with a statement listing the figures behind the amount. A payment that can’t be traced to wallets and blocks is hard to defend in a dispute.

What to know about streaming distributor wallet activity

  • The watch list is a set of addresses; which distributor owns each wallet is a join in your database.
  • A wallet added to the list is picked up by the running pipeline without a redeploy.
  • Tables keyed on the row ID take reorg corrections as updates and deletes, so totals follow the chain.
  • Goldsky runs the pipeline; the totals, the share rates and the payout are yours.

Option 2: Attribute stablecoin holdings to distributors with balances and transfers APIs

Your code calls the Feeds balances and transfers endpoints for each distributor wallet when it runs the numbers, and gets back the wallet’s latest holdings and its transfers with token details. There’s no pipeline or database to set up on Goldsky.

When to use wallet balances and transfers APIs

You have a short list of distributor wallets and pay on balances checked at set times, not on every change in between.

What you’ll need

  • Goldsky Feeds
  • Your list of distributor wallets, and which distributor owns each
  • A scheduler for your attribution code
  • A database to store each reading
  • Your revenue-share terms and payout process

  1. Sign up the distributor and its wallets

    Activity can only be credited to a distributor once you know which wallets are theirs.

    The agreement sets the share rates and the wallets that count, and the wallet list has to stay current as the distributor adds wallets. A wallet missing from the list earns the distributor nothing, and a dispute follows.

  2. Keep the wallet list with each owner

    Your code needs to know which wallets to query and which distributor each one belongs to.

    Keep each wallet’s address, chains and distributor together. A wallet that’s in the API calls but not in this list returns figures nobody can credit.

  3. Move the coin through distributor wallets

    A distributor’s holdings change when coins are minted to, burned from or transferred in and out of its wallets, on any chain.

    Each chain records only its own activity. For a short time the newest blocks can still be rewritten, so a change seen once isn’t final yet.

  4. Read each wallet’s holdings

    Handled by Goldsky Feeds

    A distributor’s holdings are the coin balances in its wallets at the time you check.

    Read every wallet at the same times each period and store each reading, because only the latest balance comes back, not past ones. Gaps between readings become guesses in the payout.

    Goldsky’s Feeds balances endpoint returns a wallet’s latest token balances across the chains you request, with token metadata on each row.

    Read the balances endpoint reference (opens in a new tab)

  5. Read each wallet’s mints, burns and transfers

    Handled by Goldsky Feeds

    Some agreements pay on activity as well as holdings, and transfers fill in what happened between balance checks.

    Request the period since your last call so nothing is skipped, and store what comes back once, keyed on fields that identify each transfer, such as its transaction hash. A repeated call shouldn’t count the same transfer twice.

    The Feeds transfers endpoint returns a wallet’s transfers newest first; set from to the time of your last call, and include_unknown_price=true so your coin is included even if it has no market price.

    Read the transfers endpoint reference (opens in a new tab)

  6. Total each distributor’s holdings and activity

    Revenue share is paid on each distributor’s totals: holdings over time, plus mints and burns, by chain.

    Join each reading to its distributor through your wallet list, then work out holdings over the period from the stored readings and transfers, the way the agreement defines them. Wait until recent transfers are final before closing a period, since a reorg can remove one without notice.

  7. Pay each distributor its revenue share

    The payout closes each period, and it’s the figure the distributor sees.

    Your payout run applies the agreed rates to each distributor’s totals and pays them, with a statement listing the figures behind the amount. A payment that can’t be traced to wallets and blocks is hard to defend in a dispute.

What to know about attributing holdings with wallet APIs

  • Your code pulls, so holdings between calls are unknown unless you rebuild them from the transfers.
  • Balances come back as the latest figure, so holdings over time depend on how often you call and store them.
  • Waiting out reorgs is your job: a transfer undone by a reorg stops appearing in responses, with no flag to say so.
  • Each wallet is its own request, so the work grows with every wallet you add.

Related jobs

How to calculate partner payouts for stablecoin distributors

Turn attributed holdings and holding time into each distributor’s payout. Also called partner payouts or time-weighted average balance.

This runs on the attribution record above. A Compose task starts at the same cut-off every day, each distributor wallet’s balance at that moment is taken from the balances the pipeline keeps, and your SQL applies each distributor’s rate and adds the days up into a payout.

What you’ll need

  • Goldsky Turbo
  • Goldsky Compose
  • Your list of distributor wallets, with each one’s distributor and payout address
  • The revenue-share agreement: rates, the daily cut-off and the payout schedule
  • A database or warehouse for the daily figures
  • A custody provider that signs payouts under your approval policy

  1. Fix the payout terms

    A payout is a rate applied to a balance, so both sides have to agree on which balance, read when, and at what rate.

    Write down the daily cut-off and its time zone, each distributor’s rate (which can differ by chain or region), the day a new wallet starts earning and how often payouts run. A vague start date invites claims for days before a wallet was registered.

  2. Start the run at the cut-off

    Handled by Goldsky Compose

    Balances only compare fairly if they’re all taken at the same moment every day, weekends included.

    The run starts at the cut-off and pins the snapshot to the block at that moment, and the payout figures wait until that block is deep enough not to be rewritten. A run that starts late or skips a day leaves a gap someone has to fill by hand.

    A Compose task with a cron trigger starts at the time you set, and a six-field expression gives second-level timing for a cut-off such as one second before midnight.

    Run a task on a schedule (opens in a new tab)

  3. Snapshot every distributor wallet

    Handled by Goldsky Compose

    The day’s amount comes from what each wallet held at the cut-off, not from what it holds when someone checks later.

    Every registered wallet is read at the snapshot block on each chain, including wallets that held nothing that day. A wallet missing from the snapshot earns nothing for the day, and its distributor will notice.

    Goldsky’s Turbo Pipelines already writes each watched wallet’s balance after every change, so a wallet’s snapshot is its last row at or before the snapshot block. For a chain the pipeline doesn’t cover yet, the task can backfill that chain’s transfers up to the block with a Turbo job it starts through ctx.turbo.createJob.

    Start Turbo jobs from a task (opens in a new tab)

  4. Work out each distributor’s daily amount

    The payout is the sum of daily amounts, each one a distributor’s balance at the cut-off times its rate for that day.

    Join each wallet to its distributor, group the balances by chain and rate, apply the daily rate the agreement sets and store the result for every day. Never overwrite a past day; if a figure changes, keep the correction beside the original with its reason.

  5. Send each payout

    At the end of each period, the daily amounts become one payment per distributor.

    Your custody provider signs a payout for each distributor’s total to the payout address it registered on that chain, under your approval policy. Keep the transaction hash with the period, because it’s the proof the distributor was paid.

  6. Close the period with a statement

    Distributors check their payout against their own records, and finance books it.

    The statement lists the daily balances, the rate applied and each day’s amount, with the payout’s transaction hash. A payout nobody can trace back to balances and blocks is hard to defend in a dispute.

What you control

Your team
  • Sign up the distributor and its wallets
  • Total each distributor’s holdings and activity
  • Pay each distributor its revenue share

Security and deployment

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

Use cases built the same way

Run stablecoin distributor revenue share 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