callWithMemo reverts during gas estimation (eth_call) but succeeds with direct signed transaction

[consumeobeydie]

Summary

callWithMemo on the predeployed Memo contract (0x5294E9927c3306DcBaDb03fe70b92e01cCede505) reverts during gas estimation (eth_estimateGas / eth_call) but executes successfully when sent as a direct signed transaction.

Environment

• Network: Arc Testnet (Chain ID: 5042002)
• Memo contract: 0x5294E9927c3306DcBaDb03fe70b92e01cCede505
• SDK: viem v2.52.2
• Tool: Foundry cast

Reproduction

Fails (estimation):

cast call 0x5294E9927c3306DcBaDb03fe70b92e01cCede505 \
  "callWithMemo(address,bytes,bytes32,string)(bool,bytes)" \
  0xe81f5BA4181eA29061C3C229c8D6EB4cFE56639C \
  0xb7dc1284 \
  0xf02ff6783ff9bca82d31d52554ec1a67aafc314374620c489f58afe2d84326d2 \
  "test" \
  --rpc-url https://rpc.testnet.arc.network \
  --from 0x54b4B44749a95070560509B6Ec0be501665CcF63
# → execution reverted (empty revert data)

Succeeds (direct send):

cast send --private-key $KEY \
  0x5294E9927c3306DcBaDb03fe70b92e01cCede505 \
  --data 0xc3b2c4f8... \
  --rpc-url https://rpc.testnet.arc.network
# → status: 1 (success), Memo event emitted

Impact

Any library or SDK that estimates gas before sending (viem writeContract, Circle Developer Controlled Wallets createContractExecutionTransaction, ethers.js) will fail to call callWithMemo. Only raw signed transactions work.

Verified Successful Transactions

• https://testnet.arcscan.app/tx/0x7532ce470169e2db2be43e5f9c43dd523d21e9071c04268ff5941f8ca839ef7b
• https://testnet.arcscan.app/tx/0xf889b8fa893e18db9cafc52a01b855706e43860152737d2c0095725fbb4dd71e

Hypothesis

The CallFrom precompile's msg.sender preservation mechanism may behave differently in read-only simulation mode (eth_call) vs actual execution. This causes standard gas estimation to fail even when the real transaction would succeed.

[osr21]

Confirmed — same gas estimation failure affects multiple Arc precompile/infrastructure calls

We independently hit this exact pattern while building Arc Swap, a DEX and cross-asset payment app on Arc Testnet (Chain ID 5042002). Happy to share what we found.

---

The issue is broader than callWithMemo

eth_estimateGas / eth_call fails for any call that touches Arc-specific precompile infrastructure — not just the Memo contract. We observed it on:

Call	Fails with estimation	Succeeds when sent
UniswapV2Factory.createPair	✅	✅
UniswapV2Router02.addLiquidity	✅	✅
UniswapV2Router02.swapExactTokensForTokens	✅	✅
ERC20.approve on USDC (0x3600...)	✅	✅
Memo.memo / Memo.callWithMemo	✅	✅
Standard ERC20 transfer on non-Arc tokens	✅	✅

The pattern appears to be: anything involving Arc's native USDC precompile (0xffff...fe / 0x3600...) or the CallFrom precompile path in static simulation mode fails, while the signed broadcast path works fine. Your hypothesis looks correct to us.

---

Working workaround

Skip estimation entirely — pass an explicit gas field on every write:

// viem — never let it call eth_estimateGas
await walletClient.writeContract({
  ...params,
  gas: 350_000n,  // explicit override
});

Values we use in production:

Operation	Gas
ERC20 approve / transfer	100,000
Single-hop Uniswap V2 swap	250,000–350,000
General contract call (incl. Memo.memo)	200,000–500,000
UniswapV2Factory.createPair	5,000,000
First addLiquidity on a new pair	3,000,000

The gas limit feels large but actual usage is much lower — our swap transactions typically consume 123k–128k of a 350k limit.

Verified swap transactions on our app for reference:

• https://testnet.arcscan.app/tx/0x57d29e4c793d880ef56619475f280d373b036501d6ef56240629592e0c7d06f8 (128k used / 350k limit)
• https://testnet.arcscan.app/tx/0x16c428a263cf2b991b7a92ff8f5120e971fedfbc2287fece758f262410bd02bf (123k used / 350k limit)

---

Our Memo contract experience specifically

We integrated the Memo contract (0x5294E9927c3306DcBaDb03fe70b92e01cCede505) to attach on-chain payment notes when the backend wallet relays a transfer. A few things we hit:

1. Gas estimation fails identically — same workaround applies

await walletClient.writeContract({
  address: "0x5294E9927c3306DcBaDb03fe70b92e01cCede505",
  abi: MEMO_ABI,
  functionName: "memo",
  args: [targetToken, transferCalldata, memoId, memoData],
  gas: 200_000n,  // required — estimation reverts
});

2. The memo function (not callWithMemo) is what we used

We called memo(address target, bytes data, bytes32 memoId, bytes memoData) rather than callWithMemo. The distinction matters: memo attaches a memo event to an already-executed call, while callWithMemo wraps the call. Both suffer from the estimation bug.

3. waitForTransactionReceipt does not throw on revert

This is a second Arc Testnet quirk, separate from but related to the gas estimation issue. When a transaction reverts, viem's waitForTransactionReceipt returns normally with receipt.status === "reverted" instead of throwing. If you don't check this explicitly, the call appears to succeed:

const receipt = await publicClient.waitForTransactionReceipt({ hash });
if (receipt.status === "reverted") {
  throw new Error(`Transaction reverted — check receipt: ${hash}`);
}

This caught us out early — createPair appeared to succeed but the pair was never created. The receipt status check is now mandatory on every write.

---

Flagging Arc node issue #80 is the right call. Both quirks (estimation failure + non-throwing reverts) appear to stem from the same underlying node behaviour in simulation vs execution mode. Happy to share more specifics or test cases if useful.

[osr21]

Additional finding from Arc Stablecoin DApp — a second, distinct memo error surface

We hit this issue from a different angle while building the Batch Transfer feature in Arc Stablecoin DApp, and wanted to document a second error that is separate from but related to this one.

---

The self-call rejection — a consensus-level block, not an estimation bug

Our original memo design used a self-call: encode the memo as UTF-8 calldata, send from userAddress to userAddress. This fails on Arc with:

External transactions to internal accounts cannot include data

This is enforced at consensus / block-inclusion time — not during eth_estimateGas or eth_call. The gas: 200_000n override that fixes this issue does not help; the transaction is dropped before the EVM ever executes it.

Error scenario	Stage	Workaround
callWithMemo reverts during eth_estimateGas (this issue)	RPC simulation	Pass explicit gas:
Self-call with non-empty data (from == to + data != 0x)	Block inclusion / consensus	Must use a different memo strategy entirely

---

What worked: embed memo in the contract function

Since we own the BatchTransfer contract, we added string calldata memo as a 4th parameter and emit it in the BatchExecuted event. The memo is stored in the transaction log in the same confirmation — no extra step, no self-call, no Memo precompile call:

event BatchExecuted(
    address indexed sender,
    address indexed token,
    uint256 totalAmount,
    uint256 count,
    string  memo    // ← stored in the log, decoded by name on ArcScan
);

function batchTransfer(
    address          token,
    address[] calldata recipients,
    uint256[] calldata amounts,
    string    calldata memo
) external;

Deployed and source-verified on ArcScan: 0x76d5dd51ad28D607cD8804dc5230cAE93403eD3d

Live example with memo "Invoice MR" decoded in the Logs tab:
https://testnet.arcscan.app/tx/0xacc2bc5a96ecac286549132303e664f3ade81969c26e788c814798f20f13b429?tab=logs

---

Practical summary for builders hitting either error

• Gas estimation fails on callWithMemo (this issue): pass gas: 200_000n explicitly — the tx will succeed.
• from == to with non-empty data (self-call memo): cannot fix at the RPC layer — either use the Memo precompile with an explicit gas: override, or embed the memo in your own contract function.
• If you own the contract: adding memo as a function parameter is the simplest path — zero extra confirmations, no precompile dependency, survives any future changes to the Memo contract.

Filed the self-call restriction as a standalone issue for visibility (it warrants its own documentation entry).

[thlucy]

It is a long thread, thank you for testing and reporting these!

Here is doc for the memo transaction https://docs.arc.io/arc/concepts/transaction-memos. I believe the callWithMemo signature is out of dated, the correct signature is memo(address,bytes,bytes32,bytes).

Same success example by cast command to transfer USDC by ERC20.transfer interface with memo. You could set your own address and private-key to test.

MEMO=0x5294E9927c3306DcBaDb03fe70b92e01cCede505
USDC=0x3600000000000000000000000000000000000000
MYADDR=0x44295cbc6068104981df5171F9cEce9971445446

cast call --from $MYADDR $MEMO 'memo(address,bytes,bytes32,bytes)' \
  $USDC "$(cast calldata 'transfer(address,uint256)' $MYADDR 2)" \
  "$(cast to-uint256 1)" \
  "0x$(echo 'test ERC20 transfer' | xxd -p)" \
   -r https://rpc.testnet.arc.network

This also works for estimation

cast estimate --from $MYADDR $MEMO 'memo(address,bytes,bytes32,bytes)' \
  $USDC "$(cast calldata 'transfer(address,uint256)' $MYADDR 2)" \
  "$(cast to-uint256 1)" \
  "0x$(echo 'test ERC20 transfer' | xxd -p)" \
   -r https://rpc.testnet.arc.network

And slightly modified your example to get a successful call

cast call $MEMO  "memo(address,bytes,bytes32,bytes)"  \
   0xe81f5BA4181eA29061C3C229c8D6EB4cFE56639C  \
   0xb7dc1284 \
   0xf02ff6783ff9bca82d31d52554ec1a67aafc314374620c489f58afe2d84326d2  \
   "$(echo -n test | xxd -p)" \
   --rpc-url https://rpc.testnet.arc.network \
   --from 0x54b4B44749a95070560509B6Ec0be501665CcF63

I also could construct the viem code to sendTransaction without explicit gas assigning. Please tell me if you are still getting issues after changing the signature.

[osr21]

@thlucy — thank you, the signature correction is the root cause. Confirmed on our end:

Verified: correct signature fixes gas estimation

cast estimate --from $MYADDR $MEMO 'memo(address,bytes,bytes32,bytes)' \
  $USDC \
  "$(cast calldata 'transfer(address,uint256)' $MYADDR 2)" \
  "$(cast to-uint256 1)" \
  "0x$(printf 'arc stablecoin dapp test' | od -A n -t x1 | tr -d ' \n')" \
  -r https://rpc.testnet.arc.network
# → 61929

Gas estimation returns cleanly with memo(address,bytes,bytes32,bytes). No explicit gas override needed.

What was wrong

Our original reproduction used callWithMemo(address,bytes,bytes32,**string**) — the old function name and the wrong type for the 4th parameter. The current entry point is memo(address,bytes,bytes32,**bytes**). The docs at https://docs.arc.io/arc/concepts/transaction-memos show the correct ABI.

This also explains the docs' STATICCALL guardrail — "Memo execution changes state by incrementing the memo index, so static execution is rejected." The old function likely didn't have that restriction lifted in the simulation path, whereas memo() does.

viem usage with the correct ABI

For anyone hitting this in TypeScript — the 4th parameter must be Uint8Array or hex-encoded bytes, not a plain string:

import { toHex, toBytes, encodeFunctionData } from 'viem';

// Encode the inner call (e.g. USDC transfer)
const innerCalldata = encodeFunctionData({
  abi: erc20Abi,
  functionName: 'transfer',
  args: [recipientAddress, amount],
});

// Call memo() — no explicit gas needed with correct signature
await walletClient.writeContract({
  address: '0x5294E9927c3306DcBaDb03fe70b92e01cCede505',
  abi: [{
    name: 'memo',
    type: 'function',
    inputs: [
      { name: 'target',   type: 'address' },
      { name: 'data',     type: 'bytes'   },
      { name: 'memoId',   type: 'bytes32' },
      { name: 'memoData', type: 'bytes'   },
    ],
    outputs: [],
    stateMutability: 'nonpayable',
  }],
  functionName: 'memo',
  args: [
    USDC_ADDRESS,
    innerCalldata,
    toHex(1n, { size: 32 }),           // memoId — your app-defined identifier
    toBytes('Invoice INV-2026-001'),    // memoData — arbitrary bytes
  ],
});

Separate issue: broader estimation failures on Arc-native contracts

To keep the record accurate: the gas estimation failures we documented for UniswapV2 (createPair, addLiquidity, swapExactTokensForTokens) and ERC20 approve/transfer on the native USDC precompile (0x3600...) are separate from the callWithMemo signature issue. Those still require explicit gas: overrides and are likely rooted in the CallFrom precompile path under eth_estimateGas. If those belong in a separate issue we are happy to open one.

Closing the Memo-specific part of this — the explicit gas override workaround is no longer needed once callers use the correct memo() ABI. Will also revise our docs and remove the workaround from the Arc Stablecoin DApp.