> For the complete documentation index, see [llms.txt](https://dataipo.gitbook.io/dataipo-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-8-capital-execution-and-settlement.md).

# Chapter 8 — Capital Execution and Settlement

A single on-chain success covers one link of a full settlement. Capital execution manages intent, preconditions, authorization, the asset leg, the cash leg, external receipts, and the state update together.

## 8.1 Capital Execution Engine

The Capital Execution Engine receives validated intents, locks or verifies required state, calls on-chain contracts or external institutional systems, collects results, and produces auditable receipts. Its discipline comes from deterministic preconditions, minimal authorization, idempotent processing, failure isolation, external receipt binding, reconciliation, and recovery.

From intent to new state takes nine steps: intent creation → evidence and state locking → policy and eligibility checks → authorization confirmation → execution preparation (PCTEnvelope, idempotency\_key, nonce, expires\_at) → on-chain or external execution → receipt collection → reconciliation and condition evaluation → state update (SettlementReceipt and LifecycleEvent).

## 8.2 Settlement modes

| Mode                                       | Protocol requirement                                                              | Boundary                                                                   |
| ------------------------------------------ | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| On-chain atomic delivery                   | Asset leg and cash leg satisfy atomic conditions in one execution environment     | Asset rights and cash instruments must map validly into that environment   |
| On-chain coordinated DvP                   | Two verifiable legs lock, release by condition, and produce receipts              | Cross-network finality, bridging, and failure recovery governed separately |
| On-chain asset + external cash             | State updates after binding bank, payment, or custody receipts                    | Authenticity, delay, returns, and business hours of external receipts      |
| External asset + on-chain cash             | Registry, custody, or transfer confirmation matched against the cash result       | Legal transfer may complete later than the technical instruction           |
| Fully external settlement + on-chain audit | Protocol stores intent, authorization, both external receipts, and reconciliation | SimpleChain does not become a cash or securities settlement institution    |

## 8.3 SettlementReceipt and three finalities

SettlementReceipt contains at least execution\_id, settlement\_mode, asset\_leg, cash\_leg, onchain\_receipts, external\_receipts, resulting\_state\_change, parties, timestamps, and signatures. The receipt states which conditions are met, which remain pending, and when the state may move from pending to settled, failed, reversed, or disputed.

Technical, economic, and legal finality stay separate. Technical finality means the ledger record is confirmed by validator votes and hard to roll back (SimpleChain's fast path confirms in one round, see 4.2). Economic finality means funds or assets are actually usable and reconciliation is complete. Legal finality means transfer of rights, clearing, and clawback boundaries under applicable law. SettlementReceipt connects the three and keeps the basis and confirming party of each.

## 8.4 Failure, compensation, and retry

| Status             | Meaning                                                                | Next step                                               |
| ------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------- |
| prepared           | Evidence, policy, and authorization ready; not yet signed or submitted | Await designated approval or signature                  |
| submitted          | Instruction sent; result unconfirmed                                   | Monitor external or on-chain receipts                   |
| partially\_settled | Only part of a leg completed                                           | Pause new actions; enter reconciliation or compensation |
| settled            | Defined delivery conditions and reconciliation all met                 | Update asset state and the lifecycle ledger             |
| failed             | Execution produced no expected delivery                                | Record cause; decide retry or termination               |
| reversed           | A completed result formally returned, charged back, or revoked         | Generate the reverse event and new state                |
| disputed           | Result or receipt under a valid challenge                              | Limit dependent actions; start the dispute process      |

## 8.5 The lifecycle ledger

The lifecycle ledger connects onboarding, verification, structuring, approval, issuance or registration, subscription, transfer, performance, distribution, risk disposal, redemption, termination, and archiving to one Asset ID. It is a verifiable event graph: different assets, jurisdictions, and arrangements follow their own state paths while reusing one set of event and reference principles.

> **Settlement claim**
>
> An instruction counts as a complete settlement record only when the asset leg, the cash leg, formal account receipts, reconciliation, and the state update form one consistent body of evidence. On-chain success, funds received, and legal transfer each leave their own trail, and none can impersonate another.


---

# 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://dataipo.gitbook.io/dataipo-docs/whitepaper-center/simplechain-whitepaper/chapter-8-capital-execution-and-settlement.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.