> 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/5.-smart-contracts-and-arc-network-settlement/5.4-deployments-and-interfaces.md). # 5.4 Network Parameters, Deployments & Interfaces This reference distinguishes the compiled registry interface from a proposed deadline-aware redesign. They are not interchangeable. Integrators must use the ABI of the exact deployment that holds their funds, not an interface inferred from product terminology. No verified production or testnet registry address is established in this release. A displayed external $ARCV token address is not the bounty registry. Do not construct a deposit transaction until the registry's deployment record and code have been independently verified. ## Arc network parameters | Parameter | Production network | Public testnet | | --------------------- | ---------------------------- | --------------------------------- | | Network | Arc mainnet | Arc Testnet | | Chain ID | 5042 | 5042002 | | Native currency | USDC | Testnet USDC | | Native-value decimals | 18 | 18 | | Public RPC | | | | Explorer | | | These network values are documented in [Arc's official connection reference](https://docs.arc.io/arc/references/connect-to-arc). They identify networks, not an ARCV deployment. A testnet balance has no claim on production USDC, and identical-looking addresses on two chains must be treated as separate deployments. Native value is supplied in transaction value and exposed to the contract as msg.value. No ERC-20 allowance call is part of createBounty. Network gas and escrow both use the native denomination, but they are separate costs. ## Complete callable interface for the current registry The following standalone interface includes all current public functions, generated getters, events, and custom errors, including inherited role-management methods. It excludes the constructor because Solidity interfaces cannot declare one. Deployment construction separately requires a nonzero administrator and external token address. ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.28; interface IARCVDataBountyRegistry { error AccessControlBadConfirmation(); error AccessControlUnauthorizedAccount(address account, bytes32 neededRole); error CapacityExhausted(); error DatasetNotPending(); error DuplicateArweaveTxId(); error DuplicateHash(); error EmptyReason(); error IncorrectEscrow(uint256 expected, uint256 received); error InvalidAddress(); error InvalidPayload(); error InvalidSpecification(); error PayoutFailed(); error ReentrancyGuardReentrantCall(); error UnknownBounty(); event ARCVTokenUpdated(address indexed previousToken, address indexed newToken); event BountyCreated( uint256 indexed bountyId, address indexed sponsor, uint256 targetCount, uint256 rewardPerSample, string dataSchemaURI, uint256 escrow ); event DatasetSubmitted( uint256 indexed datasetId, uint256 indexed bountyId, bytes32 indexed dataSha256, string arweaveTxId, address contributor ); event DatasetPaid(uint256 indexed datasetId, address indexed contributor, uint256 amount); event DatasetRejected(uint256 indexed datasetId, string reason); event RoleAdminChanged( bytes32 indexed role, bytes32 indexed previousAdminRole, bytes32 indexed newAdminRole ); event RoleGranted(bytes32 indexed role, address indexed account, address indexed sender); event RoleRevoked(bytes32 indexed role, address indexed account, address indexed sender); function createBounty( uint256 targetCount, uint256 rewardPerSample, string calldata dataSchemaURI ) external payable returns (uint256 bountyId); function submitDataset( uint256 bountyId, bytes32 dataSha256, string calldata arweaveTxId, address contributor ) external returns (uint256 datasetId); function validateAndDisburse(uint256 datasetId) external; function rejectDataset(uint256 datasetId, string calldata reason) external; function setARCVToken(address externalARCVToken) external; function DEFAULT_ADMIN_ROLE() external view returns (bytes32); function VALIDATOR_AGENT_ROLE() external view returns (bytes32); function BUNDLER_ROLE() external view returns (bytes32); function arcvToken() external view returns (address); function bountyCount() external view returns (uint256); function datasetCount() external view returns (uint256); function totalEscrow() external view returns (uint256); function usedHashes(bytes32 dataSha256) external view returns (bool); function usedArweaveTxIds(bytes32 txKey) external view returns (bool); function bounties(uint256 bountyId) external view returns ( address sponsor, uint256 targetCount, uint256 rewardPerSample, uint256 remainingEscrow, uint256 pendingCount, uint256 paidCount, string memory dataSchemaURI ); function datasets(uint256 datasetId) external view returns ( uint256 bountyId, bytes32 dataSha256, string memory arweaveTxId, address contributor, uint8 status ); function hasRole(bytes32 role, address account) external view returns (bool); function getRoleAdmin(bytes32 role) external view returns (bytes32); function grantRole(bytes32 role, address account) external; function revokeRole(bytes32 role, address account) external; function renounceRole(bytes32 role, address callerConfirmation) external; function supportsInterface(bytes4 interfaceId) external view returns (bool); } ``` The DatasetStatus enum is encoded as uint8: None=0, Pending=1, Paid=2, Rejected=3. The public getters return default values for unknown identifiers. Require a nonzero campaign sponsor or a recognized non-None dataset status rather than treating a successful eth\_call as existence proof. The interface's inclusion of supportsInterface does not mean the implementation advertises the XOR interface ID of this entire documentation interface. The inherited implementation advertises its supported ERC-165/access-control interfaces. Verify the compiled runtime and expected ABI rather than assuming a newly written Solidity interface is registered on-chain. Function selectors depend on the function name and canonical argument types. Replacing a string schema URI with bytes32 plus a deadline changes the selector. Replacing datasetId with bounty/recipient/hash/storage arguments also changes the selector. Adding these declarations to a frontend ABI cannot add corresponding functions to deployed bytecode. ## Transaction and receipt semantics createBounty requires targetCount and rewardPerSample greater than zero, a nonempty schema URI, and exactly their product in native value. It returns the new bounty ID to an on-chain caller. An externally submitted transaction's receipt does not contain that Solidity return value; decode BountyCreated to recover the ID. submitDataset similarly emits DatasetSubmitted with the assigned datasetId. Do not predict an ID by incrementing a cached counter because other operators can register concurrently. validateAndDisburse accepts that datasetId, not the bountyId. Before paying, read the registered recipient and reward. The current validator cannot pass a different recipient or amount in its call. It can approve or reject a pending record. If the recipient transfer fails, the transaction reverts with PayoutFailed and state remains Pending. | Error family | Client response | | ------------------------------------ | ---------------------------------------------------------------------- | | AccessControlUnauthorizedAccount | Verify signer and current role; do not retry with arbitrary identities | | IncorrectEscrow | Recalculate integer native value from campaign inputs | | DuplicateHash / DuplicateArweaveTxId | Reconcile existing registration | | CapacityExhausted | Inspect paid and pending slots | | DatasetNotPending | Read current status; a prior success may already exist | | InvalidPayload / InvalidAddress | Correct metadata before registration | | PayoutFailed | Investigate recipient acceptance; do not mark the payment complete | Contract errors are transaction failures, not necessarily contributor misconduct. Do not automatically add reputation strikes for infrastructure or role-configuration errors. ## Proposed deadline-aware interface: not implemented The requested redesign is shown separately so its intended API is explicit. This interface declaration compiles, but there is no implementing contract in this release, no matching deployment, and no production safety guarantee attached to it. ```solidity // SPDX-License-Identifier: MIT pragma solidity 0.8.28; interface IARCVDataBountyRegistryProposed { function createBounty( bytes32 schemaHash, uint256 maxTasks, uint256 rewardPerTask, uint256 deadline ) external payable returns (uint256 bountyId); function validateAndDisburse( uint256 bountyId, address payable contributor, bytes32 datasetHash, string calldata arweaveTxId ) external; function cancelBounty(uint256 bountyId) external; function registeredHashes(bytes32 datasetHash) external view returns (bool); } ``` This redesign merges registration and payment inputs at the validator boundary. It does not preserve the current separate bundler registration flow by itself. It also omits a Merkle-root argument, so it cannot implicitly establish direct on-chain Merkle verification. Before implementation, specify whether registeredHashes is reserved on submission or successful payment; whether rejection releases it; whether uniqueness is global or campaign-scoped; and how concurrent settlement and cancellation interact. Define timestamp units, the exact deadline boundary, pending-work treatment, refund recipient handling, and liabilities already earned by contributors. | Concept | Current ABI | Proposed redesign | | -------------- | --------------------------- | ------------------------------------------------- | | Schema | Nonempty URI string | bytes32 commitment | | Payable units | targetCount | maxTasks | | Expiry | None | deadline field | | Registration | Separate submitDataset call | Not defined by the proposed interface | | Payout | Existing datasetId | Bounty, recipient, hash, archive ID | | Replay getter | usedHashes | registeredHashes | | Sponsor refund | Absent | cancelBounty declaration requiring implementation | Publishing a proposed ABI is not a migration. The current contract has no proxy upgrade path or sponsor withdrawal method to move existing liabilities into a replacement. A deployment plan must handle that constraint explicitly. ## Environment configuration contract | Key | Purpose | Exposure and validation | | --------------------------------------- | -------------------------------- | ------------------------------------------------------------------------ | | NEXT\_PUBLIC\_ARC\_CHAIN\_ID | Expected application network | Public; allow only the explicitly supported chain | | NEXT\_PUBLIC\_BOUNTY\_REGISTRY\_ADDRESS | Verified chain-specific registry | Public; reject missing, malformed, zero, or unverified values | | ARC\_RPC\_URL | Server-side RPC endpoint | May embed provider credentials; keep private URLs out of source and logs | These keys define the recommended registry integration configuration. They are not currently sufficient to wire the enterprise UI to the registry: the reviewed frontend has no consumer for NEXT\_PUBLIC\_BOUNTY\_REGISTRY\_ADDRESS. Its existing swap network configuration uses separate settings. Adding an environment value does not implement escrow transactions. NEXT\_PUBLIC values are suitable only for public configuration and can be embedded in a Next.js client build. Never place a signer key or private RPC credential in such a variable. Keep server signing material in a controlled signer or secret manager, separate from the public registry address. Because no verified deployment address is established, an example must not invent one or silently use the zero address. The following complete Python helper asks for the verified address and produces a local three-key configuration. Save it as configure\_registry.py and run it in the frontend root. It refuses to overwrite an existing .env.local and does not deploy or send transactions. ```python import re from pathlib import Path NETWORKS = { "5042": "https://rpc.mainnet.arc.io", "5042002": "https://rpc.testnet.arc.io", } def main() -> None: chain = input("Arc chain ID (5042 or 5042002): ").strip() if chain not in NETWORKS: raise SystemExit("Unsupported chain ID") address = input("Independently verified registry address: ").strip() if not re.fullmatch(r"0x[0-9a-fA-F]{40}", address): raise SystemExit("Invalid registry address") if int(address[2:], 16) == 0: raise SystemExit("Zero registry address is not permitted") text = ( f"NEXT_PUBLIC_ARC_CHAIN_ID={chain}\n" f"NEXT_PUBLIC_BOUNTY_REGISTRY_ADDRESS={address}\n" f"ARC_RPC_URL={NETWORKS[chain]}\n" ) destination = Path(".env.local") with destination.open("x", encoding="utf-8", newline="\n") as output: output.write(text) print("Created local configuration; verify deployed code before funding.") if __name__ == "__main__": main() ``` The same key names belong in an eventual .env.example contract, but a real address must come from a verified deployment record. This documentation update creates no environment file and supplies no fictitious deployment value. The repository ignores .env\*; do not force-add actual local configuration during a documentation commit. ## Build artifacts and preflight From contracts, regenerate the ABI and inspect method selectors from the exact source used for release: ```bash forge build forge inspect ARCVDataBountyRegistry abi --json forge inspect ARCVDataBountyRegistry methodIdentifiers --json ``` The artifact resides at out/ARCVDataBountyRegistry.sol/ARCVDataBountyRegistry.json. Preserve its ABI, compiler metadata, source/dependency versions, constructor configuration, and deployed-bytecode comparison as release evidence. Keep generated build directories out of source checkpoints. A read-only preflight must check the RPC-reported chain, nonempty runtime code, runtime identity against verified source, expected role constants, and deployment-specific role membership. Code presence and successful getters alone do not authenticate an address: another contract can imitate those methods. Before signing a campaign deposit, also simulate the exact call with the selected account and value, estimate gas, and verify the user's total required native balance. Simulation can become stale before inclusion; it is not a guarantee of transaction success. Decode the actual receipt and re-read state after confirmation. ## Deployment acceptance record The release record must identify chain ID, registry address, creation transaction and block, source revision, compiler settings, dependency commits, runtime identity, constructor arguments, and current administrator/operational roles. Record role grants and revocations rather than assuming constructor deployment authorized validators. No source-level code hash can substitute for verifying the live deployment. Likewise, a token launch on faze.fun does not deploy this registry. The external token, registry, treasury, validator signer, and bundler signer are separate roles and addresses. Test the selected deployment with a bounded campaign before accepting enterprise funds, including registration, successful payout, duplicate rejection, unauthorized access, and recipient failure. Document unresolved liveness and refund limitations prominently. Completing a deployment transaction does not create the cancellation, fee, or pause features described only in a proposed interface. --- # 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/5.-smart-contracts-and-arc-network-settlement/5.4-deployments-and-interfaces.md?ask=&goal= ``` `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.