> For the complete documentation index, see [llms.txt](https://rwapact.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rwapact.gitbook.io/whitepaper/system-architecture/trade-lifecycle.md). # Trade Lifecycle ## Trade Lifecycle A trade does not move directly from agent intent to execution. It moves through evaluation, authorization or rejection, execution, and attestation. ``` Trade Intent -> Pact Evaluation -> Authorization or Rejection -> Execution -> Attestation ``` ### Trade intent The lifecycle begins when an autonomous agent submits a trade request. The request provides the context needed for evaluation, such as agent identity, session, asset, amount, and requested execution. The agent proposes the action. RWAPACT evaluates whether that action can proceed. ### Risk evaluation KRO evaluates RWA-specific risk during the decision flow. Its evaluation can account for oracle staleness, price deviation, liquidity depth, slippage, market hours, compliance freeze, concentration, and volatility. This stage produces risk context for the Pact. It does not authorize the trade on its own. ### Session validation KSO checks that the session is active, current, and authorized for the proposed action. It verifies the session time window, remaining budget, asset scope, permitted trade size, revocation status, and matching agent identity. If the session fails validation, the trade cannot continue to execution authorization. ### Policy evaluation KPV applies the active policy to the requested trade. Policy conditions can cover the allowed asset, maximum trade size, daily limit, concentration, maximum slippage, oracle freshness, minimum liquidity, market-hours permission, and maximum risk score. If a required policy condition fails, the trade does not proceed to execution authorization. ### Gas and execution conditions KGR evaluates gas and execution conditions before the decision is finalized. Its role includes gas monitoring, delay windows, batch execution, alternative route comparison, and L2 fallback where available. Gas optimization is part of the protocol's decision context. It does not guarantee a particular execution cost or outcome. ### Decision Pact Gate combines the required checks into one outcome: ``` Can_Trade = KRO risk below threshold AND KSO session active and in scope AND KPV policy allows asset and amount AND KGR gas conditions are optimized ``` When all required conditions pass, execution is authorized. When any required condition fails, the trade is rejected with a reason code. [Pact Decision Logic](/whitepaper/the-rwapact-protocol/pact-decision-logic.md) describes this decision model in detail. ### Attestation KAR records the decision and its relevant context. The record can include the attestation ID, agent ID, session ID, asset, amount, risk score, policy version, gas route hash, approval status, rejection reason, timestamp, and execution transaction hash. The attestation preserves the decision context. A transaction hash can be associated after an authorized trade executes. ### Execution Only an authorized trade reaches the execution layer. The specified execution environments include Uniswap v4, MCP execution, and the Robinhood API. Each path has its own execution interface. After execution, the execution transaction hash can be associated with the attestation. ### Approval lifecycle ``` Agent | v Trade Intent | v KRO Risk | v KSO Session | v KPV Policy | v KGR Gas | v Authorization | v KAR Attestation | v Execution | v Execution Transaction | v KAR records executionTxHash ``` ### Rejection lifecycle ``` Agent | v Trade Intent | v Required Check Fails | v Rejection | v Reason Code | v KAR Attestation | v No Execution ``` Rejection is a valid protocol outcome. It records that the proposed action did not satisfy a required condition, and no execution is forwarded. ### Example: risk-based rejection An agent requests a tokenized stock trade. KRO determines that the risk score exceeds the configured threshold. The Pact rejects the trade. KAR records the agent, session, asset, amount, risk score, policy version, rejection reason, and timestamp. No execution transaction occurs. If all required checks pass instead, the Pact authorizes the trade and the selected execution layer can perform it. ### Lifecycle takeaway The lifecycle separates four responsibilities: ``` Intent -> Decision -> Execution -> Attestation ``` The agent proposes. RWAPACT evaluates and authorizes or rejects. The execution layer performs an authorized transaction. KAR preserves the resulting decision context. [Execution-Layer Agnosticism](/whitepaper/system-architecture/execution-layer-agnosticism.md) explains why this lifecycle does not depend on one execution environment. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://rwapact.gitbook.io/whitepaper/system-architecture/trade-lifecycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.