Watch addresses

Rolink can keep an eye on a few Solana addresses for each project. It polls each one, and every new transaction that touches it becomes a watch event, which the SDK fires on every server as ChainActivity. The event tells you that something happened and where to look: the signature, the slot and whether it failed. It doesn’t decode the transaction.

Watching needs live events. Without a universe ID and an Open Cloud API key on the project, Rolink still polls, but the events go nowhere.

Add a watch

1. In the dashboard, open your project and go to Watched addresses.
2. Under Watch an address, enter a Name and an Address, then select Add address.
3. Connect a handler to rolink.ChainActivity in a server script (see the payload below).

The rules, checked when you save:

• Up to 10 watched addresses per project.
• Names are 1 to 32 characters: lowercase letters, digits, - and _, starting with a letter or a digit, such as treasury or shop-wallet. Each name is unique within the project. Your game receives it as ChainActivity.name, and it’s how Rolink remembers where it stopped.
• Addresses must be valid Solana addresses. They are read on the project’s cluster, so a devnet project watches devnet.

To stop watching, select Remove next to the watch.

Watching doesn’t count toward your project’s request quota: polls and the events they produce are Rolink’s own traffic, not API requests.

How polling works

Rolink polls each watched address every few seconds.

1. First poll: record where history ends. The first time Rolink polls a watch, it only notes the latest signature on that address. Nothing is published, so adding a watch on a busy address never replays its history.
2. Empty addresses still count. If the address has no transactions at all yet, Rolink remembers that instead, so the address’s very first transaction is still delivered.
3. Every poll after that fetches the signatures newer than the last one it saw, at confirmed commitment, 100 per page and up to 10 pages. It publishes them oldest first, then moves its position to the newest.
4. More than 1,000 at once means the address is busier than one poll can carry. Rolink publishes the newest 1,000 and skips the older ones. Watches are meant for addresses with moderate traffic, not for indexing a busy program.

If a poll fails, for example because the RPC is briefly unavailable, the next poll starts again from the same position. With live events off, Rolink still polls and records its position, so turning events on later doesn’t replay what it already saw.

Names are the position

Rolink stores its position per watch name, not per address, and keeps it after you remove a watch. To watch a different address, give it a name you haven’t used before in this project. Reusing a name for another address would make Rolink compare against a signature from the old address, and it could publish up to 1,000 past transactions of the new one. Adding a removed watch back under its old name resumes from where it stopped, so the transactions made in between are published (up to 1,000).

The ChainActivity payload

rolink.ChainActivity:Connect(function(activity)
  -- activity.name      "treasury" (the name from the dashboard)
  -- activity.address   the watched address
  -- activity.signature the transaction signature
  -- activity.slot      the slot it landed in
  -- activity.failed    true if the transaction failed on-chain
  print(`{activity.name}: {activity.signature} in slot {activity.slot}`)
end)

The message behind it is:

{ "v": 1, "type": "watch", "name": "treasury", "address": "…", "signature": "…", "slot": 312345678, "failed": false }

A failed transaction still appears, because it still touched the address (it paid a fee or was meant to). Check failed before reacting. The full format is in the Events reference.

Getting the details

ChainActivity doesn’t say what the transaction did: who sent what, or how much. For that:

• call rolink:GetSignatureStatus(activity.signature) for its status and slot,
• re-read the balances you care about with GetSolBalance or GetTokenBalance, or
• query your own indexer or RPC provider with the signature.

Like all events, ChainActivity is best effort. Rolink can occasionally publish the same signature twice, and MessagingService can drop a message. Deduplicate by signature, and don’t build accounting on top of it.

Deduplicate by signature

local seen: { [string]: boolean } = {}

rolink.ChainActivity:Connect(function(activity)
  if seen[activity.signature] or activity.failed then
    return
  end
  seen[activity.signature] = true
  -- react to the new transaction here
end)

What it’s good for

• Watch your managed wallet. Add the project’s wallet address (on the Overview page, or GetProject().walletAddress) as a watch to see every transaction it signs, and spot anything you didn’t expect.
• Refresh what’s on screen. When a game-owned address changes, re-read its balance for a lobby display or a leaderboard, instead of polling the balance on a timer.
• Operations alerts. Forward activity on important addresses from a game server to your own logging or alerting.

Note

If you’re thinking of granting something in the experience when a payment lands on an address, read Use Rolink responsibly first. Roblox’s rules on off-platform transactions tied to in-experience content apply to that kind of design.

Next steps

• Live events: the Open Cloud setup that watches depend on.
• Read on-chain data: GetSignatureStatus and balance reads.
• Limits and quotas: the watch limits with every other project limit.