docs: add EOA-only limitation note to transaction-memo-integration example

[consumeobeydie]

Summary

Adds a "Known Limitations" section to the transaction memo integration example documenting the EOA-only constraint of the Memo contract.

What this adds

The callFrom precompile requires msg.sender == tx.origin, which means any contract-based account (Circle Developer Controlled Wallets, ERC-4337 SCAs, Modular Wallets) will silently revert when calling memo().

This was confirmed on Arc Testnet (Chain ID: 5042002) — gas estimation also fails for the same reason when using callFrom simulation with contract-based senders.

Changes

• Explains why contract callers revert (precompile level, not Memo contract)
• Shows working example (EOA via viem private key signer)
• Shows failing case (Developer Controlled Wallet / SCA)
• References IMemo.sol and ICallFrom.sol NatSpec for verification

Related

This was flagged in the Arc Discord by @timothy Baker after I reported the revert behavior while building on Arc Testnet.

[osr21]

Thanks for documenting the EOA-only constraint — this is a real footgun for builders on Arc and worth having in the official docs.

I've been building the Arc Stablecoin DApp on Arc Testnet and can confirm the callFrom precompile behaviour from first-hand experience. A few observations on the two files:

---

transaction-memo-integration.md — useful, a couple of notes

✅ EOA constraint confirmed. Our server-side operator (DEPLOYER_PRIVATE_KEY EOA) calls on NanopayVault and ConditionalEscrow work fine. Circle Developer Controlled Wallets and any ERC-4337 SCA fail silently at the precompile — exactly as described. Good to have this written down.

Function signature vs public docs. The file derives callWithMemo(address,bytes,bytes32,string) / selector 0xc3b2c4f8 from bytecode inspection because the ABI wasn't published at the time. The text also references memo() as the primary entry point in the working TypeScript snippet. It would help to clarify which function callers should target, and ideally Circle publishes the canonical IMemo.sol ABI so builders aren't reverse-engineering selectors.

Minor: the bytes32 correlationId note (must be exactly 32 bytes) is worth expanding — a common mistake is passing a UTF-8 string instead of a zero-padded bytes32, which silently truncates or reverts.

---

arc-agent-sdk-example.ts — two concrete issues

⚠️ Undisclosed conflict of interest. @consumeobeydie/arc-agent-sdk is your own npm package. Adding it to Circle's official docs/examples/ without disclosure isn't appropriate for a docs PR to this repo, regardless of the package quality. If the intent is to showcase community tooling, a separate community showcase or a link from the PR description would be the right channel.

⚠️ USDC decimal mismatch. The spending limit amounts use 18-decimal precision:

const { hash: limitHash } = await sdk.setSpendingLimit(
  sdk.address,
  1_000_000_000_000_000_000n, // labeled "1 USDC daily"
  5_000_000_000_000_000_000n, // labeled "5 USDC weekly"
    100_000_000_000_000_000n  // labeled "0.1 USDC per tx"
);

USDC on Arc Testnet is 6 decimals. If SpendingLimits operates on raw USDC token amounts, 1_000_000_000_000_000_000 is one trillion USDC, not 1 USDC — the correct raw value would be 1_000_000n. If SpendingLimits uses its own 18-decimal internal representation independent of the token, that needs to be documented explicitly in the SDK and here, since it directly contradicts the ERC-20 decimals that every other Arc contract (including the Circle-deployed USDC at 0x3600...0000) uses.

Contract addresses. The addresses for SpendingLimits, AgentIdentity, SplitPayment, and ArcDEX in the example don't match Arc's officially deployed or documented addresses. These appear to be the author's own testnet deployments. Docs examples should either use canonical addresses or be explicit that these are demo deployments.

---

Suggestion: merge transaction-memo-integration.md with the fixes above; hold arc-agent-sdk-example.ts until the conflict-of-interest and decimal issues are resolved.