Skip to main content

Goldsky

Rewards on stablecoin balances

Talk to our team

What are rewards on stablecoin balances?

Rewards on stablecoin balances are payments to customers based on how much of a stablecoin they hold over a period, run as a stablecoin rewards program.

Neobanks and fintechs with their own ledger offer them to keep customer balances with them, and every period someone has to fix who held what, apply the terms and pay each customer the right amount.

Goldsky runs the schedule, reads each wallet’s balance at the record block and sends each reward to your signer; the terms, the question of whether a program fits the rules where you operate, and the keys stay with you.

Who pays rewards on stablecoin balances?

Neobanks, consumer finance apps and fintechs with their own ledger that pay rewards to customers who hold stablecoins with them.

How rewards on stablecoin balances work

The diagram follows one reward period from setting its terms to the rewards landing in customers’ wallets. Your setup may differ.

Your business, step 1: Set the reward termsRate and accrual rules for the period
Goldsky, step 2: ComposeSnapshot the balancesA scheduled task picks the record block
Goldsky, step 3: EdgeRead balances at the blockEach customer wallet’s balance at that block
Your business, step 6: Wallet or custody providerSign the payoutsSigned under your approval policy
Goldsky, steps 4–5: ComposeCalculate and sendRate applied, each reward sent for signing
Goldsky, step 8: ComposeConfirm and closeEvery payment checked, totals matched
Blockchains, step 7: Rewards landCustomers see rewards in their balance
  • Goldsky
  • Your provider

How to pay rewards on stablecoin balances

A Compose task runs at the end of each period, reads every customer wallet’s balance at a record block through Edge RPC, applies your terms and sends each reward to your signer, logging every step.

What you’ll need

  • Goldsky Compose
  • Goldsky Edge
  • Legal advice on whether and how you can offer rewards
  • The funds for rewards, held in a payout wallet
  • A custody provider that can sign EIP-712 typed data and EIP-7702 authorizations, reached through a signing endpoint you host
  • A list of customer wallets in the program

  1. Set the reward terms

    Every reward is worked out from the same rules, so they have to be fixed before the period ends.

    Your team sets the rate, how balances are measured and which customers qualify, after legal review where you operate. Terms changed mid-period leave some customers paid on old rules.

  2. Fix the record block for the period

    Handled by Goldsky Compose

    Balances change all the time, so each period needs one agreed point to measure them at.

    Pick a block far enough behind the newest one that a reorg can’t replace it, and keep it with the period. Measuring at a block that later changes means paying on balances that never existed.

    With Goldsky Compose, a task on a cron trigger runs at the end of each period, picks the record block and keeps it with the run.

    Schedule a task with cron (opens in a new tab)

  3. Read each balance at the record block

    Handled by Goldsky Edge

    Each customer is rewarded on what their wallet held at the agreed point.

    Read every wallet’s token balance at that exact block, not the latest one. A wallet left out of the read gets nothing, and someone has to pay it by hand.

    Edge RPC answers eth_call at any block number you pass, so the task can call the token’s balanceOf for each wallet at the record block.

    Read the eth_call reference (opens in a new tab)

  4. Calculate each customer’s reward

    Handled by Goldsky Compose

    The terms turn each balance into an amount, and the amounts have to add back up to what you budgeted.

    Rounding has to be settled in the terms: round every reward down and leave the remainder unassigned, and money is left over; round up, and the payout runs short before the last customer.

    The task applies your terms in its own TypeScript code, so the formula lives in your repository and every input to it is logged on the run.

    How Compose logs each call (opens in a new tab)

  5. Send each reward for signing

    Handled by Goldsky Compose

    Each reward is a payment from your payout wallet, signed with a key you control.

    Each customer is paid once per period. A retry after a timeout or a restart must not pay anyone twice.

    Goldsky’s Compose webhook wallet sends the signing endpoint you host each payment as a UserOperation (the transaction format smart-account wallets use) to sign, plus a one-time EIP-7702 authorization the first time it sends on a chain, and submits it once signed; a payment that already landed isn’t sent again after a retry.

    Learn about webhook wallets (opens in a new tab)

  6. Sign the reward payments

    Most firms keep payout keys with a custody provider whose rules say who can approve what.

    Your signing endpoint holds the limits set before the run starts: it reads the recipient and amount from each reward’s call data, checks them, then asks your custody provider to sign. A run that exceeds your limits stops before money leaves.

  7. Deliver the rewards

    The reward is paid when it lands in the customer’s wallet and shows in their balance.

    Each payment sits in a block that a reorg can still replace for a short time. A payment that never confirms still counts as unpaid.

  8. Confirm every payment and close the period

    Handled by Goldsky Compose

    The period is closed when every customer owed a reward has been paid, and the record shows it.

    Check each payment confirmed, resend any that a reorg dropped, and compare the total paid with the total calculated. Customers left unpaid are followed up before the next period starts.

    Compose waits for the confirmations you set on each payment and resends it with the replay behavior if a reorg drops it, and the run keeps the full record.

    Handle confirmations and reorgs (opens in a new tab)

Related jobs

How to pass stablecoin rewards through to account holders

Receive the rewards a stablecoin program pays on the balances you hold for customers, and credit each customer their share.

A pipeline records each rewards payment that reaches your payout address in your database, next to your customer ledger. Your team checks it against the program’s statement, splits it among the customers whose balances earned it and credits their accounts.

What you’ll need

  • Goldsky Turbo
  • Legal advice on whether and how you can pass rewards on to customers
  • A rewards agreement with the stablecoin’s issuer or its program
  • The addresses of the wallets that hold customer stablecoins, and your payout address
  • A database beside your customer ledger

  1. Join the issuer’s rewards program

    The rewards come from the stablecoin’s issuer or its program, under an agreement that sets the rate and what counts.

    The agreement sets the rate, how often rewards are paid and which wallets count. Rewards accrue only on wallets you’ve registered with the program, from the day you register them, so a wallet added late earns nothing for the days before.

  2. Keep each customer’s daily balance

    The program pays on the total in your wallets, and each customer is owed in proportion to what they held.

    Your ledger records each customer’s stablecoin balance at the same daily cutoff the program uses. A ledger that measures at a different time splits rewards on balances that don’t match what the program counted.

  3. Receive the rewards payment

    The program pays what your wallets earned to the payout address you gave it, on the schedule it sets.

    Each payment arrives as a token transfer to your payout address. For a short time the chain can still replace its newest blocks (a reorg), so a payment seen once isn’t final yet.

  4. Record each payment to your payout address

    Handled by Goldsky Turbo

    Your team can only split a payment it knows has arrived.

    Every transfer into the payout address is recorded with its amount, token, sender and transaction hash, apart from customers’ own deposits. A payment recorded twice gets split twice.

    With Goldsky, your payout addresses can sit in a Turbo Pipelines dynamic table, which lives in a Postgres database, and the pipeline keeps only token transfers whose recipient is on it with dynamic_table_check(). A database sink keyed on the transfer’s id updates the same row if a payment is delivered again.

    Learn about dynamic tables (opens in a new tab)

  5. Check the payment against the program’s statement

    The amount paid should match what the program says your wallets earned for the period.

    Compare each payment with the rate and balances in the program’s statement for the same days. A gap means a wallet wasn’t registered, a balance was counted differently or a payment is still to come, and it’s settled before customers are credited.

  6. Credit each customer’s share

    Customers earn in proportion to what they held, after any fee you keep.

    Your ledger splits the payment across customers by their daily balances, takes off your fee if you charge one, and credits each account in the same stablecoin. Rounding is set in your terms, so the shares add back up to the payment.

What you control

Your team
  • Set the reward terms
Your providers
  • Wallet or custody provider

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 run stablecoin accounts and cards

Use cases built the same way

Pay rewards on stablecoin balances 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