How to read an Arc project entry

Every entry on Built on Arc carries the same five fields and the same verification block, regardless of whether it's a memecoin launchpad or a bank running a settlement pilot. This page explains what each field means, what the verification block checks, and how to run those same checks yourself against the primary source rather than taking this site's word for it.

The five fields, and why they're the same for every entry

Built on Arc used to run a single trust-block methodology — contract verification, liquidity locks, audits, open-source status — across every listing. That model made sense for a token launch. It made no sense at all applied to a bank or a payments processor, where "is the liquidity locked" isn't an unknown, it's a question that doesn't apply. So every entry now carries five fields that work regardless of what kind of project it is:

Builds on Arc — one editor-written sentence, capped at 120 characters, stating what the project actually does with the chain and for whom. It's never copied from the project's own tagline, and it never asserts Arc usage the evidence doesn't support — if Arc support is unconfirmed, the sentence says what the project does generally and the status field carries the uncertainty.

Role — one of four: Deploys (runs its own contracts on Arc), Issues (mints a stablecoin or tokenized asset natively on Arc), Integrates (an existing product that added Arc as a rail for its own customers), or Serves (infrastructure other builders depend on — RPC, custody, oracles, compliance tooling). A small number of entries also carry a Founding validator mark alongside their role — the mark is not a role on its own; it sits next to whichever of the four actually describes what the entity builds.

Category → subcategory — where the entry sits in Built on Arc's ten-category structure, linked from the category page itself.

Status + dated evidence — Live on Arc, Testnet, Announced, or Inactive, each with a source and a date attached. This is the field that actually tells you how far along something is, and it's covered in full in Every project building on Arc.

Tier — Editor's Index or Listing. Tier is a paid-submission and editorial-curation label, not a claim about the underlying project.

The verification block: what replaces the old trust block

Instead of a single trust-block table, every entry carries a verification block with three components: an official source (the project's own site, social account, or a press release naming it), the claimed listing itself (what the project or a third party says is true about its Arc involvement), and whether the product is live to customers (a working product a real user can actually reach, as distinct from a testnet deployment or an announcement). Reading these three side by side is usually enough to tell you how much weight a claim can bear — a project with an official source, a specific claimed listing, and a live customer-facing product is in a different category of evidence than one with only a press mention and no product a customer can touch.

On-chain checks: project-page only, and only for two roles

Contract verification and liquidity-lock status appear on individual project pages, not as a directory-wide badge or a homepage number, and only for entries with a Deploys or Issues role — because those are the only roles where a token, pool, or deployer address actually exists to check. A bank running an Arc settlement pilot has no liquidity to lock; asking whether its pool is locked isn't a strict question with an unknown answer, it's a question that doesn't apply to that entry at all. Where a check can't apply, the project page shows "Not applicable" — never "not met," and never blank. That distinction matters: "not met" reads as a deficiency, and a bank isn't deficient for not having a liquidity pool.

Where a check does apply — a launchpad's token, a DEX's pool — locking services publish lock duration and admin details on-chain, independently checkable by anyone. Team Finance is one such locker. *Disclosure: Built on Arc is operated within the TrustSwap ecosystem, which includes Team Finance and MintPlus.* Contract verification works the same way: it means the deployed bytecode has been matched to human-readable source code, checkable on Arc's testnet explorer at testnet.arcscan.app today, and on a mainnet explorer once Circle publishes one after 16 September 2026.

None of this — locked liquidity, a verified contract, a published audit, open-source code — is presented anywhere on this site as a universal signal every entry either has or lacks. They're checks that apply to some roles and not others, and their presence or absence is a fact about that entry's evidence, not a mark against entries where the check simply doesn't apply.

The three flags — and what they aren't

Built on Arc uses exactly three flags, and nothing else is a flag:

• Unverified claim — the project publicly claims a status this site can't independently confirm (its site says "live on Arc mainnet," the chain shows testnet or nothing). Cleared the moment the claim is confirmed.
• Lookalike — a name or domain designed to imitate another listed project or Circle/Arc branding itself (think arc-airdrop.* or uarc-official.*). The entry stays listed specifically so someone searching that name finds the warning rather than nothing.
• Under review — a correction or dispute is open and the status may change. Neutral, not a red mark — cleared once the review resolves.

A missing liquidity lock is not a flag. A missing audit is not a flag. Neither is the absence of a publicly identified team, or unverified contract source. Those are states an on-chain check can show — locked, unlocked, verified, unverified, not applicable — and they live on the project page as evidence, not in the flag system. Built on Arc flags claims and impersonation; it does not flag the ordinary condition of a pre-mainnet project that hasn't published an audit yet, and readers shouldn't read the absence of one as a mark against it.

Checking any entry yourself

The methodology is the same regardless of role. Start with the official source in the verification block and navigate to it independently — search for the project rather than clicking through — and confirm its own channels agree with what's claimed here. Check the status field's dated evidence against that source directly; a status is only as good as the date and link behind it, and this site revises status rather than deleting the history when something changes. If the entry has a Deploys or Issues role, check the on-chain items yourself on Arc's testnet explorer rather than trusting a label in any interface, including this one. And treat every check as time-stamped: a lock has an expiry, an audit covers a specific commit, and a team's usual channels can change — if something looks different from the last time you checked, redo the check rather than assume nothing moved.

Where the rest of this lives

Built on Arc's own scope stops at status and verification. For checking whether it's a reasonable idea to actually buy or trade an Arc-based token — wallet setup, contract-scanner and honeypot-detection tooling, the mechanics of a purchase — that content belongs to Meme Central, which owns Arc consumer and trading how-to coverage. For anything involving yield, APY, or lending rates on Arc, see ArcYield — Built on Arc covers a DeFi or credit entry's status and links only, never its earn angle.

Sources: - Arc ecosystem page