# Welcome to ONCHAIN® Docs *ONCHAIN®* introduces a new access layer for the internet of value — making on-chain assets instantly reachable from any interface, without custody, without bridges, and without platform gatekeeping. These docs cover the complete ONCHAIN® ecosystem: * [**Why access is broken**](/getting-started/solving-the-access-problem) * [**Universal Access Schema (UAS)**](/getting-started/universal-access-schema-uas) **→ A simple, open addressing layer** * [**Smart Guardrails**](/getting-started/smart-guardrails) **→ Verified, safe, native assets** * [**OPN**](/getting-started/the-onchain-r-protocol-network-opn) **→ Deterministic on-chain execution** * [**Gateway**](/getting-started/gateway-verification-and-intent-layer) **→ Verification + Intent broadcasting** * [**Marketplace**](/getting-started/onchain.money-marketplace) **→ The onchain.money interface** * [**Chain Integration**](/getting-started/chain-integration-program) **→ How new networks join** * [**Builders**](/getting-started/integrating-uas) **→ How to embed ONCHAIN® anywhere** # Quickstart Welcome to *ONCHAIN®* — the access layer for the internet of value. This Quickstart shows you how to embed instant, on-chain access using a single link: the Universal Access Schema. You can integrate ONCHAIN® in under 30 seconds. *** ### 1. The One Link You Need Every on-chain asset becomes reachable through a simple format: ``` https://buy.onchain.money/[chain]/[token] ``` Example (Ethereum token): ``` https://buy.onchain.money/ethereum/0xabc123... ``` Example (Base token): ``` https://buy.onchain.money/base/0x1234abcd... ``` Paste it anywhere a user can click — it “just works.” *** ### 2. Where You Can Use It Anywhere links can be placed, the schema works: * Token websites * Wallets * Telegram bots * Discord bots * Explorers (Etherscan, Basescan, etc.) * NFT marketplaces * Portfolio trackers * Launchpads * Community dashboards * CEX → DeFi off-ramps (“Withdraw to token”) > No API keys.\ > No SDK.\ > No backend. *** ### 3. Minimal Integration Example Button example for any website: ``` Buy with ONCHAIN ``` Telegram bot example (pseudo-logic): ``` "Buy now → https://buy.onchain.money/" + chain + "/" + contract ``` That’s it. *** ### 4. Supported Chains | Chain | Slug | Status | | --------- | -------- | --------- | | Ethereum | ethereum | Supported | | Base | base | Supported | | BNB Chain | bnbchain | Supported | | Polygon | polygon | Supported | | Solana | solana | Imminent | To request support for your EVM chain: 📩 *** ### 5. What Happens Behind the Scenes 1. User opens the link 2. ONCHAIN® Gateway loads token + chain 3. User pays (card, Apple Pay, Google Pay, crypto) 4. Payment is verified 5. Gateway broadcasts a BuyIntent 6. OPN executes it natively — no bridges, no custody 7. Tokens arrive in the user wallet > A single click → fully on-chain settlement. *** ### 6. Next Steps To go deeper: * Learn how to embed the schema → Integrating the UAS * Understand safety checks → Smart Guardrails * Explore the execution layer → OPN (The ONCHAIN® Protocol Network) * Try the live interface → onchain.money # Solving the Access Problem Most users never make it from curiosity to ownership. **68% of first-time users drop off before completing a single on-chain transaction.**\ The problem isn’t demand — it’s *access*. ### Why the current access stack is broken Today’s onboarding path forces users through a maze: 1. Acquire gas on a CEX 2. Wait for withdrawals 3. Install a wallet 4. Transfer funds 5. Connect to a DEX 6. Approve the token 7. Swap and hope the price hasn’t changed This *seven-step gauntlet* destroys intent, kills conversion, and keeps on-chain ecosystems from growing. ### Why access must be a *network property* Access today is *platform-controlled*: * CEX listings decide what the world can buy * Bridges and wrappers fragment markets * On-ramps support only a handful of assets To unlock a global tokenized economy, **access must be native to the network**, not granted by platforms. ### The HTTP Moment for On-Chain Value HTTP turned websites into instantly reachable destinations. The **Universal Access Schema (UAS)** does the same for on-chain assets — making every verified token resolvable through a single, open addressing format: > ] One link.\ One step.\ Instant ownership. Access becomes infrastructure, not a service. # Universal Access Schema (UAS) The **Universal Access Schema** is a standardized, deterministic URL format that makes any verified on-chain asset instantly reachable — anywhere a link can be placed. No APIs.\ No SDKs.\ No contracts to deploy.\ Just a link that routes intent through the ONCHAIN® stack. ### The Format > ] ### What the Schema Represents Each link encodes a **BuyIntent** specifying: 1. **Chain** 2. **Token contract** 3. **Verified metadata (via Smart Guardrails)** 4. **Execution path (via OPN)** Click → Payment → Deterministic on-chain settlement. ### Supported Chains | Chain | Slug | Status | | --------------- | -------- | --------- | | Ethereum | ethereum | Supported | | Base | base | Supported | | BNB Chain | bnbchain | Supported | | Polygon | polygon | Supported | | Solana | solana | Imminent | | Additional EVMs | varies | Planned | ### Example Links **Direct Token** ```html buy.onchain.money/base/0x1234abcd… ``` **Telegram Bot** ```js "Buy → https://buy.onchain.money/" + chain + "/" + address ``` **Website CTA** ```html Buy with ONCHAIN ``` ### What Happens When a User Opens a Link 1. Gateway loads token context 2. User selects payment method 3. Payment is verified 4. Gateway broadcasts a BuyIntent 5. OPN executes deterministically 6. Tokens settle directly to the user’s wallet No bridges.\ No wrapping.\ No custody.\ No redirects. Access becomes a primitive. # Integrating UAS # The Integrator Mental Model The Universal Access Schema (UAS) is not an API. It is not an SDK. It is not a widget. It is a **protocol primitive** — a link format that behaves more like: * `mailto:` * `sms:` * `https://…/pay` * deep links used in mobile apps Anywhere a link can be placed, the UAS can be embedded. It is a **deterministic addressing layer** for on-chain value: ``` https://buy.onchain.money/[chain]/[token] ``` That URL *is* the integration. ### How the mental model works Think in terms of: #### **1. You provide context** The integrator chooses: * the **chain** * the **token contract** #### **2. Gateway interprets the intent** The *ONCHAIN®* Gateway: * loads the asset * checks verification + compliance * prepares payment routes #### **3. OPN executes** OPN fulfills the intent natively on the asset’s home chain: * no bridges * no wrapping * no custody #### **4. Tokens land directly in the user’s wallet** Fully settled, verified, final, on-chain. ### What integrators *don’t* need * No backend server * No signing * No API keys * No auth * No rate limits * No RPC calls * No gas logic * No ABI knowledge If you can construct a string, you can integrate the Universal Access Schema. This is why UAS integrates cleanly into: * Telegram bots * Discord bots * Websites * Wallets * Scanners * Launchpads * Marketplaces * Token pages * Portfolio apps * CEX off-ramping flows The entire model collapses into one simple operation: **Generate the URL → Display the URL → User clicks the URL.** That’s it. # Dynamic Link Generation Dynamic Link Generation describes how integrators construct UAS links that execute deterministically at the moment of intent. A UAS link encodes everything required for execution directly in the URL. There is no session state, no custody handoff, and no dependency on listings, approvals, or negotiated routing. These links are portable and permissionless by design, allowing execution intent to originate from any surface — wallets, bots, launchpads, explorers, or external applications — while settling locally and natively on-chain. *** #### What This Section Covers The following pages describe how to correctly construct UAS links: * Link Anatomy Understand the structure of a UAS link and how execution context is encoded. * Required Parameters Learn which parameters must be present for execution to occur. * [Optional Attribution Parameters (UTM)](/getting-started/integrating-uas/dynamic-link-generation/optional-attribution-parameters-utm) Add execution attribution without affecting routing, pricing, or access guarantees. * Examples Copy-paste reference links for common integration surfaces. *** #### Key Principles * All execution context is encoded in the link * No custody, no session state, no platform control * Attribution is optional and informational only * Execution behavior is deterministic and surface-agnostic *** This section is the single source of truth for generating executable UAS links. All surface-specific integrations should reference these pages rather than redefining link behavior elsewhere. # Link Anatomy The Universal Access Schema (UAS) is a standardized, permissionless URL format that enables direct execution into an on-chain asset at the moment of intent. A UAS link is not a redirect or deep link into an application. It is a self-contained execution instruction that can be generated by any surface — wallets, bots, launchpads, dashboards, explorers, or static pages — without backend infrastructure. *** ### The Universal Access Schema (UAS) The most common integration pattern for UAS is to dynamically generate a link using the following base format: ``` https://buy.onchain.money/[chain]/[token] ``` This link alone is sufficient to initiate execution. * No backend required * No API keys * No authentication * No listings or approvals Even a static site or bot can generate valid UAS links. *** ### Base Format ``` https://buy.onchain.money/[chain]/[token] ``` #### Components | Component | Description | | ----------------- | ---------------------------------- | | buy.onchain.money | ONCHAIN Gateway execution endpoint | | \[chain] | Chain identifier (slug) | | \[token] | Token contract address | Example: ``` https://buy.onchain.money/ethereum/0xabc123... ``` This path encodes the execution target directly in the URL. *** ### How UAS Links Work A UAS link encodes all required execution context in the URL itself: * The chain determines where execution occurs * The token address determines what asset is accessed * Execution is evaluated at click time, not link creation time * There is no session state or stored user context If execution is possible at the moment of intent, it proceeds. If not, the link fails gracefully. *** ### Dynamic Link Generation UAS links are designed to be generated dynamically based on user context. ``` https://buy.onchain.money/ethereum/0xabc123... ``` *** #### Example: Telegram bot ``` "Buy now → https://buy.onchain.money/" + chain + "/" + contract ``` *** #### Example: Web (React) ``` const link = `https://buy.onchain.money/${chain}/${address}`; return Buy; ``` *** #### Example: Node / backend ``` function buildSchemaLink(chain, token) { return `https://buy.onchain.money/${chain}/${token.toLowerCase()}`; } ``` *** ### Recommended Practices Use lowercase token addresses Contract addresses should always be lowercase to avoid checksum or parsing issues. *** #### Validate the chain slug Only supported chain identifiers should be used. If a chain is not supported, hide the execution surface or fall back to native behavior. *** #### Do not URL-encode The schema accepts raw hex addresses without encoding. *** #### Keep links simple The base format is the integration: ``` https://buy.onchain.money/[chain]/[token] ``` Avoid unnecessary parameters unless explicitly required (e.g. attribution). *** #### Generate dynamically when possible Bots, dashboards, wallets, and scanners should construct the link directly using user-selected context. *** #### No backend required All logic can run client-side. There are no API keys, no rate limits, and no authentication requirements. *** #### Fail gracefully If a chain or token is not supported, hide the button or defer to native behavior rather than forcing execution. *** ### Attribution Parameters (Optional) UAS links may include optional attribution parameters (such as UTMs) to provide execution context. Attribution parameters: * Are optional * Do not affect execution behavior * Do not change routing, pricing, or settlement See [Optional Attribution Parameters (UTM)](/getting-started/integrating-uas/dynamic-link-generation/optional-attribution-parameters-utm) for details. # Required Parameters For the standard Universal Access Schema (UAS) buy flow, the required parameters are encoded directly in the URL path. #### Required Path Parameters ``` https://buy.onchain.money/[chain]/[token] ``` | Parameter | Description | Required | | --------- | ----------------------- | -------- | | \[chain] | Chain identifier (slug) | Yes | | \[token] | Token contract address | Yes | There are no required query parameters. *** ### \[chain] — Chain Identifier The chain parameter specifies the blockchain where execution should occur. * Must be a supported chain slug * Must be lowercase * Determines execution environment and settlement context Example: ``` ethereum polygon base ``` If the chain is not supported, execution will fail gracefully. \ \ See [Supported Chains](/getting-started/supported-chains) for details. *** ### \[token] — Token Address The token parameter specifies the on-chain asset to execute against. * Must be a valid contract address * Must be lowercase * Must correspond to the specified chain Example: ``` 0xabc123... ``` The token address is treated as a reference, not a listing or approval. *** ### Minimal Valid UAS Link This is the smallest valid execution link: ``` https://buy.onchain.money/ethereum/0xabc123... ``` If both the chain and token are valid and supported, execution can proceed. *** ### What Is Not Required The following are not required for execution: * API keys * Authentication * Backend services * Session state * Query parameters * Listings or approvals * Attribution parameters (UTMs) Execution is evaluated entirely at click time. *** ### Optional Parameters Additional parameters may be included to provide context or attribution, but they do not affect execution behavior. Examples include: * UTM parameters for attribution * Surface-specific metadata See Optional Attribution Parameters (UTM) for details. *** ### Failure Behavior If required parameters are missing, malformed, or unsupported: * Execution does not proceed * No partial execution occurs * Integrators should hide or disable the execution surface when possible= UAS is designed to fail safely and deterministically. *** ### Key Takeaway If you can generate: ``` https://buy.onchain.money/[chain]/[token] ``` You have satisfied all required parameters for UAS execution. Everything else is optional. # Optional Attribution Parameters (UTM) UAS links support standard UTM parameters for execution attribution. These parameters allow ONCHAIN and integrators to understand where execution intent originates across wallets, bots, launchpads, explorers, and other distribution surfaces — without introducing custody, tracking scripts, or platform control. UTM parameters are optional, but strongly recommended for integrators distributing UAS links across multiple environments. UTM parameters do not affect execution routing, pricing, access guarantees, or settlement. *** #### Supported UTM Parameters
ParameterDescription
utm_sourceThe specific surface where the link appears
utm_mediumThe class of surface
utm_campaignLogical grouping or distribution phase
utm_content(Optional) Placement or variant identifier
UTM parameters follow standard conventions and are passed through execution unchanged. *** #### Recommended utm\_medium Values To ensure consistency across the UAS ecosystem, integrators are encouraged to select utm\_medium values from the list below.
These values describe the type of surface, not the implementation details.
utm_mediumDefinition
walletEmbedded inside a wallet UI
botAutomated or chat-based agents (Telegram, Discord, Farcaster, etc.)
explorerBlock explorers and discovery tools
launchpadToken launch and distribution platforms
socialSocial feeds and profile links
webGeneral-purpose websites or web applications
apiProgrammatic or server-generated execution
emailEmail-based distribution
qrPhysical or scanned QR placements
Integrators may use custom values if necessary, but doing so may reduce comparability across surfaces. *** #### Example: UAS Link with Attribution ``` https://onchain.money/u/USDC ?utm_source=telegram &utm_medium=bot &utm_campaign=uas_links &utm_content=inline_cta ``` * utm\_source=telegram **identifies the exact surface** * utm\_medium=bot **classifies the execution environment** * utm\_campaign=uas\_links **groups related distribution** * utm\_content=inline\_cta **identifies placement (optional)** If your UAS link already includes query parameters, append UTM parameters using &. *** #### Recommended Naming Conventions To maintain clean attribution data: * Use lowercase * Use underscores instead of spaces * Keep utm\_source specific and utm\_medium generic * Avoid user-identifiable or sensitive data **Good** ``` utm_source=pinksale utm_medium=launchpad ``` **Avoid** ``` utm_source=launchpad_pinksale_v2_ios utm_medium=token_sale_campaign ``` *** #### Why Attribution Matters Because UAS links are permissionless and portable, execution may originate far from the destination application. UTM parameters allow ONCHAIN and integrators to: * Measure execution completion by surface type * Compare execution quality across environments * Understand repeat execution behavior * Improve distribution without restricting access Attribution is informational only and does not influence execution behavior. # Supported Chains This page lists the blockchain networks currently supported by ONCHAIN Gateway for Universal Access Schema (UAS) execution. When constructing UAS links, integrators must use the exact chain slug listed below. Chain availability may change over time as support expands. Integrators should validate support where possible and fail gracefully if a chain is unavailable. *** ### Currently Supported Chains | Chain | Chain Slug | Status | | --------- | ---------- | --------- | | Ethereum | ethereum | Supported | | Polygon | polygon | Supported | | Base | base | Supported | | BNB Chain | bnb | Supported | | Solana | solana | Imminent | Only the chain slugs listed above are valid for UAS execution. *** ### Usage in UAS Links The chain slug is used directly in the UAS path: ``` https://buy.onchain.money/[chain]/[token] ``` Example: ``` https://buy.onchain.money/ethereum/0xabc123... ``` Using an unsupported or incorrect chain slug will prevent execution. *** ### Validation Guidance * Chain slugs must be lowercase * Chain slugs must match the table above exactly * Unsupported chains will not execute * No partial execution occurs on unsupported chains Recommended behavior: * Hide or disable execution surfaces when a chain is unsupported * Fall back to native or alternative flows when appropriate *** ### Source of Truth The list above reflects current ONCHAIN Gateway availability. For the most up-to-date list of supported chains, refer to the official ONCHAIN Help Center documentation on compatible chains. *** ### Key Takeaway When generating UAS links, always use a supported chain slug: ``` https://buy.onchain.money/[chain]/[token] ``` # Examples This page provides copy-paste examples of Universal Access Schema (UAS) links across common integration surfaces. All examples follow the same base format: ``` https://buy.onchain.money/[chain]/[token] ``` Attribution parameters are optional and do not affect execution behavior. *** ### Minimal UAS Link The smallest valid execution link: ``` https://buy.onchain.money/ethereum/0xabc123... ``` Use this format when attribution is not required. *** ### Wallet Integration Example: Wallet “Buy” button ``` https://buy.onchain.money/base/0xabc123... ?utm_source=phantom &utm_medium=wallet ``` Typical usage: * Asset detail views * Buy / acquire buttons * Embedded wallet flows *** ### Bot Integration Example: Telegram or Discord bot ``` https://buy.onchain.money/polygon/0xabc123... ?utm_source=telegram &utm_medium=bot ``` Bots typically generate UAS links dynamically based on user-selected chain and token. *** ### Dynamic Link Table (Common Use Cases) This table outlines how different products typically generate and use the Universal Access Schema (UAS). In all cases, the same base format applies: ``` https://buy.onchain.money/[chain]/[token] ```
Use CaseImplementation Detail
Telegram botBot outputs a URL based on user-selected chain and token contract
Wallet “Buy” buttonWallet reads the active chain and asset address to build the link
Token websiteHard-coded CTA button linking directly to the token
CEX off-boarding flowReplace bridge / DEX steps with a direct UAS link
Portfolio trackerGenerate a UAS link for each asset displayed
Community dashboardEmbed per-token links inside cards or tables
MarketplaceAdd a “Buy Token” action to collections or listings
All implementations rely on the same deterministic link structure and require no backend, authentication, or API keys. *** ### Launchpad Integration Example: Token launch or sale page ``` https://buy.onchain.money/ethereum/0xabc123... ?utm_source=pinksale &utm_medium=launchpad &utm_campaign=token_launch ``` Launchpads should use utm\_medium=launchpad. *** ### Explorer Integration Example: Explorer asset page ``` https://buy.onchain.money/bnbchain/0xabc123... ?utm_source=explorer &utm_medium=explorer ``` Explorers typically surface UAS links alongside token metadata. *** ### Web Application Example: Static or dynamic web app ``` https://buy.onchain.money/polygon/0xabc123... ?utm_source=webapp &utm_medium=web ``` Links may be generated client-side or server-side. *** ### API / Backend Generation Example: Server-generated link ``` function buildUASLink(chain, token) { return `https://buy.onchain.money/${chain}/${token.toLowerCase()}`; } ``` Example usage: ``` buildUASLink("ethereum", "0xabc123..."); buildUASLink("bnbchain", "0xdef456..."); ``` *** ### Email Distribution Example: Newsletter or email CTA ``` https://buy.onchain.money/ethereum/0xabc123... ?utm_source=newsletter &utm_medium=email ``` *** ### QR Code Distribution Example: QR-based execution ``` https://buy.onchain.money/base/0xabc123... ?utm_source=event &utm_medium=qr ``` *** ### Fully Attributed Example ``` https://buy.onchain.money/ethereum/0xabc123... ?utm_source=telegram &utm_medium=bot &utm_campaign=uas_links &utm_content=inline_cta ``` This format is recommended when measuring distribution performance across surfaces. *** ### Key Notes * Chain slugs must match the Supported Chains page exactly * Token addresses must be lowercase * Do not URL-encode token addresses * Attribution parameters are optional and informational only * Unsupported chains or tokens fail gracefully *** ### Summary If you can generate: ``` https://buy.onchain.money/[chain]/[token] ``` Using a supported chain slug, you have a valid UAS execution link. Everything else is optional. # Behind the Scenes When a user clicks a Universal Access Schema link, the following sequence happens automatically: #### 1. Gateway loads context * Detects the chain slug * Loads the token contract * Confirms the asset is cleared by Smart Guardrails * Prepares available payment options (fiat or crypto) #### 2. User completes payment The user pays using: * Cards * Apple Pay / Google Pay * Local payment methods * Native crypto (where supported) #### 3. Gateway verifies payment Payment confirmation triggers a **BuyIntent** that is sent to OPN. #### 4. OPN executes deterministically OPN handles all on-chain settlement: * Sources liquidity from the asset’s home chain * Performs native DEX execution * Avoids bridges, wrappers, and intermediaries * Enforces deterministic settlement rules #### 5. Final settlement to the user’s wallet OPN sends the purchased token directly to the user’s wallet: * No custody * No pooled funds * No manual approvals * No extra transactions #### Summary The entire backend collapse into one principle: **The URL encodes the intent.**\ **Gateway interprets it.**\ **OPN fulfills it.** This is why the Universal Access Schema works across wallets, bots, sites, and everywhere a link can exist. # Smart Guardrails Smart Guardrails ensure that only safe, liquid, and executable assets can be reached through the Universal Access Schema.\ They act as an automated clearing layer — verifying each token before OPN accepts a BuyIntent. Smart Guardrails run four independent checks: *** ### 4.1 Liquidity Verification Ensures the asset has sufficient on-chain liquidity for deterministic execution. **Checks include:** * Minimum liquidity thresholds on local DEXs * Reliable routing paths (no fragmented liquidity) * Slippage safety under expected volumes **Why it matters:**\ Tokens with thin liquidity can cause failed trades, high slippage, or delivery mismatches. *** ### 4.2 Contract Integrity Review Analyzes the token’s smart contract for security and behavioral risks. **Checks include:** * Mint / burn authority * Proxy or upgrade logic * Fee-on-transfer behavior * Pausable or blacklist controls * Known exploit patterns **Why it matters:**\ Users should never buy a token whose code allows unexpected minting, freezing, or execution traps. *** ### 4.3 Admin Key Analysis Examines whether a token can be manipulated post-launch. **Checks include:** * Ownership status (EOA, multisig, timelock) * Ability to change fees, supply, or trading rules * Privileged functions that override market reality **Why it matters:**\ Admin keys can compromise user safety if not properly structured or time-locked. *** ### 4.4 Settlement Compatibility (OPN Compatibility) Ensures the token can be executed natively and non-custodially. **Checks include:** * Exists on a supported chain with native liquidity * No bridging, wrapping, or derivative representations * Deterministic settlement possible via local USDC liquidity **Why it matters:**\ Gateway and OPN only execute **native, verifiable** settlement paths — no wrappers, no synthetic assets. *** ### 4.5 Outcome of Smart Guardrail Checks Each token receives one of three results: | Status | Meaning | | -------------- | ----------------------------------------------------------------------- | | **Cleared** | Token is eligible. Schema links work globally. | | **Restricted** | Token partially passes checks; schema may work in limited contexts. | | **Rejected** | Token fails core safety requirements and is not executable via Gateway. | *** ### 4.6 Why Smart Guardrails Exist Smart Guardrails prevent: * Unsafe assets from being purchased * Illiquid assets from causing failed settlement * Wrapped/bridged assets from creating fragmentation * Users from encountering opaque or malicious token behavior They are the foundation of **trust, determinism, and safety** for the Universal Access Schema. *** ### 4.7 Summary Smart Guardrails ensure that: * Users only interact with safe, verifiable assets * Chains remain sovereign (local liquidity, no bridges) * Execution remains deterministic * Every schema link points to a trustworthy path They function as the **on-chain clearing layer** of the ONCHAIN® Protocol Network. # The ONCHAIN® Protocol Network (OPN) OPN (pronounced “open”) is the deterministic execution layer beneath *ONCHAIN®* — fulfilling BuyIntents natively on each chain. ### Core Components #### **1. BuyIntent** A canonical, tamper-proof representation of a user’s request: * Token * Chain * Amount * Wallet * Timestamp #### **2. IntentRegistry** An on-chain anchor guaranteeing: * Transparency * Non-repudiation * Replay protection #### **3. Deterministic Execution** OPN uses: * Prefunded USDC Solver Treasuries * Local DEX routing * Guaranteed settlement * Predictable execution behavior #### **4. Local, Native Settlement** Tokens settle on their home chain.\ No bridging.\ No wrapping.\ No synthetic IOUs. #### **5. Solver Treasuries** Execution liquidity: * Non-custodial * USDC-denominated * Fully withdrawable * Rebalanced automatically *** ### Execution Flow 1. Gateway verifies payment 2. Gateway broadcasts BuyIntent 3. OPN swaps USDC → token 4. Token settles to the user wallet 5. Treasury rebalances as needed *** OPN turns a link into confirmed ownership — deterministically and globally. # Gateway: Verification & Intent Layer *ONCHAIN®* Gateway orchestrates the top of the funnel — verifying payments, validating assets, enforcing compliance, and broadcasting BuyIntents to OPN. ### Responsibilities #### **1. Context Loading** * Detect chain * Detect token * Hydrate metadata via Smart Guardrails #### **2. Payment Handling** Supported payment rails: * Cards * Apple Pay * Google Pay * Local methods (depending on region) * Native crypto #### **3. Compliance + Safety** * KYC/AML where needed * Travel Rule compliance * Fraud detection * Sanctions screening #### **4. Intent Broadcasting** Gateway converts a successful payment into a **BuyIntent** and commits it to the IntentRegistry. #### **5. Session Security** Protection against: * Replay * Injection * Manipulation * Tampering Gateway makes access safe at the moment of discovery. # ONCHAIN.MONEY Marketplace The **onchain.money** interface is the universal purchaser for UAS links — the “browser” for schema addresses. ### What It Does * Loads token context * Shows a clear summary of the asset * Provides an all-in final price * Handles payment selection * Settles tokens to the user’s wallet * Abstracts gas and multi-step flows ### Why It Exists The schema needs a **resolver** — a neutral interface that guarantees: * Safety * Predictable UX * Deterministic execution * Instant settlement Everything interoperates: any link → one interface → full on-chain ownership. # Supported Chains | Chain | Slug | Status | | ----------------------- | -------- | --------- | | Ethereum | ethereum | Supported | | Base | base | Supported | | BNB Chain | bnbchain | Supported | | Polygon | polygon | Supported | | Solana | solana | Imminent | | Additional EVM networks | varies | Planned | To request your chain’s integration → **** # Chain Integration Program Networks can join *ONCHAIN®* and enable instant access for every asset on their chain. ### Requirements (EVM Only) You must support: * Native USDC * CCTP v2 (or canonical settlement primitive) * Stable DEX liquidity * Reliable RPC infrastructure ### Integration Checklist * Chain metadata submitted * Canonical USDC verified * DEX routing validated * Smart Guardrails activated * Test executions performed * Schema published ### Optional: Chain-Funded Liquidity Chains may contribute **execution liquidity** (USDC) to ensure: * Global reach for every asset in the ecosystem * Local, native execution * Guaranteed settlement **This liquidity is:** * Non-custodial * Fully withdrawable * Not staked or revenue-shared * Treated as working capital * Used only for verified executions #### Cool-Off Rule If a chain withdraws *all* liquidity: * A 5–14 day cool-off begins * Status becomes **sunsetting** * Builders receive transparent notice * After cooldown, chain may be delisted This prevents broken links and maintains deterministic routing. ### Contact 📩 # Compliance & Security *ONCHAIN®* operates with full regulatory, technical, and operational safeguards. ### Compliance * Registered VASP (jurisdiction-specific) * KYC/AML where applicable * Travel Rule exchange * Fraud and sanctions screening ### Security * All core smart contracts audited (Hacken) * Deterministic execution paths * Non-custodial settlement * Intent-level transparency * Encrypted payment sessions ### Data Handling * Minimal data retention * No unnecessary tracking * No custody of user private keys *ONCHAIN®* is designed from the ground up to be safe, transparent, and predictable. # Contact * General Support → **** * Chains & L1/L2 Teams → **** * Liquidity Providers → **** * Integrations & Builders → **** We respond within 24–48 hours.