> 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/agent-to-pact-gate-to-execution.md). # Agent to Pact Gate to Execution ## Agent to Pact Gate to Execution An autonomous trade begins with an agent's intent. That intent moves to Pact Gate, where RWAPACT coordinates the required checks before the request can receive execution authorization. ``` Agent -> Trade Intent -> Pact Gate -> Execution Authorization -> Execution Layer ``` Pact Gate does not execute the transaction. It coordinates the Five-Layer Pact so the protocol can determine whether execution is permitted. ### Trade intent enters the Pact The process starts when an autonomous agent proposes a trade. The intent provides the context needed to evaluate the requested action, including the asset, amount, agent identity, session context, and execution request. This is a conceptual representation of the request. It does not define a formal trade-intent structure. The essential boundary is that the agent proposes the action, but does not bypass the decision layer simply by producing a valid request. ### Pact Gate coordinates the request Pact Gate receives the request as the orchestration point for the decision flow. It connects the required components before execution authorization. Pact Gate is not an independent risk engine. It coordinates risk evaluation from KRO, session authority from KSO, policy enforcement from KPV, and gas and execution-path conditions from KGR. The resulting outcome is then recorded through KAR. ### Risk, session, and policy checks The first authorization dimensions evaluate distinct questions about the trade: ``` Trade Intent -> KRO: Risk Check -> KSO: Session Check -> KPV: Policy Check ``` KRO asks whether the trade is within acceptable RWA risk conditions. KSO asks whether the agent is authorized to perform this action in the current session. KPV asks whether the asset, amount, and trade conditions comply with the configured policy. None of these checks replaces the others. An acceptable risk result does not establish the session's authority. A valid session does not allow an asset or amount outside policy. Pact Gate coordinates these distinct checks as parts of the same authorization decision. ### Gas and execution conditions KGR evaluates gas and execution-path conditions before authorization. The protocol design identifies gas price monitoring, delay windows, batch execution, alternative execution paths, and L2 fallback where available as strategies that can inform this evaluation. KGR does not independently change the authorization model or guarantee gas savings. Its output contributes to the Pact's decision about whether the current execution conditions are sufficiently optimized for the requested trade. ### Decision and attestation After the required checks, the Pact reaches an authorization outcome. If the conditions pass, the request receives execution authorization. If a required condition fails, the Pact rejects the request. KAR records the decision and relevant context for both paths. **Approval** ``` Trade Intent -> Checks Pass -> Authorization -> KAR Attestation -> Execution ``` **Rejection** ``` Trade Intent -> Check Fails -> Rejection -> Reason Code -> KAR Attestation -> No Execution ``` Rejection is a normal protocol path. It means the proposed trade did not satisfy the conditions required for authorization. No execution occurs without an approved outcome. ### Execution after authorization Execution takes place outside the Pact decision layer. Depending on the integration, an authorized request can proceed toward Uniswap v4, MCP execution, or a Robinhood API path. These are examples from the protocol design, not statements of deployed integrations. The whitepaper describes a Uniswap v4 hook architecture as a concrete mapping of this boundary: ``` Agent calls pool.swap() -> Hook.beforeSwap() -> KRO -> KSO -> KPV -> KGR -> If all pass, allow swap -> Hook.afterSwap() -> KAR records attestation with execution txHash ``` This flow describes the specified hook architecture. Other execution paths need not follow the same mechanics. In every case, the architectural distinction remains: the Pact decides whether the requested trade satisfies the protocol conditions, while the execution layer determines how an authorized trade is technically executed. ### Post-execution context KAR can preserve the execution transaction hash after execution. The broader attestation context can include an attestation ID, agent ID, session ID, asset, amount, risk score, policy version, gas route hash, approval status, rejection reason, timestamp, and execution transaction hash. This information links the authorization outcome to the execution result where execution occurs. It provides lifecycle context without making KAR an execution engine or a replacement for the execution transaction. ### Full lifecycle The complete request path is: ``` Agent | v Trade Intent | v Pact Gate | v KRO: Risk | v KSO: Session | v KPV: Policy | v KGR: Gas / Execution Conditions | v Decision | +--> Reject -> Reason Code -> KAR | +--> Approve -> KAR -> Execution Layer | v Execution Tx | v KAR updated with execution txHash ``` The Pact decides whether the requested trade satisfies the protocol's conditions. The execution layer decides how the authorized trade is technically executed. RWAPACT does not become the exchange, broker, custodian, wallet, or autonomous agent. The next architectural topic is [On-Chain and Off-Chain Components](/whitepaper/system-architecture/on-chain-and-off-chain-components.md), which examines how protocol components and supporting infrastructure divide responsibilities. --- # 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/agent-to-pact-gate-to-execution.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.