Skip to main content

Goldsky

Security token recovery for lost wallets

Talk to our team

What it is

Security token recovery tracking is recording each time a lost security token is moved to an investor’s new wallet after the investor proves their identity again, a recovery that permissioned token standards such as ERC-3643 build into the contract.

Transfer agents and tokenization platforms track recoveries because the holding moves without the old wallet signing anything, and the register has to show who approved the move and why.

Goldsky decodes each recovery event from the token contract into your records, while your identity provider, your tokenization platform and your team handle the request, the checks and the register.

You can track recoveries two ways: stream recovery events into the database your register runs on with Turbo Pipelines, or index them in a subgraph Goldsky hosts and receive each one by webhook.

Who it’s for

Transfer agents and tokenization platforms that keep the holder register for permissioned security tokens.

How security token recovery tracking works

The diagram follows one recovery from the investor’s report of a lost wallet to the register entry that moves their holding, and shows who does each step. Your setup may differ.

Your business, step 1: Investor reports a lost walletThe request reaches the transfer agent
Your business, step 2: KYC/KYB providerVerify the investor againIdentity confirmed before reissue
Your business, step 3: Transfer agentRecover the tokensThe platform’s agent moves them to a new wallet
Blockchains, step 4: Recovery executesThe token contract emits the event
Goldsky, step 5: TurboDecode the recoveryLost wallet, new wallet and investor identity
Your business, steps 7–8: Update the registerThe holding moves to the new wallet
Goldsky, step 6: TurboWrite to your recordsEach recovery stored with its block
  • Goldsky
  • Your provider

Ways to track security token recoveries

Recovery records land next to your register when a pipeline writes them into your own database; with the subgraph they stay in a hosted index, and each new one is pushed to your endpoint.

Usual setupOption 1: Stream to your database
Best for
A register in your own database, tokens on several chains
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 chain per token, recoveries pushed to your backend
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: Track security token recoveries by streaming to your database

A pipeline decodes recovery events from the token contract on each chain and writes each one, with the lost wallet, the new wallet and the investor’s identity, into the database your register runs on.

When to stream recoveries into your database

The register already lives in your own database, or one fund or security is issued on several chains and every recovery has to land in one place.

What you’ll need

  • Goldsky Turbo
  • An identity verification provider
  • The tokenization platform that runs the token contract
  • The database your register runs on
  • The token contract’s ABI on each chain

  1. Take the investor’s report of a lost wallet

    A recovery starts when an investor loses access to the wallet that holds their security tokens.

    The request reaches the transfer agent with the investor’s details and the new wallet they want to use. Each request needs a reference that stays with it to the end, or the recovery can’t be tied back to the approval later.

  2. Verify the investor again

    Moving tokens to a new wallet without the old one signing is only safe once you know the request comes from the real holder.

    Your identity verification provider checks the investor again before anything moves. A recovery approved on a weak check hands the holding to whoever asked for it.

  3. Recover the tokens to the new wallet

    A permissioned token lets an authorized agent move a lost holding to a new wallet the investor controls.

    Your tokenization platform’s agent calls the token’s recovery function with the lost wallet, the new wallet and the investor’s onchain identity. A recovery sent to the wrong wallet is a transfer like any other and has to be reversed the same way.

  4. Execute the recovery on the chain

    Once the transaction is included, the contract moves the balance and announces the recovery as an event.

    Under ERC-3643 the contract emits a RecoverySuccess event naming the lost wallet, the new wallet and the investor’s identity. Until enough blocks sit on top of it, a reorg (the chain replacing its newest blocks) can still undo it.

  5. Decode the recovery

    Handled by Goldsky Turbo

    The recovery event has to be turned into a record that names both wallets and the investor.

    Decode each recovery from the token’s events, on every chain the security is issued on. A recovery that goes unrecorded leaves the register showing the holding at a wallet that no longer has it.

    Turbo Pipelines can decode the token’s logs with the ERC-3643 ABI and keep RecoverySuccess events alongside freezes and identity changes, each with its block time and transaction hash.

    Track ERC-3643 recoveries (opens in a new tab)

  6. Write each recovery to your records

    Handled by Goldsky Turbo

    The recovery has to sit in the same database as the register, so the two can be checked together.

    Store each recovery as one row with its block and transaction, keyed so a retried write replaces the row. If a reorg drops the recovery, the row has to go too, or the register moves a holding that never moved.

    The pipeline writes to a table with primary_key set to the event’s id, so a replayed write is applied as an upsert and a reorg correction deletes the row.

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

  7. Match each recovery to its approved request

    Every recovery on the chain should trace back to one request that passed identity checks.

    Tie each recovery to its request by the investor’s identity and the two wallets, and confirm the identity check passed before the recovery executed. A recovery with no matching request is an incident to investigate, not a register update.

  8. Update the register

    The register is the legal record of who holds what, so it has to show the holding at its new wallet and why it moved.

    Move the holding to the new wallet, citing the request, the identity check and the transaction. If the register changes without that trail, the next audit sees a balance move with no reason recorded.

What to know about streaming recoveries into your database

  • Goldsky runs the pipeline; you own the database, the register and the check against identity records.
  • The same pipeline can carry the contract’s freezes and identity changes, so recoveries sit beside the other events an examiner may ask for.
  • Tables keyed on the event’s ID take reorg corrections as updates and deletes, so a recovery the chain drops disappears from your records too.

Option 2: Track security token recoveries with a hosted subgraph

A subgraph on the token contract keeps a record of each recovery in an index Goldsky hosts. A webhook sends every new recovery to your backend to check and post to the register.

When to use a hosted subgraph for recoveries

Each token sits on one chain, recoveries are rare, and you’d rather receive them by webhook and query a hosted API than run a pipeline into your database.

What you’ll need

  • Goldsky Subgraphs
  • An identity verification provider
  • The tokenization platform that runs the token contract
  • An endpoint that receives each recovery
  • Your register system

  1. Take the investor’s report of a lost wallet

    A recovery starts when an investor loses access to the wallet that holds their security tokens.

    The request reaches the transfer agent with the investor’s details and the new wallet they want to use. Each request needs a reference that stays with it to the end, or the recovery can’t be tied back to the approval later.

  2. Verify the investor again

    Moving tokens to a new wallet without the old one signing is only safe once you know the request comes from the real holder.

    Your identity verification provider checks the investor again before anything moves. A recovery approved on a weak check hands the holding to whoever asked for it.

  3. Recover the tokens to the new wallet

    A permissioned token lets an authorized agent move a lost holding to a new wallet the investor controls.

    Your tokenization platform’s agent calls the token’s recovery function with the lost wallet, the new wallet and the investor’s onchain identity. A recovery sent to the wrong wallet is a transfer like any other and has to be reversed the same way.

  4. Execute the recovery on the chain

    Once the transaction is included, the contract moves the balance and announces the recovery as an event.

    Under ERC-3643 the contract emits a RecoverySuccess event naming the lost wallet, the new wallet and the investor’s identity. Until enough blocks sit on top of it, a reorg (the chain replacing its newest blocks) can still undo it.

  5. Index each recovery

    Handled by Goldsky Subgraphs

    Each recovery has to become a record your team can look up by investor or wallet.

    Index the token contract so every recovery is saved with both wallets, the investor’s identity, the block and the transaction. An index that misses recoveries leaves gaps no one notices until a holder asks.

    With Goldsky Subgraphs, a mapping on the token contract can save each RecoverySuccess event as its own record, queryable from a hosted GraphQL API that Goldsky runs.

    Index onchain data with Subgraphs (opens in a new tab)

  6. Send each recovery to your backend

    Handled by Goldsky Subgraphs

    Your team should hear about a recovery as soon as it’s indexed, without polling for it.

    Each new recovery is posted to an endpoint you run, which stores it for matching. If the chain replaces the block the recovery was in, the endpoint has to undo what it stored.

    Goldsky sends each record change to your URL through a subgraph webhook, and a version’s block_range lets your endpoint tell a recovery the chain rolled back from a new one.

    Learn about subgraph webhooks (opens in a new tab)

  7. Match each recovery to its approved request

    Every recovery on the chain should trace back to one request that passed identity checks.

    Tie each recovery to its request by the investor’s identity and the two wallets, and confirm the identity check passed before the recovery executed. A recovery with no matching request is an incident to investigate, not a register update.

  8. Update the register

    The register is the legal record of who holds what, so it has to show the holding at its new wallet and why it moved.

    Move the holding to the new wallet, citing the request, the identity check and the transaction. If the register changes without that trail, the next audit sees a balance move with no reason recorded.

What to know about tracking recoveries in a hosted subgraph

  • Goldsky runs indexing, storage and the GraphQL API; your register stays in your own system.
  • Each subgraph indexes one chain, so a security issued on several chains needs a subgraph for each.
  • Webhooks carry an insert, update or delete for each change with no guaranteed order, so your endpoint has to handle them by record ID and version.

What you control

Your team
  • Take the investor’s report of a lost wallet
  • Match each recovery to its approved request
  • Update the register
Your providers
  • KYC/KYB provider
  • Transfer agent

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 keep a holder register

Use cases built the same way

Track security token recoveries 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