When Is a Session Key Really Revoked? Design Wallet Status Around Expiry and Chain State

A wallet’s “Disconnect” button can remove a website from the screen while a previously granted session remains usable. The user may reasonably interpret the disappearance as the end of authority. The application may mean only that it stopped exchanging messages with the site. That mismatch becomes consequential when a delegated signer can act without a fresh interactive signature.

The product question is narrow: what has to happen before the wallet can truthfully say that a session has ended? Answering it requires a lifecycle, an enforcement location, and evidence about the state of that enforcement location. A label cannot supply the underlying guarantee.

The design below uses a hypothetical smart account with a dedicated session-policy module. It is a proposed product and implementation model, not a claim about any deployed wallet. Documentation was checked for the October 10, 2026 cutoff. ERC-4337 documentation explicitly describes session delegation as wallet-specific; ERC-7715 is identified as a draft, and its interface should not be read as universal deployed behavior. Session keys and delegation, ERC-7715 draft.

Phase one: establish what the permission identifies

The hypothetical wallet creates a grant identified by an account, chain, policy identifier, signer, and generation number. The grant permits a defined application action and has a specified expiry. The generation distinguishes the current grant from an earlier grant that happened to use the same signer.

That identity is a proposed design choice. Its purpose is to make revocation target a concrete authorization object rather than a vague relationship with a website. One site can have several grants; one signer can participate in several contexts. A “revoke this site” action needs to say which of those contexts it covers.

The grant record should identify the enforcing account or module. A user-facing name such as “Game session” is helpful, but it cannot substitute for the chain and account that make the rule effective. A mobile wallet can display the same app on two networks while the permissions remain separate.

Expiry belongs in the actual enforceable policy. If the wallet merely promises to delete a browser key at midnight, another copy of that key may remain valid. A timestamp shown in the interface should correspond to a documented check in the authorization path. If the implementation supports only local expiry, describe that narrower behavior explicitly.

ERC-4337 defines account validation and time-range information for UserOperations. It does not prescribe a universal session-policy registry or revocation function. The wallet-specific module must connect its grant to those mechanics, and the deployed version must be examined for the promised behavior. ERC-4337 account interface.

A useful grant screen therefore states the account, network, application, expiry, and the action that ends authority early. The engineering requirement behind the screen is traceability: every displayed claim should map to an enforcement object and an observable state. Without that mapping, the settings page becomes a collection of promises that the runtime cannot verify.

Phase two: keep local interaction separate from authority

An active session has at least two dimensions. The wallet can be connected to the application, and the grant can remain authorized. Those dimensions need not move together. A network interruption ends communication while leaving authorization intact. A revocation can end authorization while the application page stays open.

A proposed state model records the authorization state separately from connection status. The page can say “Disconnected; permission remains active until 18:00” or “Connected; this session no longer has permission.” Such language may feel less elegant than a single green dot, but it gives the user an accurate action to take.

The table is a design specification, not standardized ERC status vocabulary. Different wallets may choose different internal states, but collapsing submitted and confirmed produces a predictable misunderstanding. A transaction identifier is evidence of a request, not necessarily evidence of its effect.

The disconnected state should preserve access to permission management. A user should not have to reopen the granting website to revoke authority. If the wallet does not support independent revocation, it should expose that limitation at grant time rather than reveal it after the user wants to leave.

Local key deletion can complement revocation by stopping that device from signing more operations. It does not establish what other devices, services, or earlier copies can do. Treat it as a local action with its own result. The interface can combine local deletion and onchain revocation in one flow while continuing to report their different completion states.

Phase three: translate expiry across three clocks

Expiry has a display clock, an enforcement clock, and an observation clock. The display clock is the device’s local time. The enforcement clock is the time basis used by the deployed policy and execution path. The observation clock is the wallet’s latest reliable view of chain state.

For the hypothetical wallet, the policy uses a timestamp condition enforced onchain. The interface converts that timestamp into the user’s time zone and shows an absolute time alongside a countdown. The countdown is convenience; the enforceable timestamp is the underlying condition. A device clock that runs fast should not become the security boundary.

Suppose the session expires at 18:00 according to its policy. At 17:59:50, the application prepares an operation. At 17:59:55, an infrastructure service accepts it for processing. At 18:00:10, a block includes the relevant execution attempt. The result depends on the implementation’s validity checks at the relevant stage, not merely on when the user pressed a button.

ERC-4337 specifies validity ranges and bundler handling of operations likely to expire before inclusion. The designer still needs to verify how the wallet’s session expiry feeds those checks and which deployed EntryPoint version it uses. A successful earlier simulation is not an unconditional promise of later inclusion. ERC-4337 simulation.

The proposed interface can stop initiating new session actions shortly before expiry to reduce avoidable failures. That is a usability buffer, not an extension of permission. If the product chooses a thirty-second buffer, it should be described as a product policy and evaluated against actual network behavior rather than presented as a protocol constant.

When the wallet cannot refresh chain state, an elapsed local countdown supports an estimate but not every possible status claim. “Expiry time reached; verification unavailable” is more precise than implying that all pending actions were canceled. The user may need to wait for an outcome or inspect an operation separately.

Phase four: make early revocation an observable transition

In the proposed module, revocation changes the grant’s generation or marks its identifier inactive. Subsequent authorized uses check that state. The owner’s action must reach the enforcing chain state before the wallet announces confirmed revocation.

This example deliberately assumes a module with an owner-authorized revocation operation. Other implementations may use signed permission tokens, module removal, delegation managers, or different state. ERC-7579 specifies modular account interfaces, including module installation and removal, but it does not make every module expose the same session lifecycle. ERC-7579 modular accounts.

The flow can distinguish request creation, user authorization, submission, inclusion, and the wallet’s chosen confirmation threshold. These phases answer different questions. Was the user’s request recorded? Was the request signed? Was it sent? Did it change state? Is the wallet ready to rely on that observed state?

If submission fails, keep the session visible as active or uncertain according to current evidence. Removing it from the list while displaying a small error elsewhere invites the user to believe it has ended. The failed action should remain attached to the grant whose authority is unresolved.

If the owner lacks funds or sponsorship for the revocation path, the product must provide a concrete recovery path appropriate to that implementation. The issue is especially important when the session itself had sponsored actions: the user may never have funded the account in the gas asset. Sponsorship of ordinary actions does not establish sponsorship of revocation.

A confirmation policy should be stated at the level the product can support. Some applications may rely on observed inclusion; others require additional confidence before a high-value status changes. The article does not propose one universal number of confirmations across networks. It proposes that the visible state correspond to the actual policy and that reversals of observed state be handled explicitly.

Phase five: reason about actions already in flight

Revocation limits authority according to an ordering of state changes. It does not automatically undo a transaction that completed earlier. The wallet should separate “can this key authorize another eligible action?” from “did every action already submitted stop?”

Consider operation S using the session and operation R revoking it. If S executes before R changes the relevant enforcement state, the action may complete under the previously valid policy. A completed purchase is not canceled just because permission later ends. The user’s settings screen and activity screen should reflect that distinction.

A subtler case appears when validation and execution are separate stages. ERC-4337 describes a verification loop and an execution loop. In a hypothetical bundle, S could validate while the grant is active, R could later execute, and S could execute after that state change. Whether S is stopped depends on the account and module’s actual execution checks. ERC-4337 EntryPoint functionality.

The proposed module’s strongest lifecycle promise would require relevant permission state to be checked at the point needed to enforce that promise. That may include an execution-time check rather than relying only on an earlier validation. This is a design requirement to investigate in code, not a claim that all ERC-4337 wallets already provide it.

The product can define a narrower guarantee if the implementation cannot enforce the stronger one. For example, it may explain that revocation blocks newly validated operations while previously accepted operations can remain in flight. Such wording must match the actual runtime; it should not be chosen merely because it is easier to display.

This race deserves a targeted test with controlled operation ordering. A test that revokes a grant, waits, and then sends a new request verifies the easy case. It does not establish the outcome when revocation and use share a bundle or overlap between validation and execution. The lifecycle claim should be based on the cases that could invalidate it.

Phase six: discover what authority survives the session

A session can create effects outside its own policy. Suppose an authorized action grants a token allowance to a spender. Ending the session blocks future use of that session key, but the previously created token allowance is a separate piece of state. ERC-20 defines approval and delegated transfer behavior at the token contract. ERC-20 allowance semantics.

In the hypothetical wallet, the session is allowed to purchase one item through a merchant contract. If the purchase path first grants a large token allowance, the merchant’s authority can outlive the session. A screen saying “all access removed” after session revocation would overstate the result unless the wallet also addressed that allowance.

The same reasoning applies to application state. A session might create an order, enroll in a recurring arrangement, or deposit assets into a contract. Those objects can have their own cancellation or withdrawal methods. Session expiry does not imply that every earlier object expires with it.

The permission review should therefore identify persistent effects the allowed actions can create. This is more specific than a broad warning that smart contracts are risky. The user needs to know which downstream authority or commitment remains and whether the wallet can help end it separately.

A proposed revocation screen can group the current session and known persistent effects without combining their states. “Session revoked” can sit beside “Token allowance remains active” and “Order already completed.” The distinct labels make it possible to take the next relevant action without suggesting that one operation reverses the entire history.

Complete discovery may be difficult. A wallet should not assert that no persistent effect exists merely because its indexer did not find one. It can show effects it observed from session activity and explain the coverage of that view. For a narrow application integration, designing allowed calls to avoid broad persistent approvals can reduce this ambiguity before the grant is ever created.

Phase seven: treat a renewed session as a new authorization

A user may want to continue after expiry. Renewal should create or update an explicitly identified grant under a documented policy. The application should not silently reinterpret an old expiry as permission to extend itself.

In the proposed generation-based module, renewal creates a new generation with a new expiry. Old signatures remain tied to the old generation. That prevents a revoked historical authorization from becoming valid again merely because the same signer is reused. Whether a real module provides that property depends on its signed data and state checks.

Reusing a signer can be convenient for a device, but it also makes the interface’s labels important. “Renew session” should show the new expiry and any changed authority. If the requested action set expands, it is a changed grant requiring the corresponding user decision, not merely more time on the same arrangement.

The wallet should retain enough history to distinguish expired, revoked, and replaced grants. A current-session list can remain short while a detail view explains why an earlier signature is no longer eligible. That history helps resolve support questions without requiring the user to interpret raw contract events.

Automatic renewal adds another policy question. If the wallet has permission to renew based on a standing owner instruction, the user should be able to inspect and revoke that standing instruction. Otherwise, revoking individual sessions can become a loop in which the application immediately creates a replacement. Termination should reach the authority that creates new grants, not only the latest child object.

The narrow lifecycle lesson is to identify the parent decision. Ending a generated session and ending the authorization to generate sessions are different transitions. A well-designed permission manager makes that relationship visible instead of scattering it across application-specific settings.

Phase eight: keep network coverage explicit

The same account address can appear on several networks while permission state differs. A revocation observed on one network should not be displayed as completion on every network unless the implementation actually coordinates that effect.

For the hypothetical wallet, each chain has its own grant record and enforcement state. A global “revoke application” action creates a group of chain-specific tasks. The interface can show two confirmed, one pending, and one failed. This preserves the convenience of one action while making incomplete coverage visible.

A chain-specific failure should not make confirmed revocations disappear or imply that nothing happened. Conversely, partial success should not produce an unqualified “revoked everywhere” banner. The aggregate result can state “Revoked on two of four networks” and keep the unresolved grants accessible.

Account upgrades introduce a related boundary. A new implementation may change where session policy is checked or how grants are interpreted. Before preserving old grants across an upgrade, the wallet should establish that their expiry and revocation meanings remain compatible. If it cannot, requiring fresh authorization may be clearer than carrying forward an uncertain lifecycle.

The supported interface also matters. ERC-7715’s draft includes methods for requesting, discovering, and revoking execution permissions, with supported types and rules. A wallet’s advertised support must still be evaluated for the particular chain, permission type, and enforcement implementation. A familiar JSON-RPC method name does not establish identical guarantees across wallets. ERC-7715 permission discovery and revocation.

This is why the article avoids providing a universal revocation call that supposedly ends every session. The integration should discover supported capabilities, bind them to an actual grant, and document the returned completion semantics. That specific contract is what the product’s status labels can truthfully describe.

Phase nine: make failures legible on a small screen

A permission screen is often used when the user is worried or hurried. Its first line should state the current evidence: active, pending termination, confirmed termination, expired, or unavailable. The next line can explain what action remains possible.

If the chain connection is unavailable, show the last verified state and its observation time. “Last checked active at 16:42” is useful evidence. An endlessly spinning loader provides neither evidence nor a safe conclusion. It can also hide the fact that the device stopped signing locally while onchain authority remains unresolved.

If revocation requires another owner device, say so in the same flow. A user who lost that device needs the wallet’s actual recovery path, not a repeated prompt that cannot succeed. Recovery is implementation-specific, so the interface must link to the mechanism it supports rather than imply that every smart account has the same fallback.

Use action labels that describe effects. “Stop on this device” differs from “Revoke on this network.” “Cancel pending order” differs from “End session.” Users can understand these distinctions when the product presents them at the point of action, especially with a short explanation of what remains.

The interface should also preserve unsuccessful attempts. A failed revocation can show a retry action and a reason, while leaving the grant visible. If the failure is insufficient funds, network unavailability, or unsupported revocation, those outcomes require different recovery. One generic “try again later” message wastes attention and can leave authority active longer than the user realizes.

Accessibility matters in the status model. Color alone should not distinguish active from revoked. A countdown should not be the only expression of expiry. The text can provide the absolute expiry time, network, and status so that users of assistive technology receive the same lifecycle information.

Phase ten: prove the lifecycle claim, then choose the label

Validation should start with the exact termination promise. For the proposed wallet, the team might require that a revoked generation cannot authorize a new action through any supported session path. The test population must then include those paths, not merely the application’s most common button.

Exercise expiry boundaries using the implementation’s actual time basis. Prepare before expiry and include after it. Try an old grant after renewal. Attempt a session use while revocation is pending. Test the same-bundle ordering case where the enforcement design permits it. Each scenario asks a different lifecycle question.

Check persistent effects separately. Create an allowance through an allowed session action, revoke the session, and observe whether the allowance remains. The expected result may be that it does remain; the product test then verifies that the screen reports it accurately and offers the separate supported action.

Test unavailable observations and partial network success in the interface. The wallet should preserve the last known evidence without turning it into a current certainty. A resumed connection should reconcile submitted requests with actual enforcing state rather than assuming that every old request completed.

The final product label follows the tested guarantee. “Revoked” should mean the relevant authority has ended under the stated policy. “Submitted” should remain a pending event. “Expired” should identify the policy boundary without claiming to reverse completed actions. These words are small, but they carry the wallet’s most important promise: the user can tell when another signer can still act on their account.

Sources

• ERC-4337: Account Abstraction Using Alt Mempool, validation, validity ranges, and execution ordering.
• ERC-4337 documentation: Session Keys and Delegation, wallet-specific session implementations.
• ERC-7715: Request Permissions from Wallets, draft permission and revocation interface; not a universal implementation guarantee.
• ERC-7579: Minimal Modular Smart Accounts, modular-account interfaces and authorization considerations.
• ERC-20: Token Standard, token approval and delegated transfer semantics.