> For the complete documentation index, see [llms.txt](https://docs.most.wtf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.most.wtf/developers/developer/end-to-end.md).

# End To End

1. The user creates an intent using the Escrow smart contract on the source chain.
2. A hash of the intent details is stored in `orderStatus`.
3. An `OrderPlaced` event is emitted.
4. The Operator service, listening for the `OrderPlaced` event, detects the new intent.
5. The Market Maker (MM) calls the `mostFulfillOrders` function on the PaymentRegistry smart contract on the destination chain, using details from the `OrderPlaced` event.
6. The PaymentRegistry contract records the transaction details and transfers the funds to the user on the destination chain.
7. The Operator service, listens for the `FulfillmentReceipt` event from the PaymentRegistry contract.
8. Once the `FulfillmentReceipt` event is detected, the MM can either begin the proof process immediately or wait for better gas prices and batch proof their intent fulfillments.
9. When the proof process begins, the Operator service gathers data specifying which intent is being proved.
10. The Operator service forwards the data for the intents claimed as fulfilled back to the Escrow smart contract, which sends the data to an HDP module that calculates which storage slots in the `PaymentRegistry` smart contract certify intent fulfillment.
11. The HDP module verifies that the storage slot for each order hash stores a non-zero `bytes32` (the MM’s source address). If so, the module output is validated by Escrow and the funds are released to the MM.