Summary
The docs describe RitualWallet's prepaid deposit / fee-lock-at-submission mechanism, but don't specify which address the fee is actually deducted from when a contract (rather than an EOA directly) triggers the wallet flow.
Steps to reproduce
- Deployed a contract that interacts with RitualWallet on behalf of a user
- Observed that the fee deduction appears to apply to
tx.origin (the original EOA signer) rather than the calling contract's own balance
Expected behavior
Based on the "deposit RITUAL" framing in the docs, I expected the fee to be deducted from the contract's own RitualWallet balance if the contract itself initiated the call.
Actual behavior
Fee deduction appears to target tx.origin, which has implications for any contract design that relies on the calling contract paying its own way (e.g. relayers, meta-transactions, multi-step flows).
Ask
Could the team clarify the intended design here? If tx.origin-based deduction is intentional, documenting it explicitly would help developers avoid unexpected fee behavior in contract-to-contract flows.
Summary
The docs describe RitualWallet's prepaid deposit / fee-lock-at-submission mechanism, but don't specify which address the fee is actually deducted from when a contract (rather than an EOA directly) triggers the wallet flow.
Steps to reproduce
tx.origin(the original EOA signer) rather than the calling contract's own balanceExpected behavior
Based on the "deposit RITUAL" framing in the docs, I expected the fee to be deducted from the contract's own RitualWallet balance if the contract itself initiated the call.
Actual behavior
Fee deduction appears to target
tx.origin, which has implications for any contract design that relies on the calling contract paying its own way (e.g. relayers, meta-transactions, multi-step flows).Ask
Could the team clarify the intended design here? If
tx.origin-based deduction is intentional, documenting it explicitly would help developers avoid unexpected fee behavior in contract-to-contract flows.