> ## Documentation Index > Fetch the complete documentation index at: https://docs.polygon.technology/llms.txt > Use this file to discover all available pages before exploring further. # List supported networks > Lists every network BPN supports, with its identifiers, available assets, and which OMS resources can use it in which direction. Availability is derived from live route configuration, so a network absent from this list is not routable. Fiat-rail availability reflects the calling project's own configuration; crypto networks are global. "Network" here means any rail, not only a blockchain: `category` (`crypto` | `fiatAccount` | `cash`) and `type` (`blockchain` | `bankRail` | `card` | `physical`) are what distinguish them, and `chainId` / `networkFamily` are absent on everything that is not a blockchain. Declared here, beside the other Reference operations, to match the ratified OMS v0.12 contract — which tags `/networks`, `/assets` and `/reference/account-type-requirements` alike. The handler lives in `services/platform`; tag and Go package are independent, exactly as `getAccountTypeRequirements` above is served from `services/externalaccount`. ## OpenAPI ````yaml /api-reference/openapi.yaml get /networks openapi: 3.0.3 info: title: Polygon OMS Public API version: v26.05.28-0001 description: >- Unified API for moving money between crypto and fiat. Three ways to move money: Transactions (instant, wallet or card funded, including Cash-In for in-person cash deposits), Deposit Addresses (reusable crypto deposit configurations), and Virtual Accounts (dedicated bank accounts that auto-convert fiat to crypto). Standard transactions follow a two-step flow: create a Quote (pricing), then create a Transaction (execution). Cash-in codes generate a one-time deposit code for in-person cash deposits at retail locations. contact: name: Polygon OMS url: https://oms.polygon.technology servers: - url: https://sandbox-api.polygon.technology/v0.11 description: Sandbox - url: https://api.polygon.technology/v0.11 description: Production security: - BearerAuth: [] tags: - name: Auth description: Authentication via FrontEgg - name: Customers description: Customer management and KYC - name: Customer - name: Wallet - name: Quote - name: Transaction - name: CashIns - name: CashLocation - name: Sandbox - name: VirtualAccount - name: Counterparty - name: ExternalAccount - name: Reference - name: DepositAddress paths: /networks: get: tags: - Reference summary: List supported networks description: >- Lists every network BPN supports, with its identifiers, available assets, and which OMS resources can use it in which direction. Availability is derived from live route configuration, so a network absent from this list is not routable. Fiat-rail availability reflects the calling project's own configuration; crypto networks are global. "Network" here means any rail, not only a blockchain: `category` (`crypto` | `fiatAccount` | `cash`) and `type` (`blockchain` | `bankRail` | `card` | `physical`) are what distinguish them, and `chainId` / `networkFamily` are absent on everything that is not a blockchain. Declared here, beside the other Reference operations, to match the ratified OMS v0.12 contract — which tags `/networks`, `/assets` and `/reference/account-type-requirements` alike. The handler lives in `services/platform`; tag and Go package are independent, exactly as `getAccountTypeRequirements` above is served from `services/externalaccount`. operationId: listNetworks parameters: [] responses: '200': description: The request has succeeded. content: application/json: schema: $ref: '#/components/schemas/NetworkListResponse' components: schemas: NetworkListResponse: type: object required: - data properties: object: type: string enum: - list data: type: array items: $ref: '#/components/schemas/SupportedNetwork' SupportedNetwork: type: object required: - network - category - type - displayName - assets - supportedBy properties: network: type: string description: >- Partner-facing network token — the value to send in a request `network` field. Internal route-config codes are mapped here at the boundary (`international_wire` is emitted as `swift`), so this is never a snake_case internal token. `achSameDay` and `local` are also contract-legal request values with no distinct entry here: routes are validated against the coarser `ach` / `swift` rail respectively, so `achSameDay` availability is reported under `ach` and `local` under `swift` rather than as their own network. category: $ref: '#/components/schemas/NetworkCategory' type: $ref: '#/components/schemas/NetworkKind' chainId: type: integer format: int64 nullable: true description: >- EVM chain id. OMITTED (key absent, not explicit `null`) for a non-EVM network — see `contractAddress` for why absent and null are equivalent here. BPN stores `chain_id` as non-empty text for every row including Solana, whose value is a base58 genesis hash — anything that does not parse as an integer omits the key. Declared `int64`, not `safeint`, despite `safeint` — "an integer exactly representable in JS" — being the semantically correct scalar for a value this small (every real chain id fits well under 2^53; Aurora's 1313161554 is the largest in practice, and `int32` is already too small for it). Tried as the fix for comment 3732256949 (the generated Zod schema coerces to `bigint` while the generated TS type is `number`, so parsing a response can silently hand a caller a `bigint` where the exported type promised `number`) and reverted: the `@typespec/openapi3` emitter's default `safeint` strategy still emits `format: int64` in the OpenAPI schema — identical to plain `int64` — and hey-api's Zod generator decides bigint-coercion purely from that `format` string (`shouldCoerceToBigInt`), so the scalar swap changes nothing generated. Fixing this for real needs the emitter's `safeint-strategy: double-int` option, which is a schema-wide (not per-field) setting untested against every other `int64`/`safeint` use in this spec — out of scope for a one-field fix. Tracked as a known generator quirk rather than half-fixed here. networkFamily: allOf: - $ref: '#/components/schemas/NetworkFamily' nullable: true description: >- OMITTED (key absent, not explicit `null`) for non-blockchain networks — see `contractAddress` for why absent and null are equivalent here. displayName: type: string description: Human-readable label, e.g. "Polygon PoS". assets: type: array items: $ref: '#/components/schemas/NetworkAsset' supportedBy: $ref: '#/components/schemas/SupportedBy' description: >- A network BPN supports, with its identifiers, assets, and capability map. NetworkCategory: type: string enum: - crypto - fiatAccount - cash description: Which broad class of network this is. NetworkKind: type: string enum: - blockchain - bankRail - card - physical description: >- The transport a network uses. Named `NetworkKind` rather than `NetworkType` because `NetworkType` is already taken by the internal admin vocabulary (`chain | fiat_rail`) in admin.tsp — a different set with a different audience. NetworkFamily: type: string enum: - evm - solana description: >- Crypto network family for a registered external wallet. A walletExternal is registered per family (an EVM address is valid across every EVM chain); the service provisions one Erebor CounterpartyBlockchainAddress per served network in the family. NetworkAsset: type: object required: - asset properties: asset: type: string description: Lowercase canonical asset code, e.g. `usdc`. contractAddress: type: string nullable: true description: >- Token contract address. OMITTED — the JSON key is absent, not sent as an explicit `null` — for a native asset (BPN stores `token_id = 'native'` for those) and for any asset with no on-chain identity row. `?: T | null` in TypeSpec compiles (oapi-codegen) to a Go `*string` tagged `omitempty`, so a nil pointer drops the key rather than emitting `null`; "key absent" and "explicit null" are treated as equivalent here on purpose, not by oversight — every consumer already does (the generated Zod schema accepts both via `.nullish()`), so there is no case that needs telling the two apart. decimals: type: integer format: int32 nullable: true description: >- Count of decimal places in the on-chain smallest unit. OMITTED (key absent, not explicit `null`) — see `contractAddress` for why absent and null are equivalent here — when BPN has no on-chain identity row for this (asset, network): the scale is then genuinely unknown, not zero. A partner must not assume a default scale and must not format an amount in this asset while `decimals` is absent — the same "absent means unproven, not false" convention `supportedBy.wallet` uses for a capability instead of a scale. description: One asset available on a network. SupportedBy: type: object properties: externalAccount: type: object properties: asSource: type: array items: type: string asDestination: type: array items: type: string required: - asSource - asDestination description: |- External-account types usable on this network, per direction — e.g. `["walletExternal"]` on a chain, `["bankUs"]` on `ach`. depositAddress: $ref: '#/components/schemas/DirectionalFlag' virtualAccount: $ref: '#/components/schemas/DirectionalFlag' cashIn: $ref: '#/components/schemas/DirectionalFlag' wallet: allOf: - $ref: '#/components/schemas/DirectionalFlag' description: >- Whether an OMS-custodied wallet can hold value on this network and use it as a source or destination. ABSENT means unproven, not false. OMS wallet custody is an enforced two-vendor allow-list (`services/depositaddress/helpers.go` — `WalletRecord.VendorID` must be the multi-asset Erebor-embedded wallet, and a Coinme-custodial wallet fails closed). Erebor's served networks are therefore provable and are populated here. Coinme has no equivalent capability authority — `canonicalChains` is a name-normalisation set, not a support list, and it contains `bitcoin` — so `polygon`, the one Coinme-only network, omits this property until #2763 establishes Coinme's matrix. That will be a data change, not a contract change. description: >- Which OMS resources can use this network, and in which direction. Every property is optional, and absence is meaningful: it means BPN has not established the answer, NOT that the answer is no. A client must not treat a missing property as `false`. `wallet` is the field this applies to in practice — see its own docstring. Two spec fields are deliberately absent from the whole response rather than null, because their values are not BPN's to invent: `assets[].gasSponsorshipSupported` (today's `sponsor_gas` columns are per-request defaults, not a statement of what BPN can absorb) and `assets[].limits` (BPN's existing `transfer_limits` subsystem is rail-scoped USD, a different key and denomination — two overlapping limit surfaces would invite "which one wins" bugs). Both are additive later. See #2754. DirectionalFlag: type: object required: - asSource - asDestination properties: asSource: type: boolean asDestination: type: boolean description: >- Whether a resource can use a network as a transaction source, a destination, or both. Both flags are always present; `false` means checked-and-no. securitySchemes: BearerAuth: type: http scheme: bearer bearerFormat: JWT description: Token from POST /auth/token ````