> For the complete documentation index, see [llms.txt](https://timechain.gitbook.io/neucron/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://timechain.gitbook.io/neucron/core-concepts/blockchains-as-rails.md).

# Blockchains as Rails

## One API, many rails

Fintech infrastructure has always been built on rails. Cards run on card-network rails, bank transfers run on ACH, SEPA, or UPI rails, and each rail has its own cost, speed, finality, and compliance profile. You never ask a customer which acquiring bank you use; you just accept their payment.

Neucron applies the same mental model to blockchains. **Each blockchain is a rail for moving value.** Ethereum, Polygon, Tron, Base, and every other supported network is simply a rail with its own fees, confirmation times, asset standards, and regulatory posture. Your wallet, your invoices, and your payouts do not change when the rail changes.

```mermaid
flowchart LR
    subgraph You["Your product (whitelabelled)"]
        UI[Wallets / Invoices / Payouts]
    end
    UI --> N[Neucron API]
    N --> R1[Ethereum rail]
    N --> R2[Polygon rail]
    N --> R3[Tron rail]
    N --> R4[Base rail]
    N --> R5[More rails...]
```

## What this means in practice

* **Wallets are multi-rail by default.** A single Neucron wallet holds addresses on every supported rail. Your user has one balance view; Neucron handles address derivation, nonce management, and confirmation tracking per rail.
* **Invoices declare acceptable rails.** When a business creates a payment link, it chooses exactly which assets on which rails it is willing to accept for clearing. The payer picks any accepted combination.
* **Payouts pick the cheapest suitable rail.** Treasury teams choose the rail per payout based on fees, speed, and counterparty preference, without changing integration code.
* **Assets are rail-specific.** USDC on Ethereum and USDC on Tron are the same asset class on different rails. Neucron tracks them distinctly so accounting and reconciliation stay exact.

## Choosing rails for your product

The criteria are the same ones you would use for any payment rail:

| Criterion          | Question to ask                                                              |
| ------------------ | ---------------------------------------------------------------------------- |
| Cost               | What does a typical transfer cost on this rail?                              |
| Speed & finality   | How quickly is a payment irrevocable?                                        |
| Asset availability | Are the stablecoins and tokens you need issued on this rail?                 |
| Compliance         | Does the rail fit your regulatory posture and your customers' jurisdictions? |
| Reach              | Do your customers and vendors already hold assets on this rail?              |

See [Supported Networks](https://timechain.gitbook.io/neucron/networks-and-assets/supported-networks) for the live rail matrix and the roadmap.

{% hint style="info" %}
**Design principle:** Neucron never locks you into a rail. The same wallet, invoice, and payout APIs work across every supported network, and new rails are added without breaking changes to your integration.
{% endhint %}