> For the complete documentation index, see [llms.txt](https://docs.arcv.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arcv.network/1.-overview-and-protocol-fundamentals/1.3-network-parameters.md).

# 1.3 Network Parameters

## Reference scope

This reference separates network parameters, repository behavior, and deployment requirements. Connection values were checked against official Arc documentation on **6 October 2026**. They identify the network; they do not certify an ARCV registry deployment, an archive upload, or the production environment configuration of the website.

Configuration must be versioned with the application release. A valid network endpoint can serve a deployment unrelated to ARCV, and an address can contain different code on different chains. Network identity, contract identity, and interface compatibility must be verified together.

## Settlement chain specifications

| Parameter                      | Arc mainnet                                                 | Arc public testnet                                                  |
| ------------------------------ | ----------------------------------------------------------- | ------------------------------------------------------------------- |
| Network                        | Arc Network L1                                              | Arc Testnet                                                         |
| EVM chain ID, decimal          | `5042`                                                      | `5042002`                                                           |
| EVM chain ID, hexadecimal      | `0x13b2`                                                    | `0x4cef52`                                                          |
| Native gas and value currency  | USDC                                                        | Testnet USDC                                                        |
| Native-value decimal precision | 18                                                          | 18                                                                  |
| Public HTTPS JSON-RPC          | `https://rpc.mainnet.arc.io`                                | `https://rpc.testnet.arc.io`                                        |
| Block explorer                 | [Arc Explorer](https://explorer.arc.io)                     | [Arc Testnet Explorer](https://explorer.testnet.arc.io)             |
| Transaction lookup             | Explorer origin followed by `/tx/` and the transaction hash | Testnet explorer origin followed by `/tx/` and the transaction hash |
| Address lookup                 | Explorer origin followed by `/address/` and the address     | Testnet explorer origin followed by `/address/` and the address     |

The IDs, native currency precision, and endpoints are published in the [Arc connection reference](https://docs.arc.io/arc/references/connect-to-arc). Do not substitute a testnet RPC while retaining the expected mainnet chain ID, and do not interpret testnet balances as transferable production value.

### Block production, finality, and application timing

Arc's indexing documentation describes deterministic finality and sub-second block production. It also notes that multiple blocks can share the same second-resolution timestamp. The documented property is not an ARCV-measured fixed block interval, and it does not establish a universal end-to-end response-time guarantee. [Arc event indexing](https://docs.arc.io/integrate/infrastructure/indexing-events).

| Timing concept        | Meaning                                                       | Integration rule                                                               |
| --------------------- | ------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Block interval        | Time between successive produced blocks                       | Treat observed timing as variable; do not hard-code one transaction per second |
| Consensus finality    | Network acceptance of a block under its consensus assumptions | Distinguish a finalized receipt from a transaction hash returned at broadcast  |
| RPC latency           | Time for a provider to answer a request                       | Use bounded timeouts and provider monitoring                                   |
| Indexer latency       | Delay before derived event views catch up                     | Reconcile settlement directly with chain receipts and storage                  |
| Gateway latency       | Time to obtain archived or cached bytes                       | Measure separately from chain finality                                         |
| Full workflow latency | Assignment through validation, archival, and payment          | Do not infer it from network block timing                                      |

An indexer should identify an event by transaction hash and log index and retain block identity. `block.timestamp` is not a unique event key. A deterministic-finality chain still requires clients to detect the wrong network, inconsistent provider responses, dropped subscriptions, and failed transactions. These are operational failures, not evidence that a broadcast succeeded.

### RPC request specifications

| Method                         | Use in an ARCV integration                                | Required interpretation                                                  |
| ------------------------------ | --------------------------------------------------------- | ------------------------------------------------------------------------ |
| `eth_chainId`                  | Verify selected network                                   | Decode the hexadecimal quantity and compare to the configured numeric ID |
| `eth_getBalance`               | Read native USDC available to a wallet or contract        | Interpret the native balance with 18 decimals; record the block context  |
| `eth_getCode`                  | Confirm code exists at the intended contract              | Nonempty code is necessary but not sufficient deployment verification    |
| `eth_call`                     | Read getters or simulate a read-only contract invocation  | Match the ABI and distinguish default values from existing records       |
| `eth_estimateGas`              | Estimate execution requirements                           | Estimate against the actual sender, calldata, and native value           |
| `eth_getTransactionReceipt`    | Determine mined success or revert                         | A transaction hash alone has no success status                           |
| `eth_getLogs`                  | Reconcile registry events                                 | Use bounded block ranges and stable resume cursors                       |
| `eth_subscribe` over WebSocket | Receive live event or block notifications where supported | Backfill missed ranges after reconnect rather than assuming delivery     |

Provider limits are not protocol constants. Authentication, batch size, historical retention, maximum log ranges, and WebSocket availability depend on the selected service. No unlimited public-RPC quota or historical archive guarantee is specified here. A production operator should contract for the capacity it needs and verify the relevant methods against its provider.

This read-only command checks mainnet identity without wallet access:

```bash
curl --fail-with-body --silent --show-error \
  --connect-timeout 5 --max-time 15 \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' \
  https://rpc.mainnet.arc.io
```

For the configured mainnet endpoint, the expected result is `0x13b2`. Treat a JSON-RPC `error` object as a failure even if HTTP transport returns status 200. This example documents the request and expected identity; it is not a report of a transaction or a funded deployment.

## Native USDC economics and amount precision

Native USDC removes the need to acquire a separate volatile gas token before funding or settling an Arc transaction. This reduces the exchange-rate mismatch between a USDC-denominated task budget and the asset used for gas. It does not make gas free or fixed, eliminate price impact in a token swap, or remove stablecoin and network risks. “Zero volatile gas slippage” is therefore a description of avoiding an additional gas-asset conversion, not a guarantee of zero transaction-cost variation.

The registry accepts escrow through `msg.value` and pays native value to the registered recipient. It does not require ERC-20 allowance for this flow. The native amount convention must be preserved from frontend input parsing through transaction construction and accounting.

| Human-readable amount |      Native base units |
| --------------------: | ---------------------: |
|             0.01 USDC |    `10000000000000000` |
|             0.25 USDC |   `250000000000000000` |
|                1 USDC |  `1000000000000000000` |
|               25 USDC | `25000000000000000000` |

Use decimal-string parsing and integer arithmetic. A six-decimal ERC-20 convention is not interchangeable with the native-value interface. A transaction funding 100 payable units at 0.25 USDC requires 25 USDC as value plus sufficient additional balance for gas. Sending the full wallet balance as value can leave the transaction unfunded for execution.

The current registry requires exactly `targetCount × rewardPerSample`, without an additional settlement fee. Its payment amount is fixed by the bounty. Proposed fee waterfalls in [Section 6](/6.-protocol-economics-and-tokenomics/6.2-protocol-revenue-engine.md) do not change that source behavior. Displayed enterprise fee estimates must not be passed to this contract as excess `msg.value`.

## Contract and deployment identity

| Field                 | Required release evidence                                                                 |
| --------------------- | ----------------------------------------------------------------------------------------- |
| Registry address      | Address from a verified deployment receipt on the selected chain                          |
| Source and compiler   | Source revision, Solidity 0.8.28, Cancun target, optimizer settings matching the artifact |
| Runtime identity      | Verified source and bytecode comparison, not merely a familiar name                       |
| Administrator         | Current holder or holders of `DEFAULT_ADMIN_ROLE`                                         |
| Operational authority | Actual bundler and validator role grants                                                  |
| Token reference       | External token selected by `arcvToken`; separate from escrow currency                     |
| Replay interface      | `usedHashes(bytes32)` and `usedArweaveTxIds(bytes32)`                                     |
| Fund recovery         | No cancellation, expiry refund, or sponsor withdrawal method in the reviewed registry     |

The repository's Foundry configuration uses 200 optimizer runs. The interface named `registeredHashes` in earlier design language is not present; integration code must call `usedHashes`. A missing record can return default values through a public getter, so an apparently successful read does not prove registration.

No registry deployment address is certified by this chapter. A token address appearing in a frontend specification card is not a bounty registry address. For exact callable signatures and verification steps, use [deployment interfaces](/5.-smart-contracts-and-arc-network-settlement/5.4-deployments-and-interfaces.md).

## Decentralized storage infrastructure

### Cold storage and ingestion contract

The intended archival destination is Arweave, with an Irys integration providing the selected upload and retrieval path. The integration must identify its actual network, client version, payment mechanism, receipt semantics, and underlying settlement evidence. An endpoint carrying the Irys brand or returning an identifier is not by itself proof that the bytes were permanently recorded on Arweave.

| Layer                 | Input                                                | Output                               | Acceptance condition                                              |
| --------------------- | ---------------------------------------------------- | ------------------------------------ | ----------------------------------------------------------------- |
| Canonical serializer  | Accepted data and manifest fields                    | Exact immutable artifact bytes       | Schema and transformation versions are recorded                   |
| Hashing stage         | Final bytes after redaction and encryption policy    | SHA-256 digest and byte count        | Independent recomputation produces the same digest                |
| Upload adapter        | Artifact and provider-specific payment authorization | Upload receipt and object identifier | Receipt is bound to the submitted artifact and configured network |
| Archival verification | Receipt, identifier, and retrieval response          | Storage confirmation record          | Underlying archival evidence and fetched bytes are verified       |
| Registry binding      | Bounty, digest, TxID, recipient                      | Pending dataset record               | Authorized registration succeeds and fields match                 |
| Retrieval service     | Authorized dataset version request                   | Manifest and immutable shards        | Entitlement, byte count, and integrity checks pass                |

A bundler data-item identifier and an underlying base-layer transaction identifier may have different meanings. The chosen adapter must document which identifier is recorded and how a verifier follows its inclusion evidence. The registry checks a 43-character base64url-shaped string but does not independently interpret that proof.

### Retention economics and the meaning of permanence

Arweave's lightpaper describes an up-front storage endowment priced around 200 years of replicated storage at prevailing costs, with long-term sustainability depending on its economic assumptions. This is a storage-incentive design, not an unconditional warranty that every upload will remain retrievable for more than 200 years under every future condition. [Arweave storage endowment](https://www.arweave.org/files/arweave-lightpaper.pdf).

ARCV's requirement is to preserve immutable accepted versions and retain evidence that the intended storage settlement occurred. A gateway acknowledgment cannot be promoted into a centuries-long guarantee by wording alone. Availability depends on the storage network, the correctness of upload integration, usable retrieval paths, and the continued ability to decrypt encrypted records.

Encrypted archival introduces a separate longevity requirement: retaining ciphertext without retaining authorized decryption capability does not preserve usable training data. Conversely, destroying a key does not erase publicly archived ciphertext or exposed metadata. Data minimization, redaction, and access-policy decisions must precede irreversible upload.

Corrections produce new artifact versions linked to their predecessors. A manifest should distinguish superseded data from preferred data without claiming that the old bytes have been removed from permanent storage. A system serving only a mutable “latest” pointer is insufficient for reproducing a historical training run.

### Hot query cache and training interfaces

| Cache or loader property | Required specification                                                         |
| ------------------------ | ------------------------------------------------------------------------------ |
| Object identity          | Digest-addressed immutable version; no silent replacement                      |
| Cache hit behavior       | Same verified bytes and entitlement rules as the authoritative source          |
| Cache miss behavior      | Retry or archival fallback with explicit timeout and error handling            |
| Restricted data          | Authorization before serving and separately controlled decryption capability   |
| Shard manifest           | Format, byte count, digest, record count, schema version, and split membership |
| PyTorch workers          | Explicit worker and distributed-rank partitioning to avoid duplication         |
| Hugging Face iteration   | Stable schema and iterable record semantics appropriate to the workload        |
| Training reproducibility | Pinned tokenizer and transformation versions, shuffle policy, and resume state |
| Performance reporting    | Measured throughput and latency distributions with workload and region stated  |

The edge cache is a performance layer, not the authority for provenance. A low-latency response containing the wrong bytes must be rejected. No numeric cache-latency or GPU-utilization guarantee has been established by this repository. Performance targets require representative load testing, shard-size selection, and measurement of both warm and cold retrieval paths.

Whole-shard SHA-256 validation requires receiving the complete shard before its digest is known. Applications should verify bounded shards before yielding their records, or define an authenticated chunk structure when progressive verification is required. Do not describe an unchecked HTTP stream as cryptographically verified merely because a digest appears in its manifest.

The [provenance and dataloader chapter](/3.-enterprise-and-frontier-ai-labs/3.3-provenance-and-dataloaders.md) supplies explicit Python integration examples. It does not establish publication or ownership of a package named `arcv`. A production dependency must be verified before installation instructions are presented as an official SDK release.

## Official routing directory

The following directory describes the reviewed application source. Hosted availability and production environment configuration must be checked separately when releasing changes.

| Workspace              | URL                                                        | Implemented scope and boundary                                                                                                         |
| ---------------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Production website     | [arcv.network](https://arcv.network)                       | Protocol landing page and navigation                                                                                                   |
| Contributor portal     | [arcv.network/annotate](https://arcv.network/annotate)     | Pairwise evaluation, rubric controls, Golden Patch and copilot tools; displayed validation and contributor settlement remain simulated |
| Enterprise lab portal  | [arcv.network/enterprise](https://arcv.network/enterprise) | Payload parsing, campaign settings and vault interface; bounty deployment UI remains simulated                                         |
| DEX and burn telemetry | [arcv.network/market](https://arcv.network/market)         | Wallet-signed swap implementation requiring configured token/router deployments; burn statistics remain simulated                      |
| Validator hub          | `https://arcv.network/validate`                            | Reserved route; no page or redirect is implemented in the reviewed source                                                              |
| Documentation          | `https://docs.arcv.network`                                | Intended publication destination for these versioned Markdown chapters; source completion does not confirm publication                 |

Navigation maps **SOURCE** to `/enterprise`, **VALIDATE** to `/annotate`, and **ARCHIVE** to `/market`. The label VALIDATE must not be interpreted as a promise that `/validate` exists. A future validator hub also requires operator authentication and signer isolation; a browser URL is not a contract role.

The swap widget uses chain `5042`, real native-balance reads, quote-derived minimum output, and receipt-confirmed success. It fails closed when the configured token or router identity is missing or mismatched. This source implementation is distinct from a confirmed live deployment and does not turn neighboring synthetic burn values into indexed chain events.

## Environment and operating boundaries

| Configuration name                | Purpose                                                          | Disclosure rule                                                       |
| --------------------------------- | ---------------------------------------------------------------- | --------------------------------------------------------------------- |
| `ARC_RPC_URL`                     | Operator or script RPC endpoint for registry reads and execution | Keep provider credentials out of public bundles and logs              |
| `BOUNTY_REGISTRY_ADDRESS`         | Verified chain-specific registry                                 | Public address; must not be inferred from the token address           |
| `NEXT_PUBLIC_ARC_RPC_URL`         | Browser-accessible Arc RPC for the swap widget                   | Public build-time value; use a provider configured for browser access |
| `NEXT_PUBLIC_ARCV_TOKEN_ADDRESS`  | Actual token being purchased                                     | Public verified token address                                         |
| `NEXT_PUBLIC_FAZE_ROUTER_ADDRESS` | That token's Faze curve contract                                 | Must match the selected launch's venue                                |
| `NEXT_PUBLIC_DEX_ROUTER_ADDRESS`  | Supported graduated-pool Universal Router                        | Must match the resolved Arc deployment                                |

A `NEXT_PUBLIC_` value is distributed to browsers and cannot hold a private key. Public addresses are configuration, not secrets; credentials and signing material require separate custody. A project can use one chain for gas, escrow, and DEX execution while still having distinct permission boundaries for the enterprise sponsor, contributor wallet, bundler, validator, and treasury.

Operational acceptance requires agreement across these boundaries: the correct chain, verified contract code, valid role assignments, exact native amounts, durable job reconciliation, verified archival bytes, and an explicitly configured retrieval policy. Each element is independently observable. None can be replaced by a successful frontend animation or an unverified status badge.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.arcv.network/1.-overview-and-protocol-fundamentals/1.3-network-parameters.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.