feat(recurring): add 0.2.0 types and batch trigger helpers

[LeoSlrRf]

Add ERC20 Recurring Payment Proxy v0.2.0 Support

Introduces support for the 0.2.0 version of the ERC20RecurringPaymentProxy, which introduces batch-based recurring payment scheduling via triggerRecurringPaymentBatch.

Changes

• Added encodeRecurringPaymentTriggerBatch to encode triggerRecurringPaymentBatch calldata using the 0.2.0 ABI without requiring a deployed proxy address.
• Added triggerRecurringPaymentBatch to send a triggerRecurringPaymentBatch transaction to the 0.2.0 proxy.
• Added optional version parameter to getRecurringPaymentProxyAddress, encodeSetRecurringAllowance, and getPayerRecurringPaymentAllowance to allow callers to target a specific artifact version.
• Introduced SchedulePermitBatch and SchedulePermitLeg types representing the 0.2.0 permit structure, along with SCHEDULE_PERMIT_BATCH_EIP712_TYPES containing the EIP-712 type definitions with field order matching the contract.
• Added helper functions getRecurringPaymentProxyInterface and connectRecurringPaymentProxy to reduce duplication when resolving versioned artifacts.
• Added tests covering the new 0.2.0 functions, including encoding validation, address resolution, transaction dispatch, and error handling.

[LeoSlrRf]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat(recurring-payment): contract deployment #1767
• feat(recurring): add 0.2.0 admit and revoke cycle helpers #1766
• feat(recurring): add 0.2.0 cancel, hash, and sign helpers #1765
• feat(recurring): add 0.2.0 types and batch trigger helpers #1764 👈 (View in Graphite)
• feat: ERC20RecurringPaymentProxy batch schedule v0.2.0 #1763
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Greptile Summary

This PR adds the shared 0.2.0 recurring-schedule permit types and helpers for encoding and submitting batch triggers. The encoding contract is aligned with the 0.2.0 ABI, but direct submission currently cannot resolve a deployed 0.2.0 proxy.

• Adds SchedulePermitBatch, leg types, and matching EIP-712 definitions.
• Adds explicit artifact-version selection to recurring allowance, approval, and address helpers.
• Adds 0.2.0 batch-trigger calldata encoding and signer submission.
• Extends recurring-payment tests for version selection, encoding, and submission behavior.

Confidence Score: 4/5

The PR should not merge as a usable batch-trigger feature until a 0.2.0 deployment can be resolved or the unavailable submission helper is withheld.

The calldata and shared types align with the contract, but every call to the new submission helper fails during address lookup because the selected 0.2.0 artifact has no network deployments.

Files Needing Attention: packages/payment-processor/src/payment/erc20-recurring-payment-proxy.ts

Important Files Changed

Filename	Overview
packages/payment-processor/src/payment/erc20-recurring-payment-proxy.ts	Adds version-aware proxy helpers and batch triggering, but the submission path always fails because 0.2.0 has no deployments.
packages/types/src/payment-types.ts	Adds batch permit and EIP-712 definitions that match the 0.2.0 Solidity structs, type hashes, and ABI.
packages/payment-processor/test/payment/erc-20-recurring-payment.test.ts	Covers encoding and mocked submission, but the mocked address hides the absence of every real 0.2.0 deployment.

Sequence Diagram

sequenceDiagram
    participant App
    participant Helper as triggerRecurringPaymentBatch
    participant Artifact as ContractArtifact
    participant Signer
    App->>Helper: trigger permit batch
    Helper->>Artifact: getAddress(network, "0.2.0")
    Artifact-->>Helper: throw No deployment for network
    Note over Helper,Signer: sendTransaction is never reached

Loading

_{Reviews (1): Last reviewed commit: "feat(recurring): add 0.2.0 types and bat..." | Re-trigger Greptile}

[greptile-apps]

Batch proxy has no deployment

When triggerRecurringPaymentBatch is called with any supported network, it unconditionally resolves version 0.2.0, whose artifact has an empty deployment map, so address lookup throws No deployment for network: <network> before sendTransaction and the new submission helper cannot trigger a payment.

Knowledge Base Used:

• Payment processing
• Blockchain execution