> For the complete documentation index, see [llms.txt](https://docs.t-rex.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.t-rex.network/guides/journeys/j5.-offboarding-journey-an-investor-that-must-no-longer-hold-or-receive.md).

# J5. Offboarding journey: an investor that must no longer hold or receive

Offboarding removes a holder from an asset. The persona is the Issuer, acting through its agents, when an investor has to leave: the investor no longer meets the terms of the asset, a sanction applies, the relationship ends, or a decision of an authority orders it. The journey starts with a holder that has a position and can still act. It ends when the position has been moved or redeemed and the holder cannot come back in. The protocol has no single "remove an investor" call: offboarding is a short sequence of existing operations.

## Stages

| # | Stage                                     | Flow                                                                                                                                              | Who acts     | Outcome                                                                                                                                         |
| - | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | Immobilize what is on the reference chain | [13 Freeze and unfreeze an address or a partial balance](/guides/agents/13.-freeze-and-unfreeze-an-address-or-a-partial-balance.md)               | Token Agent  | Each address of the holder on the reference chain neither sends nor receives                                                                    |
| 2 | Bring back what is on satellites          | [32 Recall a position to the reference chain](/guides/cross-chain/32.-recall-a-position-to-the-reference-chain.md)                                | Token Agent  | The whole position is on the reference chain, at frozen addresses. Only when part of it is active on a satellite                                |
| 3 | Move or redeem the position               | [14 Execute a forced transfer](/guides/agents/14.-execute-a-forced-transfer.md) or [09 Burn a position](/guides/positions/09.-burn-a-position.md) | Token Agent  | The holder's balance is zero                                                                                                                    |
| 4 | Close the way back in                     | [19 Revoke a claim](/guides/claim-issuer/19.-revoke-a-claim.md)                                                                                   | Claim Issuer | The identity is no longer eligible, for this asset and for every asset that relied on the claim. When the fact behind the claim no longer holds |

## Overview

```mermaid
flowchart LR
    S1["1. Freeze every address<br/>13"] -.-> S2["2. Recall from satellites<br/>32"]
    S1 --> S3["3. Forced transfer or burn<br/>14, 09"]
    S2 -.-> S3
    S3 --> S4["4. Claim revoked<br/>19"]
```

## What the persona sees and does

**1. Immobilize what is on the reference chain.** The Issuer has decided that the investor leaves. A holder that became ineligible can still send its tokens to an eligible recipient, so the first act is a freeze. The agent lists every address the holder's identity uses for this asset on the reference chain: the ONCHAINID itself, its linked wallets and any address registered for it. It freezes each address entirely, in one batch. From that moment the holder neither sends from them nor receives on them. The tokens are still the holder's. A freeze does not reach a position that is active on a satellite.

**2. Bring back what is on satellites.** If part of the position is active on a satellite, the agent orders a recall. The position is burned there and returns to the holder's address on the reference chain, where the freeze of stage 1 now holds it. Until the recall is executed, that part can still move on the satellite under a validation already issued. A forced recall can fail when the tokens have left the wallet in the meantime: the register records where they went, and the agent follows them.

**3. Move or redeem the position.** The Issuer decides what becomes of the tokens, under the terms of the asset and the decision that orders the exit. When the investor is paid out, the agent burns the position once the redemption is settled. When the position goes to someone else, for example a buyer or a liquidator, the agent forces a transfer to that recipient, which must be eligible. Both operations go through the freeze of stage 1 and release the frozen tokens they need. Neither needs a signature from the holder. The agent keeps the record of the decision.

**4. Close the way back in.** A freeze keeps an address out. It does not make the investor ineligible: eligibility belongs to the identity, and comes from its claims. If the fact a claim attests is no longer true, the Claim Issuer that signed it revokes it. From the next check, the identity can no longer receive this asset or any asset that relied on that claim alone. The Issuer cannot revoke a claim it did not sign. It informs the Claim Issuer, under their agreement.

## Where journeys diverge

* **The investor leaves willingly.** It sells or redeems under the normal flows, [10](/guides/positions/10.-transfer-between-investors.md) or [09](/guides/positions/09.-burn-a-position.md). No freeze and no forced transfer are needed.
* **The investor lost eligibility and the Issuer accepts that it stays.** Nothing is done. The holder keeps its position, can still send to an eligible recipient and cannot receive.
* **The fact behind the claim still holds.** The investor stays eligible in general and only this Issuer excludes it. The Claim Issuer has no reason to revoke, and stage 4 does not apply. The Issuer keeps the investor's known addresses frozen. A freeze is on addresses, so it does not hold against an address the investor links later. Holding an exclusion against the identity itself takes a compliance module that keeps a list of excluded identities for the token. No such module ships with the protocol, and one can be written on the module interface.
* **The Issuer no longer trusts the Claim Issuer itself.** That is a different operation with a different scope: it affects every investor that relied on that issuer for this asset: [20](/guides/issuer/20.-remove-a-trusted-claim-issuer.md).
* **Addresses were registered for the holder by an agent.** Removing those registrations is housekeeping, not exclusion: it gives no guarantee that an address stops receiving, and it applies to every asset that shares the identity storage. See [18](/guides/agents/18.-remove-an-investors-registration.md).
* **The wallet is compromised and the investor stays.** This is not an offboarding. The investor revokes the wallet, or an agent recovers the position: [23](/guides/identity/23.-revoke-a-wallet.md), [15](/guides/agents/15.-recover-a-position-from-a-lost-wallet.md).
* **The exclusion ends.** The agent unfreezes the addresses with [13](/guides/agents/13.-freeze-and-unfreeze-an-address-or-a-partial-balance.md). If a claim was revoked, a new claim is needed: a revoked claim is never valid again.

## Related journeys

* [J3 Transfer agent journey: operations on a live asset](/guides/journeys/j3.-transfer-agent-journey-operations-on-a-live-asset.md) : each agent operation on its own
* [J2 Investor journey: from onboarding to secondary transfer](/guides/journeys/j2.-investor-journey-from-onboarding-to-secondary-transfer.md) : the path this journey reverses


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.t-rex.network/guides/journeys/j5.-offboarding-journey-an-investor-that-must-no-longer-hold-or-receive.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.