Skip to main content
Portal’s Flutter SDK provides token delegation capabilities through the portal.delegations API. This enables approving token spending, revoking approvals, checking delegation status, and transferring tokens as a delegate on both EVM and Solana chains.

Overview

The delegations functionality allows you to:
  • Approve other addresses to spend tokens on behalf of your wallet
  • Revoke existing delegations to remove spending permissions
  • Check status of active delegations and balances
  • Transfer tokens as a delegate from another address

Prerequisites

Before using delegation operations, ensure you have:
Delegations apply to ERC-20 tokens (EVM) and SPL Tokens (Solana) only. Native assets like ETH, MON, and SOL cannot be delegated — they have no on-chain approve / transferFrom (or SPL delegate) semantics. Calls using a native asset identifier will be rejected. See Delegations for the protocol-level reason and workarounds.
All examples below assume Portal has already been initialized with await portal.initialize(apiKey: 'YOUR_API_KEY'). See Getting Started for details.

High-Level Methods

Use approveAndSubmit, revokeAndSubmit, and transferAndSubmit when you want one call for the whole flow: build the delegation transaction(s), then sign and broadcast each one in order and collect the resulting hashes. The wallet’s signer is wired up for you, and EVM and Solana chains are routed to the right RPC method automatically, so the common case needs no configuration at all.
approveAndSubmit, revokeAndSubmit, and transferAndSubmit broadcast each transaction and return as soon as it is accepted by the network. They do not wait for on-chain confirmation. A returned hash means the transaction was submitted, not that it succeeded — an approval can still revert. If your flow depends on the delegation being active, wait for the receipt yourself, or poll getStatus before proceeding.

Signatures

Each takes the same parameters as its low-level counterpart — see EVM Approval, EVM Revoke, and EVM Transfer From below — plus an optional onProgress. Failures throw a PortalException, so wrap calls in try / catch.

Progress

onProgress is optional. When set, it is called twice per transaction — once with signing before signing begins, and once with submitted after the transaction is broadcast. For a batch of n transactions it is called 2n times. DelegationSubmitProgress carries: DelegationSubmitStep has exactly two values — signing and submitted. There is no confirming or confirmed step, because nothing is awaited on-chain.

Return value

All three return List<String> — one transaction hash per broadcast transaction, in submission order. Most delegation flows produce a single transaction, so the list usually has one element. Transactions are submitted sequentially, not batched into one RPC call: if the API returns multiple payloads, the second is only sent after the first has been broadcast. There is no status field and no partial-success concept: a hash is present because the network accepted the transaction, and nothing beyond that has been checked.

Example (approve and submit)

Example (revoke and submit)

Example (transfer as a delegate)

The wallet calling transferAndSubmit must already be an approved delegate of fromAddress.

Example (Solana)

The same three methods work on Solana — pass a solana: CAIP-2 chain ID and the SDK signs and submits via sol_signAndSendTransaction instead of eth_sendTransaction:

Errors

All failures throw a PortalException. Catch it with on PortalException: The message carries the underlying reason. Two come from the native SDK itself: Most failures instead surface the API’s own error message, such as: The submit methods can also fail with the same network and decoding errors the low-level methods return.

Low-level methods

The sections below are the manual path: approve, revoke, transferFrom, and getStatus return unsigned transactions and leave signing and broadcasting to you. You receive EVM transaction objects or Solana-encoded payloads and call portal.request with the right method (eth_sendTransaction or sol_signAndSendTransaction) yourself. Use them when you need to inspect, modify, batch, or route the transactions yourself. Otherwise prefer the high-level methods above.

Approving Delegations

Use approve to grant another address permission to spend tokens on your behalf. This method works for both EVM and Solana chains.

EVM Approval

Each delegation response includes a metadata field with additional details such as chainId, tokenSymbol, tokenAddress, and delegateAddress. Access it via response.metadata?.chainId for approve/revoke, or response.metadata.chainId for transferFrom.

Solana Approval


Checking Delegation Status

Use getStatus to check current delegations and token balances for a specific delegate address.

EVM Status Check

Solana Status Check


Revoking Delegations

Use revoke to remove spending permissions from a delegate address.

EVM Revoke

Solana Revoke

Always revoke unused delegations after completing operations to minimize security risks.

Transferring as a Delegate

Use transferFrom to transfer tokens from another address that has delegated spending permission to you.

EVM Transfer From

Solana Transfer From

Delegation Roles: fromAddress is the token owner who approved the delegation. Your wallet (the delegate) signs the transaction to transfer tokens from the owner to the toAddress recipient.

Supported Networks

Delegations work on all Portal-supported EVM and Solana chains:
  • EVM: Ethereum, Polygon, Base, Arbitrum, Optimism, Monad, and all other EVM-compatible chains
  • Solana: Solana Mainnet and Devnet
For a complete list, see Blockchain Support.

Next Steps