Skip to content

docs: Circle & Arc integration exploration #302

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Huygon764 wants to merge 1 commit into
base: develop
Choose a base branch
from
Open

docs: Circle & Arc integration exploration #302

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
101 changes: 101 additions & 0 deletions docs/research/circle-arc-exploration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,101 @@
# Circle Integration & Arc Deployment — PolyPay Assessment

**Goal:** decide whether PolyPay can (a) deploy on Circle's **Arc** L1 and (b) integrate any Circle
product with real code. Exploration only, not production.

## 1. Can PolyPay deploy on Arc?

`MetaMultiSigWallet.sol` uses only standard EVM opcodes, so the contract itself is portable to any
EVM chain. But the **private** app cannot run on Arc, and Arc has no production target yet:

| Blocker | Detail | Source |
|---|---|---|
| **zkVerify not on Arc** | PolyPay verifies every signer proof on-chain by calling zkVerify's aggregation contract (`MetaMultiSigWallet.sol:236-253`, `_verifyProof`). zkVerify's aggregation contract is deployed only on Ethereum Sepolia, Base, Horizen, Arbitrum, OP, Apechain, EDU (+ testnets) — **Arc is not on the list**. On Arc `_verifyProof` has no contract to call, so `execute()` cannot verify proofs. | [zkVerify supported chain](https://docs.zkverify.io/architecture/contract-addresses) |
| **Arc's own privacy (APS) can't substitute** | Verified July 2026 from live docs: *"Privacy features are on the roadmap and not yet available on Arc."* Corroborated by Circle's June 2026 "Arc Privacy" announcement, described as *"a proposed design, not a shipping product."* | [Arc opt-in-privacy](https://docs.arc.io/arc/concepts/opt-in-privacy), [crypto.news, Jun 2026](https://crypto.news/circle-unveils-arc-privacy-to-bring-confidential-smart-contracts-to-institutions/) |
| **USDC-as-gas breaks the relayer** | Arc uses USDC as the native gas token. PolyPay's relayer executes txs paying gas in **native ETH** (`relayer-wallet.service.ts`), every chain is defined `nativeCurrency: ETH` (`scaffold.config.ts:12,34`), and price fetch special-cases ETH (`fetchPriceFromUniswap.ts:22-32`). The relayer would need USDC for gas and the ETH assumptions reworked. | [Arc connect-to-arc](https://docs.arc.io/arc/references/connect-to-arc), code |
| **No Arc mainnet** | Verified July 2026: Arc is still public testnet only — the live docs list a testnet chain id (`5042002`) with no mainnet endpoints. Mainnet beta is targeted for summer 2026 but not yet live. Any Arc deploy today is testnet-only. | [Arc connect-to-arc](https://docs.arc.io/arc/references/connect-to-arc), [Phemex: mainnet summer 2026](https://phemex.com/news/article/circle-unveils-arc-blockchain-whitepaper-mainnet-launch-set-for-summer-2026-82817) |

**Note:** "no Kurier on Arc" is *not* the real blocker. Kurier is Horizen Labs' off-chain REST API
to zkVerify (`zkverify.service.ts:57-60`) and is chain-agnostic. The hard dependency is the
**on-chain zkVerify aggregation contract**, which Arc lacks.

### Alternative: keep privacy on Arc without Kurier/zkVerify

PolyPay's circuit is Noir/UltraHonk. Barretenberg can emit a **standalone Solidity verifier** for
that circuit (`bb write_solidity_verifier` → `Verifier.sol`)
([Barretenberg docs](https://barretenberg.aztec.network/docs/how_to_guides/how-to-solidity-verifier/)).
So PolyPay could drop Kurier + zkVerify on Arc and instead:

- deploy the generated UltraHonk `Verifier.sol` on Arc,
- rework `_verifyProof` (`MetaMultiSigWallet.sol:236-253`) to call that verifier directly with the
full proof instead of `verifyProofAggregation`,
- have the frontend send the full proof to the relayer (no Kurier submit/poll).

This **keeps signer privacy** — same circuit, same commitments + nullifier — with no dependency on
Horizen Labs.

**Does the verifier run on Arc?** The generated Honk verifier requires the `ecAdd`, `ecMul`,
`ecPairing` and `modexp` precompiles ([Barretenberg docs](https://barretenberg.aztec.network/docs/how_to_guides/how-to-solidity-verifier/)).
Arc targets the **Osaka** EVM baseline, and its documented EVM differences remove only
PREVRANDAO / SELFDESTRUCT / EIP-4788 / blob-tx behaviour — the BN254 and modexp precompiles are
**not** among the removed or changed items ([Arc EVM differences](https://docs.arc.io/arc/references/evm-differences)),
and Arc advertises full EVM compatibility. So the verifier should run. Arc publishes no explicit
precompile list, so the one definitive check is to deploy `Verifier.sol` on the live Arc testnet and
verify a proof — a short test, not a blocker.

Trade-offs:

- **Higher on-chain cost** — a full Honk verification per tx, versus zkVerify's amortized aggregate
(cheap verification is zkVerify's whole point). On Arc that gas is paid in USDC.
- **Contract fork** of `_verifyProof` plus a verifier deploy.
- **Depends on the stalled UltraHonk migration** — PolyPay's bb.js/contract UltraHonk upgrade is
still pending (`docs/adr/002-ultrahonk-migration.md`); the direct-verifier VK must match the
proving stack.

**Verdict:** a **private** PolyPay on Arc is feasible **only as a testnet demo** (Arc has no zkVerify
and no live mainnet), via one of two unlocks: (a) Horizen Labs deploys zkVerify on Arc — cheapest
verification, but a partner ask; or (b) PolyPay ships the standalone UltraHonk verifier above — in
our control, at higher gas + engineering cost. Do not target Arc for production until its mainnet
exists.

## 2. Why PolyPay's privacy is chain-bound (context for the blocker)

Signer anonymity has two layers:

- **Commitments** — the wallet stores `poseidonHash2(secret, secret)` per signer, never addresses
(`MetaMultiSigWallet.sol:46`, `packages/shared/src/crypto/identity.ts:16-37`).
- **ZK membership proof** — a Noir circuit proves a signer knows the secret and signed the tx
(`packages/nextjs/public/circuit/src/main.nr:51-67`), verified **on the destination chain** via
zkVerify. This is what ties privacy to a chain: it needs `zkVerifyAddress` + `poseidonT3Address`
per chain (`packages/shared/src/contracts/contracts-config.ts:1-64`).

Privacy is therefore **not** Horizen-exclusive — it already works on Base and Arbitrum because
zkVerify is deployed there. It fails on any chain that lacks the zkVerify contract.

## 3. Circle products worth integrating (no Arc needed)

Runnable on PolyPay's existing chains, higher value than an Arc deploy. Today PolyPay has **no**
CCTP / Circle Wallets / Circle Paymaster / ERC-4337 code; the only Circle-adjacent pieces are
Coinbase CDP as an x402 facilitator and Circle's native USDC addresses (`x402.service.ts`,
`packages/shared/src/constants/token.ts`). Product list per [circle.com/developer](https://www.circle.com/developer).

| Product | What it does, and the feature PolyPay would gain | Verdict |
|---|---|---|
| **CCTP** | Circle's cross-chain USDC transfer: it burns USDC on one chain and mints native USDC on another (no wrapped tokens, always 1:1). **Feature:** anyone can fund a PolyPay multisig from a different chain and the money lands as real USDC. Works for multisigs on **Base** and **Arbitrum**, but **not Horizen** (Horizen is not a CCTP chain), so it can't fund the primary deployment ([CCTP domains](https://developers.circle.com/cctp/concepts/supported-chains-and-domains)). | **Best fit**, but Base/Arbitrum only. Real code, mainnet-ready. |
| **Gateway** | You deposit USDC once into a Circle Gateway contract and get a single "unified balance" spendable on any supported chain in under 500 ms, without bridging each time — non-custodial, so funds move only with your signature ([Circle Gateway](https://www.circle.com/gateway)). **Feature:** an org keeps its treasury as one USDC pool and funds multisigs on whichever chain a payroll runs on. Live on **Base + Arbitrum** (not Horizen); Circle says Arc is planned. | Good fit for treasury UX, but a bigger build than CCTP. |

Not pursued (documented so the decision is clear): **EURC** — Circle's euro stablecoin is live only on
Base among PolyPay's chains, not Horizen or Arbitrum ([Circle supported chains](https://developers.circle.com/w3s/supported-blockchains-and-currencies)),
so euro payroll would be single-chain and inconsistent. **Paymaster** — PolyPay users already pay no
gas (relayer + x402). **Wallets** — Circle-hosted login would replace PolyPay's own wallet and
ZK-identity model.

## 4. Conclusion

1. **Arc:** demo-only, not production. Arc has no live mainnet (testnet only; mainnet targeted
"summer 2026", no exact date) and no zkVerify. Privacy on an Arc testnet demo is possible either
by asking Horizen Labs to deploy zkVerify on Arc, or by shipping a standalone UltraHonk
`Verifier.sol` (see section 1) — the latter is in our control but costs more gas + a contract fork.
2. **Best Circle integration is CCTP** — fund a multisig cross-chain with native USDC (Base/Arbitrum
only, no ZK rework). **Gateway** is a larger follow-up for treasury UX. Neither reaches Horizen,
so both are scoped to PolyPay's Base/Arbitrum deployments.
Loading