doc

Author: Haypierre

README.md

@@ -43,7 +43,7 @@ The CABPaymaster fronts funds on the destination chain for the user if they _HAV
 
 The Paymaster contract will get repaid on the source chain(s). Ni1o: user has 100@A, 50@B, and spends 130@C
 
-- Set/update the Paymaster owner address (ecosystem *MUST* own the Paymaster)
+- Set & update the Paymaster owner address (ecosystem *MUST* own the Paymaster)
 - Withdraw Paymaster balance (Openfort crafts the transaction, but the ecosystem owner *MUST* sign it)
 - Ragequit > owner withdraw all funds from all Paymasters with one signature
 
@@ -58,11 +58,17 @@ As part of chain abstraction activation, an account registers a Paymaster Verifi
 
 ## Trust assumptions
 
-- The system relies on cross-L2 execution proofs currently provided by [Polymer](https://docs.polymerlabs.org/docs/build/examples/chain_abstraction/). This eliminates the need for Users to trust Openfort or the Ecosystem. To repay the ecosystem on the source chain(s) from the user assets locked in the vault(s), Openfort must prove the execution of the userOp on the destination chain. There is no refund on source chain without the corresponding remote chain execution proof. The `InvoiceManager` tracks invoices onchain to prevent double-refund.
-- The system supports [Hashi](https://crosschain-alliance.gitbook.io/hashi/introduction/what-is-hashi) as a fallback proving mechanism if Polymer or Openfort cease operations. Liquidity providers (LPs) can generate a proof for their fronted funds by running a [Hashi RPC API locally](https://github.com/gnosis/hashi/tree/main/packages/rpc#getting-started) and call the `fallbackRepay` function of the `InvoiceManager` with the proof and the invoice. This enables refunds using only public data, without relying on any third party. The fallback proving strategy may evolve, but it will always remain permissionless, as it ultimately determines the system's security.
+- The system relies on cross-L2 execution proofs currently provided by [Polymer](https://docs.polymerlabs.org/docs/build/examples/chain_abstraction/), eliminating the need for users to trust Openfort or the Ecosystem. To repay the ecosystem on the source chain(s) with user assets locked in vaults, Openfort must prove the execution of the userOp on the destination chain. No refund occurs on the source chain without a corresponding execution proof on the remote chain. The `InvoiceManager` tracks invoices onchain to prevent double-refund.
+- The system supports [Hashi](https://crosschain-alliance.gitbook.io/hashi/introduction/what-is-hashi) as a fallback proving mechanism if Polymer or Openfort ceases operations. Liquidity providers (LPs) first generate a proof for their fronted funds by running a [Hashi RPC API locally](https://github.com/gnosis/hashi/tree/main/packages/rpc#getting-started), which conveniently wraps [`eth_getProof`](
+https://github.com/ethereum/EIPs/issues/1186) for storage proofs or `eth_getTransactionReceipt` for events in the receipt proof. Then, they call the `fallbackRepay` function of the `InvoiceManager` with the proof and the invoice. This enables refunds solely using public data, without relying on any third party. The fallback proving strategy may evolve, but it will always remain permissionless, as it ultimately determines the system's overall security.
 - Openfort does not have custody of funds in the Ecosystem Paymaster, as the userOp is co-signed within a secure enclave that enforces predefined policies set by the ecosystem. At any time, the ecosystem can disable a signer, immediately preventing any new userOp from being sent.
 
-One of the system's key strengths is its modular approach to proof verification. State proofs will play a crucial role in Ethereum interoperability, with more proof providers emerging. The design allows for seamless integration of new proof verification strategies, giving advanced users the flexibility to choose the one that best suits their use case. With Polymer you get cheap and extremely fast proofs but you trust the sequencers, with Hashi you leverage multiple independent oracles to validate and verify block headers across different blockchain networks.
+
+A key strength of the system is its modular proof verification approach. With Ethereum interoperability advancing, more proof providers will emerge. The system’s design allows for seamless integration of new proof verification strategies, giving advanced users the flexibility to select the best fit for their use case. Polymer offers cheap and extremely fast proofs but requires trust in [sequencers](https://docs.polymerlabs.org/docs/learn/intro), whereas Hashi leverages multiple independent oracles to validate, verify, and relay block headers across different blockchains.
+
+
+The trade-off is between trustlessness and efficiency. Hashi prioritizes decentralization but incurs higher gas costs due to its thorough verification process, with block headers taking up to 24 hours to become available. This makes it a perfect fallback repayment methods but not a serious candidat for real world interop use cases. In contrast, Polymer is optimized for efficiency with near block time proof availability (2-3 seconds), making it the preferred choice for day-to-day operations. Over time, this trade-off may become more nuanced and users will be able to fine-tune the system according to their preferences.
+
 
 ![gas cost benchmark](./assets/benchmark.jpg)
 
@@ -75,3 +81,5 @@ One of the system's key strengths is its modular approach to proof verification.
 - All `Paymaster Verifiers`
 
 Check latest deployments in the [demo cli](demo/constants.ts).
+
+Curious about how it all came together? [Watch the full demo and dev story on YouTube](https://www.youtube.com/watch?v=L0Jmdw_XQX0).