Stream Elysium wallet activity

A wallet or trading app on Elysium needs every movement in its users’ wallets as soon as it happens, to show activity, update balances and send notifications. This guide builds a Turbo pipeline that writes every ERC-20 transfer and every HYPE movement for the wallets you choose into one Postgres table, in both directions. You add and remove wallets by editing a Postgres table, and the running pipeline picks up the change without a redeploy.

To show a wallet’s activity in your app, start with Feeds. The Transfers and Balances endpoints return one wallet’s transfers and balances on Elysium and other chains over REST, with token metadata and USD values. There’s no pipeline or database to run. Data sync, in early access, pushes feed rows to your own database as they land. Use the pipeline below to stream every movement for a large, changing set of wallets into a database you run.

What you’ll need

A Goldsky account and the CLI installed

Install Goldsky's CLI and log in

Install the Goldsky CLI: For macOS/Linux:
curl https://goldsky.com | sh
For Windows:
npm install -g @goldskycom/cli
Windows users need to have Node.js and npm installed first. Download from nodejs.org if not already installed.
Log into your Project by running:
goldsky login
This opens your browser to sign in (Google, GitHub, SSO, or email). Once you authenticate, the CLI is logged in automatically — there’s no API key to copy or paste.
On a headless or remote machine (or in CI), create an API key on your Project Settings page and pass it directly with goldsky login --token <API_KEY>. Use goldsky login --no-browser to print the login URL instead of opening a browser.
Now that you are logged in, run goldsky to get started:
goldsky

A Postgres database and a Goldsky secret for it. The examples call the secret MY_POSTGRES.
Basic familiarity with Turbo pipelines and SQL transforms.

How the pipeline works

Two curated Elysium datasets are the sources:
- elysium_mainnet.erc20_transfers has one row per ERC-20 Transfer event.
- elysium_mainnet.native_transfers has one row per HYPE transfer, including HYPE sent by contracts in internal calls.
A dynamic table holds the wallets to follow.
Two transforms keep the transfers where a watched wallet is the sender or the recipient. A UNION ALL combines them, and a Postgres sink writes the result.

Create the wallet table

The pipeline caches the wallet list in memory and checks Postgres for new rows once per second. A cached table must give every new row an increasing timestamp, so create it yourself before you deploy:

CREATE SCHEMA IF NOT EXISTS streamling;

CREATE TABLE streamling.watched_wallets (
  value TEXT PRIMARY KEY,
  updated_at TIMESTAMP WITH TIME ZONE DEFAULT clock_timestamp()
);

Store addresses in lowercase. The datasets use lowercase addresses, and the comparison is exact.

Pipeline YAML

elysium-wallet-activity.yaml

name: elysium-wallet-activity
resource_size: s

sources:
  elysium_erc20_transfers:
    type: dataset
    dataset_name: elysium_mainnet.erc20_transfers
    version: 1.0.0
    start_at: latest
  elysium_native_transfers:
    type: dataset
    dataset_name: elysium_mainnet.native_transfers
    version: 1.0.0
    start_at: latest # keep both sources on the same start_at

transforms:
  # The wallets to follow. Add and remove rows in Postgres while the pipeline runs.
  watched_wallets:
    type: dynamic_table
    backend_type: Postgres
    backend_entity_name: watched_wallets
    secret_name: MY_POSTGRES
    cache: true

  token_activity:
    type: sql
    primary_key: id
    sql: |
      SELECT
        id,
        block_number,
        block_timestamp,
        transaction_hash,
        'erc20' AS kind,
        address AS asset,
        sender AS from_address,
        recipient AS to_address,
        amount
      FROM elysium_erc20_transfers
      WHERE dynamic_table_check('watched_wallets', sender)
        OR dynamic_table_check('watched_wallets', recipient)

  hype_activity:
    type: sql
    primary_key: id
    sql: |
      SELECT
        id,
        block_number,
        block_timestamp,
        transaction_hash,
        'native' AS kind,
        'HYPE' AS asset,
        sender AS from_address,
        recipient AS to_address,
        amount
      FROM elysium_native_transfers
      WHERE dynamic_table_check('watched_wallets', sender)
        OR dynamic_table_check('watched_wallets', recipient)

  # One stream for both kinds of movement
  wallet_activity:
    type: sql
    primary_key: id
    sql: |
      SELECT * FROM token_activity
      UNION ALL
      SELECT * FROM hype_activity

sinks:
  activity_table:
    type: postgres
    from: wallet_activity
    schema: public
    table: elysium_wallet_activity
    secret_name: MY_POSTGRES
    primary_key: id

Before you deploy, replace MY_POSTGRES with your secret name in both places. The two datasets use different ID formats (log_… and geth_trace_v2_…), so rows from the two sources never share an id.

Deploy and add wallets

goldsky turbo apply elysium-wallet-activity.yaml

Then add wallets from any Postgres client:

INSERT INTO streamling.watched_wallets (value)
VALUES (lower('0xYourWalletAddress'));

The pipeline loads new rows within about a second. Removals take longer. The cache keeps a deleted wallet until you restart the pipeline with goldsky turbo restart elysium-wallet-activity. If several processes write to the table at the same time, follow the rules for cached tables.

Output

Each row of public.elysium_wallet_activity is one movement:

Column	Description
`id`	Unique ID from the source dataset
`block_number`, `block_timestamp`, `transaction_hash`	Where the movement happened. `block_timestamp` is Unix seconds.
`kind`	`erc20` or `native`
`asset`	The token contract address on Elysium, or `HYPE`
`from_address`, `to_address`	Lowercase addresses
`amount`	Raw amount in the token’s smallest unit

Common tokens to label in your app:

Token	`asset`	Decimals
HYPE	`HYPE`	18
WHYPE	`0xba876237b0f021a6c6d852d6c26e107997cc5e81`	18
USDC	`0xb47c4c8f73f009cc0c0d3f92b388d13e293f0b65`	6

What Elysium activity looks like

Bridged tokens appear as mints and burns. When a watched wallet bridges a token in from HyperEVM, the gateway mints it on Elysium, and withdrawals to HyperEVM burn it:

Movement	Row for the watched wallet
USDC (or another token) bridged in	`erc20` row from the zero address `0x0000…0000`
WHYPE bridged in	`erc20` row from the WHYPE gateway `0xb916…55b6`. The gateway mints WHYPE to itself, then sends it on.
Token bridged out	`erc20` row to the zero address

Wrapping HYPE also mints WHYPE. WHYPE on Elysium holds the HYPE behind it. Calling deposit() with HYPE gives two rows in one transaction: a native row from the wallet to the WHYPE contract, and an erc20 row that mints WHYPE from the zero address to the wallet. So a WHYPE row from the zero address is a wrap, not a bridge deposit. Bridged HYPE comes from an aliased address. Elysium credits a HYPE deposit from HyperEVM with a call from the sender’s aliased address: the sender’s HyperEVM address plus 0x1111000000000000000000000000000000001111. The row’s from_address is not an address the user knows. A wallet that bridges to itself shows a native row from its own address plus the offset. To label these rows as deposits, use Track Elysium bridge flows. HYPE that a contract sends is included. native_transfers is built from traces. When a contract pays out HYPE inside a transaction, for example on a swap or an unwrap, the transfer still appears as a native row. Blocks are fast. Elysium can make a block every 100 ms, so many blocks share one block_timestamp. Order a wallet’s history by block_number, not by time.

Notes

The pipeline starts at the chain head. A wallet you add now gets its new activity, not its history. To include history, set start_at: earliest on both sources.
Every transfer on the chain is read, then filtered. The pipeline is billed on worker hours and records written, not on how many wallets you follow. Each matching movement is one record written to Postgres.

Getting help

Can’t find what you’re looking for? Reach out to us at support@goldsky.com for help.

Chains

Partners

Other networks

Stream Elysium wallet activity

What you’ll need

How the pipeline works

Create the wallet table

Pipeline YAML

Deploy and add wallets

Output

What Elysium activity looks like

Notes

Getting help

​What you’ll need

​How the pipeline works

​Create the wallet table

​Pipeline YAML

​Deploy and add wallets

​Output

​What Elysium activity looks like

​Notes

​Getting help

What you’ll need

How the pipeline works

Create the wallet table

Pipeline YAML

Deploy and add wallets

Output

What Elysium activity looks like

Notes

Getting help