Temporary Account
Pronunciation: TEM-puh-rair-ee uh-KOWNT
Definition
A temporary account is an account created for a limited task, time period, or transaction workflow and intended to be closed, emptied, or abandoned afterward. It may hold intermediate assets, stage program state, or isolate permissions. The term is architectural and protocol-dependent; creation cost, rent, recovery, and residual authority must be managed explicitly. Practical use requires recognizing that short-lived state can retain funds or permissions long after the application considers the workflow complete.
Overview
A temporary account provides short-lived isolation for an operation. A protocol or application may create one to hold escrowed assets, prepare a swap, stage data, or separate a one-time authorization from a permanent account. Unlike a Session Account, which emphasizes delegated permissions for repeated actions, a temporary account often exists as an on-chain state object with a deliberately limited lifecycle.
The account can still create lasting risk. Funds or storage may remain after the intended workflow completes, closing authority may be lost, or the address may be reused incorrectly. Some networks charge storage rent or require a minimum balance, making cleanup economically important. Other systems use deterministic addresses, so developers must ensure an old temporary state cannot be confused with a new operation.
Authorization should be narrow and documented. The account may be controlled by a user key, program-derived authority, multisignature policy, or contract. A time limit in application code is not enough if the account can still sign or hold assets afterward. Closure, refund destination, and emergency recovery need enforceable rules.
Payment and smart-contract systems should track creation, purpose, expected expiry, balances, owner, and closure transaction. Monitoring should alert on accounts that remain active beyond their expected lifetime or retain unexpected assets. Temporary accounts are useful only when their residual state and authority are eliminated or safely accounted for.
Useful operational records include the creator, purpose, authority, expected lifetime, balances, storage cost, refund destination, and closure transaction. They are necessary because short-lived state can retain funds or permissions long after the application considers the workflow complete. Systems should also alert on overdue cleanup and verify closure through the resulting on-chain state.
Its cleanup should be verified through the final Transaction Result, including refunds and removal of residual authority.
Key Takeaway
A temporary account isolates short-lived activity, but its assets, permissions, and cleanup must be controlled through an explicit lifecycle.
Sources
- Solana Accounts — Solana Foundation (2026-08-02)
- Solana Programs — Solana Foundation (2026-08-02)
- Ethereum Transactions — Ethereum.org (2026-08-02)