Skip to main content

Goldsky

Stablecoin admin action log

Talk to our team

What is a stablecoin admin action log?

A stablecoin admin action log is a record of every privileged action taken on a token contract: each mint, burn, freeze, clawback and change to who holds an admin role, with when it happened and which address signed it.

Issuers and the platforms that run tokens for them keep one because risk teams and auditors ask who could move or block funds, and who did.

Goldsky decodes each action from the contract’s events into your warehouse and can flag role changes as they happen, while your team keeps the keys, the approval policy and the review.

You can keep the log two ways: stream decoded admin events into your own warehouse with Turbo Pipelines, or index them in a subgraph that Goldsky hosts, with a webhook on each new action.

Who keeps a stablecoin admin action log?

Stablecoin issuers, issuance platforms that run branded tokens for their clients, and tokenization platforms that manage permissioned tokens.

How a stablecoin admin action log works

The diagram follows one admin action from the signature that authorizes it to the audit review of the log, and shows who does each step. Your setup may differ.

Your business, steps 1–2: Admin signs an actionA mint, burn, freeze or role change
Blockchains, step 3: The contract emits itOne event per admin action
Goldsky, step 4: TurboDecode every actionFrom deployment onward, with its transaction
Your business, step 7: Review for auditSigner and approvals checked per action
Goldsky, step 5: TurboKeep the logEvery action in your warehouse
Goldsky, step 6: TurboFlag sensitive actionsRole changes sent to a webhook
  • Goldsky

Ways to keep a stablecoin admin action log

A pipeline writes every admin action into a warehouse you own, next to your other risk data; the subgraph keeps the log in a hosted index you query and pushes each new action to your endpoint.

Usual setupOption 1: Stream to your warehouse
Best for
Tokens on several chains, with the log beside your risk data
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: Hosted subgraph
Best for
One token on one chain, queried when needed
Products
Subgraphs
What you run
Nothing; Goldsky runs indexing, storage and the API
What you write
A schema and mapping handlers, or a no-code or low-code config for simple contracts
Where your data lives
Hosted by Goldsky
How results reach you
You query; changes are pushed

Option 1: Keep a stablecoin admin action log by streaming to your warehouse

A pipeline decodes every admin event the token contract has emitted since deployment and writes each one, with its block and transaction, to your warehouse. The same pipeline sends role changes to a webhook as they happen.

When to stream admin actions into your warehouse

Your risk and audit teams already work from a warehouse, the token runs on more than one chain, or you want the log next to your other compliance records.

What you’ll need

  • Goldsky Turbo
  • The token contract’s address and ABI on each chain
  • A warehouse or database for the log
  • An endpoint that receives role-change alerts
  • Your list of authorized admin addresses

  1. Decide who holds each admin role

    The log is only useful if you know who was allowed to take each action, so the roles come first.

    Write down which addresses can mint, burn, freeze, claw back or change roles, and which approvals each action needs. Without that list, a reviewer reading the log can see what happened but can’t tell whether it should have.

  2. Sign the admin action

    Every mint, freeze or role change starts with someone holding an admin key approving it.

    The action is signed under your approval policy, often by a multisig (a wallet that needs several approvers). If admin keys sit outside any policy, the log will record actions nobody signed off on.

  3. Record the action on the chain

    The token contract announces each admin action as an event, which is the evidence the log is built from.

    Each action emits one event with its block and transaction, and for a short time the newest blocks can still be replaced, so an action seen once isn’t final until enough blocks sit on top of it. On Tempo, a token’s transfer policy lives in the separate TIP-403 policy registry: the token emits TransferPolicyUpdate when its admin switches policy, and the registry emits WhitelistUpdated or BlacklistUpdated when a policy’s admin changes its list, so both contracts belong in the log.

  4. Decode every action since deployment

    Handled by Goldsky Turbo

    Events arrive encoded, and the log has to start from the token’s first day to show every action ever taken.

    Each event is turned into a named action with its parameters, block, time and transaction. The signer comes from the event itself where the contract records it, or from the transaction; a log that starts mid-life leaves early mints and role grants unexplained.

    With Goldsky, a Turbo Pipelines source can start at the contract’s first block with start_at: earliest and a filter on its address, and _gs_log_decode turns each raw log into a named event using the contract’s ABI.

    Decode logs with an ABI (opens in a new tab)

  5. Keep the log in your warehouse

    Handled by Goldsky Turbo

    Auditors ask for the full history long after the actions happened, so it has to sit somewhere your team controls.

    Write every action as one row, keyed so that a retried write replaces the row instead of adding a second one. A log with duplicates or gaps raises more questions than it answers.

    The pipeline writes each action to a database or warehouse sink with primary_key set to the event’s id, so a replayed write is applied as an upsert and a reorg correction updates or removes the same row.

    How delivery and reorgs work (opens in a new tab)

  6. Flag sensitive actions as they happen

    Handled by Goldsky Turbo

    Some actions, such as granting a new admin role, need a person to look at them the same day.

    Pick the action types that need attention and send each one to the risk team as soon as it appears. The alert fires when the action is seen, before it’s final, so the receiving system has to handle a later correction.

    A second SQL transform in the same Turbo pipeline can keep only role grants and revocations and send them to a webhook sink, which retries until your endpoint returns a 2xx.

    Send rows to a webhook (opens in a new tab)

  7. Review each action for audit

    Risk and audit teams have to confirm that every action was taken by an authorized signer with the approvals it needed.

    Check each logged action against your list of admin addresses and your approval records, and explain any that don’t match. Where admin roles sit behind a multisig, the token’s events name the multisig, not each approver: owners usually sign off the chain and one transaction carries their signatures, so the approvers come from the multisig’s own records.

What to know about streaming admin actions to a warehouse

  • Goldsky runs the pipeline; you own the warehouse, its schema and who can read the log.
  • History from the contract’s deployment is backfilled first, then new actions arrive as they’re made.
  • Tables with a primary key take reorg corrections as updates and deletes; a webhook endpoint receives correction records and has to apply them itself.
  • An alert is a filtered row about one event, so a rule about something that didn’t happen, such as a missing approval, runs in your own systems.

Option 2: Keep a stablecoin admin action log with a hosted subgraph

A subgraph on the token contract turns each admin event into a record in an index Goldsky hosts, which your team queries over GraphQL. A webhook pushes every new record to your backend.

When to use a hosted subgraph for admin actions

The token is deployed on one chain, admin actions are rare, and you’d rather query a hosted API than run a database for the log.

What you’ll need

  • Goldsky Subgraphs
  • The token contract’s address and ABI
  • An endpoint that receives each new action
  • Your list of authorized admin addresses

  1. Decide who holds each admin role

    The log is only useful if you know who was allowed to take each action, so the roles come first.

    Write down which addresses can mint, burn, freeze, claw back or change roles, and which approvals each action needs. Without that list, a reviewer reading the log can see what happened but can’t tell whether it should have.

  2. Sign the admin action

    Every mint, freeze or role change starts with someone holding an admin key approving it.

    The action is signed under your approval policy, often by a multisig (a wallet that needs several approvers). If admin keys sit outside any policy, the log will record actions nobody signed off on.

  3. Record the action on the chain

    The token contract announces each admin action as an event, which is the evidence the log is built from.

    Each action emits one event with its block and transaction, and for a short time the newest blocks can still be replaced, so an action seen once isn’t final until enough blocks sit on top of it. On Tempo, a token’s transfer policy lives in the separate TIP-403 policy registry: the token emits TransferPolicyUpdate when its admin switches policy, and the registry emits WhitelistUpdated or BlacklistUpdated when a policy’s admin changes its list, so both contracts belong in the log.

  4. Index every admin action

    Handled by Goldsky Subgraphs

    Each event has to become a record your team can look up by action, address or date.

    Index the contract from its first block so the record covers every action ever taken, each with its block, time and transaction. An index that starts later leaves early mints and role grants out of the history.

    Goldsky’s no-code subgraph wizard takes the token contract’s address, fetches its ABI and generates a subgraph with a record type for each event, served from a hosted GraphQL endpoint.

    Create a no-code subgraph (opens in a new tab)

  5. Push each new action to your backend

    Handled by Goldsky Subgraphs

    Your team should hear about a new admin action without having to query for it.

    Each new record is sent to an endpoint you run, which stores it and decides who to notify. If the chain replaces the block an action was in, the endpoint has to remove or correct what it stored.

    Subgraph webhooks post every record change to your URL as an INSERT, UPDATE or DELETE, and each version carries a block_range, which lets your endpoint tell a reorg rollback from a real change.

    Learn about subgraph webhooks (opens in a new tab)

  6. Flag sensitive actions for the risk team

    Role changes and large mints need a person to look at them the same day.

    Your endpoint picks out the action types that need attention and routes them to the risk team. Keeping that rule in your own code means you can change it without touching the index.

  7. Review each action for audit

    Risk and audit teams have to confirm that every action was taken by an authorized signer with the approvals it needed.

    Check each logged action against your list of admin addresses and your approval records, and explain any that don’t match. Where admin roles sit behind a multisig, the token’s events name the multisig, not each approver: owners usually sign off the chain and one transaction carries their signatures, so the approvers come from the multisig’s own records.

What to know about logging admin actions in a subgraph

  • Goldsky runs indexing, storage and the API; you query the log rather than keep your own copy of it.
  • Each subgraph indexes one chain, so a token on several chains needs a subgraph for each.
  • Webhooks send an insert, update or delete for each record change with no guaranteed order between them, so your endpoint has to reconcile by record ID and version.
  • The index holds only chain data, so approvals and review notes stay in your own systems.

What you control

Your team
  • Decide who holds each admin role
  • Sign the admin action
  • Review each action for audit

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 enforce freezes and blocklists

Use cases built the same way

Keep a stablecoin admin action log 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