Skip to main content

Company Deletion

This chapter describes the Core implementation of the company deletion lifecycle. The broader business and regulatory context is described in Termination of Cooperation (Offboarding).

The Core flow focuses on three system actions: marking a company for deletion, reversing a pending deletion, and finalizing deletion after the retention period has expired.

Business Flow​

  1. Mark for Deletion:

    • A company can be marked for deletion by its managing Broker Partner System or by a DEUSS Backoffice Administrator.
    • In the partner flow, the caller must be authenticated through mTLS and may act only on companies belonging to its own broker scope. In the admin flow, the Backoffice user must have the REGISTRY_MANAGER role.
    • The Registry Service verifies that the company is currently active from a deletion-state perspective (deletion_state = NONE) and then performs the Core-specific blocking checks: zero token balances including frozen amounts, no active marketplace offers or unresolved deals, and no pending or in-progress fiat payments linked to the company wallet.
    • If the checks pass, the company is moved to PENDING, a deletion_date is calculated from the configured retention period, and the action is audit logged.

  2. Temporary Operational Disablement:

    • After the company is marked for deletion off-chain, the Registry Service creates a chain_operations record for the on-chain status change.
    • JobRunnr processes this operation asynchronously and disables the company's on-chain identity by setting its entity status to DISABLED.
    • This prevents unauthorized business activity during the retention period and makes the company's pending deletion visible at the blockchain identity level.

  3. Reverse Deletion:

    • A pending deletion can be cancelled before the company reaches the final deletion stage.
    • The same authorization model applies: a broker may reverse deletion only for its own company, while a Backoffice administrator may reverse it through the admin flow.
    • Reversal is allowed only while deletion_state = PENDING. Once a company is ready for final deletion or already deleted, the process cannot be reversed.
    • When reversal succeeds, the Registry Service sets deletion_state back to NONE, clears deletion_date, logs the CompanyDeletionReversed event, and schedules an on-chain activation operation.
    • JobRunnr then restores the on-chain identity by setting the entity status back to ACTIVE.

  4. Final Deletion:

    • Final deletion is performed automatically by a scheduled system job after the regulatory retention period expires.
    • The job scans for companies with deletion_state = PENDING and deletion_date in the past. If no eligible companies exist, it ends without manual intervention.
    • For each eligible company, the system removes operational user links, such as the acting user relationship, and clears user references to the deleted company.
    • The company is then moved to DELETED and excluded from standard public API listings.
    • The final step is a state transition and relationship cleanup, not a destructive purge of historical Core records.

State Lifecycle​

Sequence Diagram​

Constraints and Failure Handling​

Deletion is rejected when the caller is not authenticated, does not have the required role, or attempts to act outside its broker tenant scope. It is also rejected when the company is not in the expected deletion state, for example when a deletion is requested for an already pending company or a reversal is requested after final deletion became irreversible.

Business constraints are checked before the company enters the retention period. Any remaining token balance, frozen amount, active marketplace exposure, unresolved deal, or pending payment blocks the deletion request until the obligation is resolved.

Blockchain execution failures are tracked through chain_operations. Temporary submission failures are retried by the background worker. If retries are exhausted or the transaction reverts on-chain, the operation is marked as failed and requires administrative follow-up.