SOLANA_TX_V1, SOLANA_APPROVE_V1, and SOLANA_REVOKE_V1) are archived and will be removed in November 2026.
The current events send one event per address involved instead of one per transaction, add a new event for delegated transfers, and add new payload fields:
What’s changing
-
Per-address delivery. The legacy webhook sent a single event per Solana transaction. The new webhook sends one event per subscribed address involved in the transaction. If two of your Portal clients are involved in a single Solana transaction (e.g. one sends SOL to the other), you will now receive two webhook events for that transaction — each with a different
triggeredByvalue and the samesignature. -
New event types. Each legacy event type has a replacement, plus a brand-new event for delegated transfers:
SOLANA_TX_V2— Solana native (SOL) transfers and SPL token transfers. (ReplacesSOLANA_TX_V1, without delegated transfers.)SOLANA_APPROVE_V2— Solana delegation approve transactions. (ReplacesSOLANA_APPROVE_V1.)SOLANA_REVOKE_V2— Solana delegation revoke transactions. (ReplacesSOLANA_REVOKE_V1.)SOLANA_DELEGATED_TRANSFER_V2— New event. Fires when a delegate executes a transfer using funds from another user’s previously-approved delegation.
-
triggeredByfield. Every event payload now includes atriggeredByfield. It identifies which of your subscribed addresses caused this specific event delivery. Use this to route events to the right user/account on your side without re-deriving it from the raw transaction data. -
directionfield. Every event payload also includes adirectionfield that describes what thetriggeredByaddress did in the transaction: -
recentBlockhashfield. Every event payload now includes arecentBlockhashfield — the base58-encodedrecentBlockhashof the transaction.
Payload differences
The same Solana transfer (a0.01 SOL receive) shows up like this on the legacy webhook vs the new one. Note the new triggeredBy and direction fields, and the type value changing from SOLANA_TX_V1 to SOLANA_TX_V2.
- Legacy (V1) payload
- Current (V2) payload
Event payloads
Below is a full example payload for each new event type so you can wire up parsers and types ahead of cutting over.SOLANA_TX_V2
SOLANA_APPROVE_V2
SOLANA_REVOKE_V2
SOLANA_DELEGATED_TRANSFER_V2
Migration steps
-
Expect multiple events per transaction. If two or more of your subscribed addresses are involved in the same Solana transaction, you will receive one event per address. Update your event handlers to be safe under this fan-out.
- Idempotency between transactions: dedupe on the
signaturefield. Solana transactions are uniquely identified by theirsignature, so it works as a stable idempotency key for “have I seen this transaction before?”. - Idempotency per (transaction, address): dedupe on the composite key
signature+triggeredBy. Use this when you process events per-address, so each(transaction, address)pair is processed exactly once even if the webhook is retried.
- Idempotency between transactions: dedupe on the
-
Subscribe to the events you need from the Portal Admin Dashboard. Open Webhooks > Informational in the Portal Admin Dashboard. Under Subscribed events, in the Solana transactions group, check Wallet transactions (
SOLANA_TX_V2) and any of Token approvals (SOLANA_APPROVE_V2), Token revocations (SOLANA_REVOKE_V2), and Delegated transfers (SOLANA_DELEGATED_TRANSFER_V2) you need. Then click Save changes. The other three events require Wallet transactions.You can keep the legacy events subscribed alongside the new ones until they’re removed, which lets you validate your V2 integration against live traffic before cutting over. While both are enabled, you receive both sets of events: a Solana transfer delivers the legacyIf you want to keep parity with the legacy webhook — i.e. be notified about every transfer involving your addresses — subscribe to bothSOLANA_TX_V2andSOLANA_DELEGATED_TRANSFER_V2. WithoutSOLANA_DELEGATED_TRANSFER_V2, transfers executed by a delegate against an approval that one of your addresses granted will not generate any webhook event.SOLANA_TX_V1event and theSOLANA_TX_V2event(s) for the same transaction, so a transfer between two of your subscribed addresses arrives as oneSOLANA_TX_V1event plus twoSOLANA_TX_V2events. Branch on the payload’stypefield to route the legacy and the current copies down separate paths, and keep thesignature/signature+triggeredBydeduplication from step 1 within the V2 path — the type check separates V1 from V2, but it does not collapse the per-address V2 fan-out. Once you have cut over, uncheck the legacy events under Archived and click Save changes. You can’t subscribe to them again. -
Test that events are being received with the correct types. Send a test event from the Test Informational Event section of the Informational page to check your parser, then send a real transaction (devnet works well) and confirm:
- You receive an event whose
typeends in_V2. If you still have the legacy events subscribed, you also receive the legacy counterpart for the same transaction —SOLANA_TX_V1,SOLANA_APPROVE_V1, orSOLANA_REVOKE_V1. - The payload contains both
triggeredByanddirection. - When two of your subscribed addresses are involved in the same transaction, you receive two events with different
triggeredByvalues and a sharedsignature.
- You receive an event whose