Risk Labs primary sources — 2026-08-12

Classification takeaway

Risk Labs clears the bar for a separate companies/ note because the useful control question around Across is no longer only how do intents, relayers, optimistic verification, and settlement work? It is also which named operator runs the hosted interface, API authentication, project-registration workflow, route-linking shell, privacy/legal perimeter, and support channels many integrators and end users inherit first? Current primary materials make that boundary unusually explicit: Risk Labs provides the website-hosted interface and related products, requires API keys and integrator IDs for production API usage, can suspend API access for security / legal / compliance reasons, and says the interface is only one means of accessing the protocol while the protocol itself is not controlled or operated by Risk Labs. That makes the project-versus-company split sharper rather than weaker.

Primary sources reviewed

1. Across homepage — https://across.to/

   • Best short source for the current product and support framing.
   • Markets Across as a single API and frontend shell for bridge / swap usage, with responsive support and a simple builder path.

2. Across Terms of Service — https://across.to/terms-of-service

   • Strongest source for the legal and operator boundary.
   • Says the products are provided by Risk Labs; defines the interface, API, and related software as Risk Labs products; says Risk Labs does not control or operate the Across protocol on blockchain networks; and reserves rights to modify, restrict, or suspend product access.

3. Across Privacy Policy — https://across.to/privacy-policy

   • Strongest source for the data-handling side of the operator boundary.
   • Says Across is operated by Risk Labs, a Cayman Islands Foundation, and that the services include the website, web app, APIs, and related properties.

4. API Keys & Integrator ID docs — https://docs.across.to/introduction/api-keys

   • Best source for production API access mediation.
   • Says production usage requires both an API key and an integrator ID, that production requests may be rate-limited or rejected without them, and that the integrator ID is assigned through the Across team.

5. Get API Key & Integrator ID tool page — https://docs.across.to/tools/integrator-id

   • Best source for the project-admission workflow.
   • Shows a company-run registration flow collecting project metadata, contact handles, website, chain usage, and intended API usage before issuing production credentials.

6. Direct Route Linking docs — https://docs.across.to/introduction/direct-route-linking

   • Useful source for the hosted frontend-shell angle.
   • Shows that Risk Labs controls a prefilled app.across.to route-linking path many partners can use instead of building fully independent user entrypoints.

7. Across docs index (llms.txt) — https://docs.across.to/llms.txt

   • Best compact map of the breadth of the operator-managed docs surface.
   • Shows that one named docs shell covers API keys, refunds, relayers, deposit tracking, embedded actions, bug bounty, AI tooling, and support-oriented integration flows.

Why it belongs in the active corpus

• Useful comparison point for interoperability stacks where open protocol claims coexist with a still-company-shaped frontend, API-auth, support, and legal shell.
• Helpful for reasoning about how decentralized protocol, hosted interface splits actually work in practice once API keys, route linking, product terms, and credential issuance become part of the easiest adoption path.
• Good companion for other routing and middleware cases such as skip, layerzero-labs, caldera, and conduit.