Skip to main content
Portal’s Android 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.

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. Portal installs a working signer on portal.delegations for you, 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 hash in DelegationSubmitResult.hashes 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.This is different from Yield.xyz, where you wait for each transaction to confirm before moving on to the next step. Do not carry that assumption over to delegations.

Signatures

options is defaulted, so portal.delegations.approveAndSubmit(request) is a complete call. All three return Result<DelegationSubmitResult> — handle failures via onSuccess / onFailure (or fold), since errors are returned in the Result rather than thrown. The request types are the same ones the low-level methods take — see EVM Approval, EVM Revoke, and EVM Transfer From below for their fields.

Configuring the signer

A signer signs and broadcasts one transaction and returns its hash:
DelegationTransaction is a sealed class covering both ecosystems:
Solana.encodedTransaction is base64-encoded. Because it is a sealed class, a when over it is exhaustive and needs no else. Portal installs a default signer that routes Evm transactions to eth_sendTransaction and Solana transactions to sol_signAndSendTransaction:
So this works with zero setup:
Use setSignAndSendTransaction(fn) to replace the signer for the instance, or DelegationSubmitOptions.signAndSendTransaction to override it for a single call. The precedence is per-call option → instance signer → Portal default.

Options and progress

DelegationSubmitOptions is the second argument to each submit method: DelegationSubmitProgress carries: DelegationSubmitStep has exactly two members — SIGNING and SUBMITTED. There is no confirming or confirmed step, because nothing is awaited on-chain.
DelegationSubmitStep members are uppercase (DelegationSubmitStep.SIGNING), while YieldSubmitStep members are lowercase (YieldSubmitStep.signing). Both shipped in 9.1.0. Write each one the way its own type declares it.

Return value

DelegationSubmitResult carries only the hashes: 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)

This builds the same approval as EVM Approval below, but signs and broadcasts it for you.
The when over progress.step is exhaustive with no else — there really are only two steps.

Example (revoke and submit)

Same RevokeDelegationRequest as EVM Revoke below, submitted end to end.
Because the revoke is not confirmed when this call returns, the delegation may still be active for a short time afterwards. Poll getStatus if you need to show the user that it is gone.

Example (transfer as a delegate)

Same TransferFromRequest as EVM Transfer From below. Your wallet must already be an approved delegate for fromAddress.

Example (custom signer)

Replace the default signer when you need to do something it does not, such as attaching a signatureApprovalMemo to every delegation transaction. A when over the sealed class is exhaustive and returns the hash directly:
To use a different signer for a single call, pass it in the options instead — it takes priority over the instance signer:

Errors

DelegationsError is a sealed class of Exception subclasses. They arrive inside a failed Result, so match them in onFailure:
The submit methods can also fail with the network and decoding errors the low-level methods return. Coroutine cancellation is never captured in the Result — it is rethrown, so structured concurrency still works when the calling scope is torn down.

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. 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

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