bug: EOA self-calls with calldata rejected at consensus level — "External transactions to internal accounts cannot include data"

[osr21]

Summary

Arc Testnet rejects any transaction where the sender and recipient are the same address (from == to) and the transaction carries non-empty data. The error returned is:

External transactions to internal accounts cannot include data

This is enforced at the consensus layer, not by the EVM or a smart contract. It cannot be worked around by adjusting gas, fee fields, or transaction type.

---

Environment

• Network: Arc Testnet (Chain ID: 5042002)
• Trigger: any eth_sendTransaction or wallet_sendCalls where from === to and data.length > 0
• Tools affected: MetaMask, viem, ethers.js, cast — any library that submits the raw transaction

---

Reproduction

// Attempt to send a self-call with data (e.g. to attach an on-chain memo)
const tx = await window.ethereum.request({
  method: "eth_sendTransaction",
  params: [{
    from:  "0xYourAddress",
    to:    "0xYourAddress",   // same as from
    data:  "0x48656c6c6f",   // any non-empty calldata
    value: "0x0",
    gas:   "0x7530",
  }],
});
// → MetaMask submits, Arc node rejects:
// "External transactions to internal accounts cannot include data"

Note: the same call with data: "0x" (empty) succeeds — it is the combination of from == to and non-empty data that is rejected.

---

Impact

This silently breaks a common pattern used by dApps to attach on-chain memos to transactions:

1. Self-call memo pattern — encode a UTF-8 string as calldata, send to self. Widely used on Ethereum mainnet and other EVMs. Completely blocked on Arc Testnet.
2. Consequence for the Arc Memo precompile — the Memo precompile (0x5294E9927c3306DcBaDb03fe70b92e01cCede505) is the only supported on-chain memo path, but it has its own gas-estimation bug (see issue #189). The self-call restriction means there is currently no simple, estimation-compatible fallback.

---

Discovered during Batch Transfer integration

We hit this while building Arc Stablecoin DApp, specifically on the Batch Transfer feature. The original design appended an on-chain text memo by sending a self-call with the memo encoded as calldata — a standard EVM pattern:

// Original design — fails on Arc
await window.ethereum.request({
  method: "eth_sendTransaction",
  params: [{
    from: userAddress,
    to:   userAddress,
    data: toHex(new TextEncoder().encode(memoText)),
  }],
});
// → "External transactions to internal accounts cannot include data"

Workaround we used: Added a string calldata memo parameter directly to batchTransfer(). The memo is emitted in the BatchExecuted event and stored in the transaction log in the same confirmation — no separate transaction or self-call needed:

contract BatchTransfer {
    event BatchExecuted(
        address indexed sender,
        address indexed token,
        uint256 totalAmount,
        uint256 count,
        string  memo           // ← stored in the event log
    );

    function batchTransfer(
        address          token,
        address[] calldata recipients,
        uint256[] calldata amounts,
        string    calldata memo   // ← callers pass memo string directly
    ) external {
        // ... ERC-20 transfer loop ...
        emit BatchExecuted(msg.sender, token, total, recipients.length, memo);
    }
}

Deployed and source-verified on ArcScan: 0x76d5dd51ad28D607cD8804dc5230cAE93403eD3d

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

---

Comparison with issue #189

This restriction is distinct from the gas-estimation bug in #189:

Scenario	Error	Stage	Workaround
callWithMemo via viem / ethers	Gas estimation fails	RPC simulation	Pass explicit gas: override
Self-call with non-empty data (from == to)	Consensus rejection	Block inclusion	Cannot use self-calls — embed memo differently

The gas: override that fixes #189 does not help here — the transaction is rejected at block inclusion, not during estimation.

---

Suggested documentation / guidance

1. Document the from == to + data restriction explicitly in Arc developer docs — the error message is opaque and this behaviour differs from Ethereum mainnet.
2. Recommend the Arc Memo precompile (0x5294...) as the supported alternative, with a note about the gas-estimation workaround (callWithMemo reverts during gas estimation (eth_call) but succeeds with direct signed transaction #189).
3. For dApps that own their contract: embedding memo as a function parameter and emitting it in an event is a zero-extra-confirmation alternative that avoids both issues entirely.

---

References

• Related: issue #189 — callWithMemo gas estimation failure
• Related: PR #182 — Arc Transaction Memo integration example
• Working implementation: BatchTransfer.sol on Arc Testnet (source-verified)
• DApp repo: osr21/arc-stablecoin-dapp

[osr21]

Confirmed — also breaks the self-call memo pattern used for agent activity logging

We hit this while building on-chain activity attribution for our AgentRegistry integration on Arc Testnet.

Additional trigger we found

The rejection fires when attaching a UTF-8 memo to any self-transfer for on-chain activity attribution:

// Intent: tag a USDC self-transfer with an on-chain memo for agent activity
await walletClient.sendTransaction({
  to: walletAddress,   // same as from
  data: toHex('agent:treasury-v2:activity:ref-123'),
  value: 0n,
});
// → Arc node rejects: "External transactions to internal accounts cannot include data"

The pattern was meant to be a lightweight gas-cheap on-chain timestamp without needing a contract. Arc's consensus layer blocks it entirely.

Our workaround

We moved all activity recording into the AgentRegistry smart contract (recordActivity(agentId, amount)) deployed at 0xF891f7cCF2A795801b9F1cE8Bd5753B5a6043e72. The contract accepts activity from any caller and emits ActivityRecorded events, which serve as the on-chain timestamp and attribution record.

Heavier than a self-call, but works correctly. Source: AgentRegistry.sol

Question for the team

Are there other EVM patterns Arc's consensus layer currently rejects beyond from == to && data.length > 0? Knowing ahead of time would help avoid dead ends when designing new primitives. Specifically curious about:

• from == to with empty data (plain USDC self-transfer) — this works correctly ✅
• Contract self-calls (CALL from contract back to itself) — untested
• Zero-value transactions with data to a non-self address — works correctly ✅

[thlucy]

Hi @osr21, I created a transaction with self-calls data without issues.
https://testnet.arcscan.app/tx/0xfa31e2ae1966399476e0915a35e04d81ec9f6ad6171186a0bfc49d5ed3b88ae2

The example command as following, could you help to verify it by cast?

cast send --account m 0xDD595E71e8dE9115353Bb1Cf3dF5D27ad6548463 0x48656c6c6f -r 
https://rpc.testnet.arc.network

[osr21]

@thlucy — confirmed, that transaction is a genuine self-call:

• From: 0xDD595E71e8dE9115353Bb1Cf3dF5D27ad6548463
• To: 0xDD595E71e8dE9115353Bb1Cf3dF5D27ad6548463 (same — from == to ✅)
• Data: 0x48656c6c6f ("Hello" — non-empty calldata ✅)
• Status: Success ✅

This is exactly the pattern that was failing when we filed the issue. Good news — it looks like the restriction may have been lifted or a fix was deployed between our original report (Jun 26) and your test (Jun 28).

We'll re-test from our side using both paths:

1. cast (same approach as your example):

cast send --account <our-wallet> <our-address> 0x48656c6c6f -r https://rpc.testnet.arc.network

2. Browser wallet (MetaMask via eth_sendTransaction) — this was the original failure path.

Can you confirm whether an Arc node update was deployed between Jun 26–28 that would explain the change? If the from == to + data path is now fully supported, we'll update the issue body and close it — and we can also revisit the Memo precompile path now that the self-call fallback is available again.

[osr21]

ERC-4337 smart accounts provide a clean workaround — with one caveat for the Memo precompile

The consensus-level restriction (from == to && data.length > 0 → rejected) applies specifically to EOA-submitted transactions. ERC-4337 UserOps route around it because the transaction that hits the Arc node never has from === to:

EOA (signs UserOperation, no eth_sendTransaction)
  ↓
Bundler submits: eth_sendRawTransaction
  ↓
Arc node sees: from=EntryPoint, to=SmartAccount  ← from ≠ to, no restriction
  ↓
EVM execution: SmartAccount.execute(to=SmartAccount, calldata=...)
  ↑ inner call from SmartAccount → SmartAccount goes through EVM frames, not
    consensus-level transaction validation — no rejection

The key: the consensus-level check fires on the outer transaction (the one in the mempool). In a UserOp, the outer transaction is always from=EntryPoint, to=SmartAccount. The inner call from the smart account to itself happens entirely inside EVM execution and is not subject to the same constraint.

This means you can put self-call calldata in userOp.callData — for memo attachment, self-initiation patterns, or anything else that requires EOA-equivalent self-addressing — and the Arc consensus rejection will not apply.

---

Caveat: the Arc Memo precompile has a separate EOA requirement

If the self-call is specifically to attach an on-chain memo via the Memo precompile (0x5294E9927c3306DcBaDb03fe70b92e01cCede505), the AA workaround may not apply.

Per the Arc transaction memos docs, the Memo precompile uses the CallFrom precompile to preserve msg.sender and enforces that the direct caller is an EOA (not an intermediary contract). A smart account's execute() calling the Memo precompile may trigger this restriction at the precompile level — a different check, same symptom.

Pattern	EOA self-call restriction	Memo precompile restriction
EOA → self with calldata	❌ Blocked by consensus	✅ N/A
SmartAccount UserOp → self	✅ Bypassed (outer tx is EntryPoint→SmartAccount)	⚠️ May be blocked by Memo's EOA-direct-caller requirement
SmartAccount UserOp → Memo precompile	✅ Bypassed	⚠️ Depends on whether Memo checks for EOA

The Memo precompile EOA requirement is worth confirming on-chain (or in the Arc node source). If it checks tx.origin == msg.sender or similar, a smart account call will fail — but any arbitrary self-call that doesn't use the Memo precompile will work fine via AA.

---

Practical implementation

Using permissionless.js on Arc Testnet (chain ID 5042002):

import { createSmartAccountClient } from "permissionless";
import { toSimpleSmartAccount } from "permissionless/accounts";

const account = await toSimpleSmartAccount({
  client: publicClient,
  owner,
  entryPoint: { address: "0x0000000071727De22E5E9d8BAf0edAc6f37da032", version: "0.7" },
});

// Self-call with calldata — Arc consensus check does not apply
const userOpHash = await smartAccountClient.sendUserOperation({
  calls: [{
    to:   account.address,   // self-call
    data: encodedCalldata,   // arbitrary calldata
    value: 0n,
  }],
});

The full ERC-4337 setup for Arc Testnet, including the three deployment constraints (no PUSH0, single-immutable constructor, no nonReentrant on validation), is documented in PR #114.