Skip to main content
This page lists every event you can subscribe to on your informational webhook. The sections follow the groups in the Events step of the dashboard: EVM transactions, Solana transactions, Wallet lifecycle, and Wallet actions. Every event shares the same envelope: data holds the event, metadata holds context about where it came from, and type names the event. Use type to route events in your handler.

EVM transactions

Wallet transactions (EIP_155_TX_V1)

Portal sends this event when an EVM address it watches for you sends or receives tokens, or approves or revokes a token spender. That covers:
  • Sending and receiving native tokens, such as ETH.
  • Sending and receiving ERC-20 tokens, such as USDC.
  • Sending and receiving NFTs.
  • Approving an ERC-20 spender, and revoking an approval by setting the allowance to 0.
Portal starts watching as soon as you subscribe, and includes every client you create afterwards. Each transaction produces two events for each watched address involved. The first arrives with confirmed: false as soon as the transaction is in a block. The second arrives with confirmed: true once the chain reaches the number of blocks in the table below. If a chain reorganization replaces the block, you can get the confirmed: false event without a confirmed: true one. data is an array with one item per transfer in the transaction: The envelope’s metadata includes custodianId, environmentId, chainId, and confirmed. It can also include the raw block, logs, and transactions from Portal’s chain data provider in block, logs, txs, and retries. Don’t rely on their shape. actualGasCost and formattedActualGasCost are only set when the client’s transaction ran as an account abstraction user operation. With a gas policy on the chain, they show the gas you sponsored.
Unconfirmed event (confirmed: false):
Confirmed event (confirmed: true):

Solana transactions

Every Solana event wraps the transaction in data.rawEvents, an array with one item. The envelope’s metadata includes environmentId, isDevnet, and eventTypes, and doesn’t include custodianId. Portal sends one event for each watched address involved in a transaction, once the transaction is confirmed. triggeredBy is the watched address the event was sent for, and direction is the role that address played: Solana events support up to 1,000,000 watched addresses. Contact our team if you need more. After you create a client, it can take up to 4 minutes before Portal sends Solana events for it. The fields in each data.rawEvents[] item:

Wallet transactions (SOLANA_TX_V2)

Portal sends this event when a watched Solana address sends or receives SOL or an SPL token, such as USDC. Delegated transfers are a separate event, SOLANA_DELEGATED_TRANSFER_V2, described below. You need this event to subscribe to the other Solana events in the group.

Token approvals (SOLANA_APPROVE_V2)

Portal sends this event when a watched address approves a delegate to spend an SPL token on its behalf, or is approved as one. direction is OUTBOUND for the owner and INBOUND for the delegate. Requires Wallet transactions in the Solana group.

Token revocations (SOLANA_REVOKE_V2)

Portal sends this event when a watched address revokes a delegate’s approval to spend an SPL token. direction is always OUTBOUND. Requires Wallet transactions in the Solana group.

Delegated transfers (SOLANA_DELEGATED_TRANSFER_V2)

Portal sends this event when a delegate spends tokens it was approved to spend. For example, if address A approves address B to spend its USDC, and B later sends some of A’s USDC to C, Portal sends this event. Each watched address gets its own event:
  • OUTBOUND for the delegate that executed the transfer (B).
  • INBOUND for the recipient (C).
  • DELEGATED for the owner whose tokens moved (A).
Requires Wallet transactions in the Solana group.

Wallet lifecycle

Each Portal client has a key on two curves, SECP256K1 and ED25519, and each curve has its own walletId. The wallet lifecycle events are sent once per curve, so you usually get two events for one action, with the same clientId and different walletId values. The envelope’s metadata includes custodianId and environmentId.

Wallet created (WALLET_GENERATE_V1)

Portal sends this event when a client creates a wallet and stores its signing share.

Wallet backed up (WALLET_BACKUP_V1)

Portal sends this event when a client backs up a wallet. If the client backs up with more than one method, you get one event per method per curve.

Wallet recovered (WALLET_RECOVER_V1)

Portal sends this event when a client recovers a wallet and stores the new signing share. signingSharePairId is the new share pair, not the one that was backed up.

Wallet actions

Wallet ejected (WALLET_EJECT_V1)

Portal sends this event when a client ejects their wallet. Ejecting covers both curves, so you get one event per client. The eject has already happened when you receive the event, and your response doesn’t change it. Portal makes one delivery attempt for this event and doesn’t retry it automatically. If your server misses it, resend it from the event log.

Archived events

The first version of the Solana events is archived and will be removed in November 2026. To move to the current events, follow Migrating from legacy Solana webhook events. The archived events differ from the current ones in these ways:
  • Portal sends one event per transaction, not one per watched address.
  • data.rawEvents[] items have no triggeredBy, direction, or recentBlockhash.
  • Delegated transfers have no event of their own.
  • Archived events support up to 100,000 watched addresses.
Token approvals and token revocations require the archived Wallet transactions event.

Wallet transactions (SOLANA_TX_V1)

Portal sends this event when a watched Solana address sends or receives SOL or an SPL token.

Token approvals (SOLANA_APPROVE_V1)

Portal sends this event when a watched address approves a delegate to spend an SPL token on its behalf.

Token revocations (SOLANA_REVOKE_V1)

Portal sends this event when a watched address revokes a delegate’s approval to spend an SPL token.