feat: add executeGatewayMintWithMemo using Arc Transaction Memos

[consumeobeydie]

Summary

Adds an opt-in variant of executeGatewayMint that wraps the gatewayMint() call through Arc's predeployed Memo contract (announced June 18, 2026), so a Gateway mint can carry a structured, queryable reference — e.g. an invoice ID or settlement batch ID — for reconciliation.

What's included

• ARC_MEMO_CONTRACT_ADDRESS constant pointing to the predeployed Memo contract on Arc Testnet
• executeGatewayMintWithMemo() — same behavior as executeGatewayMint, but routes the call through callWithMemo(address,bytes,bytes32,string) so a Memo event is emitted alongside the mint
• The original executeGatewayMint is untouched; this is purely additive

Why this matters

Treasury and payment apps often need to tie an onchain mint/transfer back to an internal reference (invoice, batch, customer ID) for reconciliation. Transaction Memos let this happen at the call level without modifying the Gateway contracts or the existing executeGatewayMint flow.

How it works

The Memo contract preserves the original msg.sender via the CallFrom precompile and only emits the Memo event if the wrapped gatewayMint() call succeeds — giving a clean signal for reconciliation pipelines.

Verification

The callWithMemo signature and behavior were verified against a live transaction on Arc Testnet before this PR:

• Tx: https://testnet.arcscan.app/tx/0x7532ce470169e2db2be43e5f9c43dd523d21e9071c04268ff5941f8ca839ef7b
• Status: Success, confirmed in 0.58 seconds

Resources

• Arc Transaction Memos announcement: https://community.arc.io/home/blogs/arc-transaction-memos-structured-transaction-context-for-financial-workflows-on-arc-2026-06-18

[consumeobeydie]

Verification update

I tested callWithMemo through two paths on Arc Testnet:

1. EOA wallet, direct signed transaction (cast send) — succeeds:
https://testnet.arcscan.app/tx/0x7532ce470169e2db2be43e5f9c43dd523d21e9071c04268ff5941f8ca839ef7b

2. Circle Developer Controlled Wallet, via createContractExecutionTransaction — fails at the gas estimation step with ESTIMATION_ERROR / execution reverted, even with parameters identical to the successful EOA transaction above.

I also reproduced the estimation failure independently with cast call --from <address> (which performs an eth_call simulation, same as Circle's pre-flight estimation) against the same Memo contract — it reverts with empty revert data for any --from address, while cast send (no prior estimation) succeeds.

This suggests callWithMemo may not be fully compatible with standard eth_call/eth_estimateGas simulation as used by Circle's Developer Wallet SDK, even though the actual transaction executes successfully on-chain. This is worth flagging since executeGatewayMintWithMemo in this PR uses createContractExecutionTransaction, which performs this same estimation step — so this PR's new function may currently fail for Developer Wallets until that's resolved on the Memo contract or estimation side.

Marking this PR as a code contribution with a known limitation, documented for visibility. Happy to update if there's guidance on the correct way to estimate gas for CallFrom-based precompile calls.

[consumeobeydie]

Additional verification

I also tried overriding gasLimit manually (per the Circle docs note that gasLimit override is supported for EOA wallets):

gasLimit: '300000',
fee: { type: 'level', config: { feeLevel: 'MEDIUM' } },

Confirmed the wallet (0x8c4461...) is indeed an EOA (no bytecode at the address). The transaction still failed with the same ESTIMATION_ERROR / execution reverted, with the gasLimit override accepted into estimatedFee but the call still failing pre-flight.

This rules out gas limit as the cause and further confirms the issue is specifically Circle's eth_call-based pre-flight simulation being incompatible with callWithMemo's CallFrom-based execution path — not a wallet-type or gas-configuration issue.