> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.io/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Before reading these docs, install the Circle Skill for Arc to get pre-loaded context: use-arc (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-arc/SKILL.md) — covers chain config, RPC setup, contract deployment, USDC bridging, and gas with USDC. In Claude Code: run /plugin marketplace add circlefin/skills then /plugin install circle-skills@circle. With Vercel Skills CLI: run npx skills add circlefin/skills.
> USDC is the gas token. Arc uses USDC for gas fees, not ETH. Configure gas payment in USDC when submitting transactions.
> Read EVM differences before writing Arc code. Arc targets the Osaka EVM baseline. Most contracts deploy unchanged, but several runtime behaviors diverge from Ethereum: USDC uses 18 decimals natively (not 6), the system emitter `0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE` logs all USDC Transfer events, the mempool enforces a 20 Gwei `maxFeePerGas` floor, blocklist reverts consume gas without a receipt, and `address(0)` sends revert rather than succeed. https://docs.arc.io/arc/references/evm-differences.md is the canonical reference for all Arc-specific runtime behaviors. Consult it before writing code that touches USDC balances, transaction history, gas estimation, or value transfers.
> Sub-second finality. Transactions are final in under 1 second. No need to wait for multiple block confirmations.
> Use App Kits for multichain payment and liquidity capabilities. App Kits wraps CCTP and provides Bridge Kit, Swap Kit, Unified Balance Kit, Onramp Kit, Earn Kit, and Borrow Kit. Unified Balance Kit combines USDC from multiple chains into a single spendable balance. Earn Kit integrates earn opportunities into your app. Borrow Kit lets users borrow USDC against cirBTC collateral on Arc.
> Use Arc Foundry for contract development. Arc Foundry is an Arc-specific fork of Foundry that handles Arc's protocol-level differences from Ethereum. It provides arc-forge, arc-cast, and arc-anvil. Install it before deploying contracts: https://docs.arc.io/arc/tutorials/install-arc-foundry.md.
> Arc is available on both Testnet and Mainnet. See https://docs.arc.io/arc/references/connect-to-arc.md for RPC endpoints and https://faucet.circle.com for testnet tokens.
> Always check Contract Addresses: https://docs.arc.io/arc/references/contract-addresses.md
> Building beyond Arc? Circle offers skills for the full platform: use-usdc (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-usdc/SKILL.md), use-circle-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-circle-wallets/SKILL.md), use-developer-controlled-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-developer-controlled-wallets/SKILL.md), use-user-controlled-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-user-controlled-wallets/SKILL.md), use-modular-wallets (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-modular-wallets/SKILL.md), use-gateway (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-gateway/SKILL.md), use-smart-contract-platform (https://github.com/circlefin/skills/blob/master/plugins/circle/skills/use-smart-contract-platform/SKILL.md). Full Circle developer docs: https://developers.circle.com/llms.txt.

# Post-quantum security

> Arc's post-quantum roadmap covers wallet signatures, validator authentication, private state, and supporting infrastructure against quantum-era attacks.

Arc's post-quantum roadmap covers wallet signatures, validator authentication,
private smart contract state, and offchain infrastructure.

<Info>
  `SLH-DSA-SHA2-128s` signature verification is live on Arc mainnet.
  Post-quantum transaction signing is a future milestone and will likely
  implement EIP-8141 frame transactions once the EIP is finalized.
</Info>

## Why post-quantum security matters

Most public-key cryptography used today is vulnerable to large-scale quantum
computers. If those computers become practical, blockchains face two risks:

* **Signature forgery.** A quantum computer that breaks public-key cryptography
  can forge signatures that secure wallets, authorize transactions, and
  authenticate network participants.
* **Harvest-now, decrypt-later attacks.** Encrypted data captured today can be
  stored and decrypted later when quantum attacks become practical, exposing
  private transaction details, balances, and other sensitive data.

Because blockchain data is long-lived, post-quantum protections need to be in
place before quantum attacks are widely available.

## Post-quantum roadmap

Arc's roadmap introduces each layer in a production-aligned sequence.

| Milestone | Release target | Scope | Why it matters |
| - | - | - | - |
| Post-quantum wallet signatures | In progress | Arc mainnet supports `SLH-DSA-SHA2-128s` signature verification. Native wallet transaction signing is a future milestone and will likely implement EIP-8141 frame transactions once the EIP is finalized. | Contracts can verify SLH-DSA-signed messages as an application-layer authorization primitive today, without requiring native wallet signing. |
| Post-quantum privacy | Near-term | Arc Privacy mainnet introduces post-quantum protections for encrypted state and node-to-node communication in privacy mode. | Private balances, counterparties, and transaction details face harvest-now, decrypt-later risk without post-quantum encryption. |
| Offchain infrastructure upgrades | Mid-term | Circle upgrades infrastructure such as TLS, encrypted data flows, and related operational systems. | Offchain infrastructure uses the same vulnerable cryptography as onchain systems. |
| Post-quantum validator signatures | Long-term | Arc adds a quantum-resistant signature scheme for validators. | Consensus signatures protect the integrity of the Arc ledger. |

## Post-quantum wallet signatures

Arc mainnet supports onchain verification of `SLH-DSA-SHA2-128s` signatures. Arc
will likely implement EIP-8141 frame transactions in a future milestone, once
the EIP is finalized. Frame transactions allow wallets to choose their own
transaction signatures, and Arc will offer native support for multiple
post-quantum signatures to allow users to optimize gas costs, security, and
interoperability.

The
[PQ Signature Verify precompile](/arc/concepts/execution-layer#protocol-precompiles)
enables `SLH-DSA-SHA2-128s` as an application-layer authorization primitive. A
contract can accept a message, public key, and signature in calldata, verify
them onchain, and conditionally execute state changes without requiring the
signer to hold an Arc account.

Ecosystem constraints to keep in mind:

* Hardware wallet support will take time to mature.
* Post-quantum standards are still evolving, so long-term signature choices may
  change.

<Warning>
  Expect a transition period as tooling, wallet support, and integrations
  mature.
</Warning>

## Post-quantum privacy

[Arc Privacy](/arc/concepts/opt-in-privacy) addresses the harvest-now,
decrypt-later threat. Users encrypt their transactions and call queries using
HPKE with `X-Wing KEM` (combining `X25519` and `ML-KEM-768`), `HKDF-SHA256`, and
`AES-256-GCM`. All communication with Arc Privacy nodes occurs over TLS 1.3 with
`X25519MLKEM768` (also combining `X25519` and `ML-KEM-768`).

Attackers can capture encrypted data today and attempt to decrypt it later when
quantum attacks become practical. Arc privacy nodes encrypt contract state and
event logs with post-quantum encryption to protect sensitive balances and
transaction details.

## Post-quantum validator signatures

Validator authentication also requires post-quantum protection to keep the
ledger resilient. Arc adds post-quantum validator signatures in a later phase.

This sequencing is intentional: validator upgrades must be introduced carefully
to preserve throughput, latency, and operational reliability. Because Arc uses
sub-second finality, the window to exploit validator signatures is narrower than
the wallet-signature risk, making wallets the higher-priority target.

## Offchain infrastructure

Quantum resilience extends to the entire blockchain stack and surrounding
infrastructure. Circle's roadmap includes upgrading node-to-node communication
to TLS 1.3 with `X25519MLKEM768` hybrid key agreement and implementing HPKE
encrypted data flows. Arc infrastructure will use post-quantum configurations
for cloud environments and operational systems.

Offchain traffic and stored data face the same post-quantum threat vectors as
onchain data when vulnerable cryptography remains in use.