ERC-3643 eligibility and allowlist tracking
What it is
ERC-3643 eligibility tracking is keeping a live record of which investors may hold a security token built on ERC-3643, also called T-REX, a token standard that checks an identity registry before every transfer.
Transfer agents and tokenization platforms answer for the register of holders, so they need every registration, removal and freeze on record, and a flag when shares move to or from a wallet they’re watching.
Goldsky decodes the registry’s identity and freeze events and screens transfers against your watch list, writing both to your database; investor checks and registry changes stay with your team.
You can track ERC-3643 eligibility two ways: stream registry events and screened transfers into your own database with Turbo Pipelines, or index the registry in a hosted subgraph.
Who it’s for
Tokenization platforms and transfer agents that keep the register for tokenized funds, shares and bonds.
How ERC-3643 eligibility tracking works
The diagram follows one investor from onboarding through a transfer of shares to your transfer agent’s review of any flag, and shows who does each step. Your setup may differ.
Ways to track ERC-3643 eligibility
Only the pipeline screens transfers against a watch list you change while it runs; a subgraph gives you a hosted register to query, one chain per subgraph, shaped by mapping code you write.
- Best for
- A register in your own database, with transfers screened
- 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
- Best for
- A hosted register of eligible wallets on one EVM chain
- 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
| Usual setupOption 1: Stream to your database | Option 2: Hosted subgraph | |
|---|---|---|
| Best for | A register in your own database, with transfers screened | A hosted register of eligible wallets on one EVM chain |
| Products | Turbo | Subgraphs |
| What you run | The destination: your database, queue or bucket, or a Postgres database Goldsky hosts | Nothing; Goldsky runs indexing, storage and the API |
| What you write | Pipeline YAML and SQL; TypeScript transforms when needed | A schema and mapping handlers, or a no-code or low-code config for simple contracts |
| Where your data lives | In your own database or systems | Hosted by Goldsky |
| How results reach you | Pushed to you | You query; changes are pushed |
Onboard the investor
A security token can only be held by approved investors, so each one starts by applying.
Your onboarding team collects the investor’s details and the wallet they’ll hold shares in. Without that link, an approved investor can’t be tied to their wallet later.
Verify the investor
Securities rules limit who may hold the token, for example by country or investor type, so each investor is checked first.
Your identity verification provider checks the investor’s identity and eligibility against the token’s rules. A wallet registered before the checks pass lets an ineligible investor receive shares.
Register the identity onchain
ERC-3643 tokens check an identity registry before every transfer, so a wallet can receive shares only once it’s registered.
An agent of the token, often the transfer agent, adds the investor’s identity and wallet to the registry. The same role removes or updates the entry when the investor’s status changes.
Confirm the registry change
Once the change is in a block, the token treats the wallet as eligible and records an event saying so.
Until enough blocks sit on top of it, a reorg (the chain replacing its newest blocks) can still undo the change.
Let the shares change hands
Investors transfer their shares, and the token checks the registry and its transfer rules before each one goes through.
A transfer to an unregistered wallet fails onchain. A transfer between registered wallets still goes through even when one of them is on your internal watch list, which is why you screen it.
Record every eligibility change
Handled by Goldsky TurboThe register has to show who was eligible to hold the token at any point, and examiners ask for those events.
Each registration, removal, freeze and recovery is decoded with its wallet and block. A missing removal makes a former investor look eligible in your records.
With Goldsky, a Turbo Pipelines transform decodes ERC-3643 events such as
See an ERC-3643 event pipeline (opens in a new tab)IdentityRegistered,IdentityRemoved,AddressFrozenandRecoverySuccessfrom your token’s logs.Screen each transfer against your watch list
Handled by Goldsky TurboYour team may want to know when shares move to or from a wallet it’s watching, even when the token allows the transfer.
The watch list has to change while screening runs, so a wallet added this morning is checked on its next transfer. A list that only updates on redeploy leaves a gap.
Turbo Pipelines checks both sides of each transfer against a dynamic table with
Learn about dynamic tables (opens in a new tab)dynamic_table_check, and picks up rows you add to that Postgres table without a redeploy.Keep the registry and flags current
Handled by Goldsky TurboYour transfer agent works from one place that shows each wallet’s latest status and every flag.
Events and flags land in tables keyed on a stable ID, so a retry or a correction replaces a row instead of duplicating it.
A database sink with a
How retries and reorgs reach tables (opens in a new tab)primary_keywrites each row as an upsert, so reorg corrections and repeat deliveries update the rows already there.Review each flag
A flag is a question, not a decision, so someone has to look at it.
Your transfer agent checks the flagged transfer or change, decides whether it needs action such as a freeze, and records the outcome. A flag nobody reviews shows you were told and didn’t act.
What to know about streaming ERC-3643 events into your database
- Goldsky runs the pipeline; your transfer agent owns the registry, the watch list and every follow-up.
- The watch list check asks only whether an address is on the list; anything that needs a join, such as tying two wallets to one owner, happens in your database.
- You can add to and remove from the watch list while the pipeline runs.
- Rows keyed on a primary key take reorg corrections as updates and deletes.
Onboard the investor
A security token can only be held by approved investors, so each one starts by applying.
Your onboarding team collects the investor’s details and the wallet they’ll hold shares in. Without that link, an approved investor can’t be tied to their wallet later.
Verify the investor
Securities rules limit who may hold the token, for example by country or investor type, so each investor is checked first.
Your identity verification provider checks the investor’s identity and eligibility against the token’s rules. A wallet registered before the checks pass lets an ineligible investor receive shares.
Register the identity onchain
ERC-3643 tokens check an identity registry before every transfer, so a wallet can receive shares only once it’s registered.
An agent of the token, often the transfer agent, adds the investor’s identity and wallet to the registry. The same role removes or updates the entry when the investor’s status changes.
Confirm the registry change
Once the change is in a block, the token treats the wallet as eligible and records an event saying so.
Until enough blocks sit on top of it, a reorg (the chain replacing its newest blocks) can still undo the change.
Let the shares change hands
Investors transfer their shares, and the token checks the registry and its transfer rules before each one goes through.
A transfer to an unregistered wallet fails onchain. A transfer between registered wallets still goes through even when one of them is on your internal watch list, which is why you screen it.
Index every eligibility change
Handled by Goldsky SubgraphsEach registration, removal, freeze and recovery changes what one investor may do, so each has to update that investor’s record.
Every event is decoded and applied to the wallet it names. A missing removal makes a former investor look eligible.
A Goldsky subgraph’s mapping handles each registry and freeze event and updates the record for that wallet, so it holds the investor’s current status.
See a holder registry on subgraphs (opens in a new tab)Look up the register
Handled by Goldsky SubgraphsYour transfer agent and apps need any wallet’s status, now or at a past date.
The register has to answer by wallet and by date. One that only shows today’s status can’t tell an examiner who was eligible last quarter.
The subgraph serves each wallet’s record through GraphQL, and because it keeps every version of a record, a query can return the register as it stood at an earlier block.
Learn about hosted subgraphs (opens in a new tab)Tell your transfer agent about each change
Handled by Goldsky SubgraphsChanges such as a freeze or a removal may need follow-up, so they have to reach the team that acts on them.
Each change goes to the endpoint your transfer agent’s tools watch. A rollback after a reorg arrives as another change, which the receiver applies instead of treating as new.
Subgraph webhooks post each changed record to your endpoint, with the block range that tells a rollback apart from a real change.
How subgraph webhooks report changes (opens in a new tab)Review each flag
A flag is a question, not a decision, so someone has to look at it.
Your transfer agent checks the flagged transfer or change, decides whether it needs action such as a freeze, and records the outcome. A flag nobody reviews shows you were told and didn’t act.
What to know about tracking ERC-3643 eligibility with a subgraph
- One subgraph covers one chain, so a token on several chains needs one for each.
- You write the mapping that turns events into investor records, so the register’s fields are yours to define.
- Screening transfers against a list you change at runtime isn’t part of this way, and stays with your own systems.
- Webhooks include rollbacks after a reorg, and your receiver has to apply them.
What you control
- Your team
- Onboard the investor
- Register the identity onchain
- Review each flag
- Your providers
- KYC/KYB 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 enforce freezes and blocklists
- Stablecoin freezes and seizuresRecord every freeze, seizure and burn on a lawful order, with the balance it affected.
- Token allowlist membership trackingFollow which wallets may hold or receive a bank-issued token as the allowlist changes.
- Stablecoin admin action logRecord every mint, burn, freeze, clawback and role change with its time and signer for risk and audit review.
Track ERC-3643 eligibility 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.
Robinhood
HyperEVM
Arc
Solana
Ethereum
Polymarket
Base
Tempo
Bitcoin
