A signed transaction is valid by its bytes, not by the channel that carries it, so any product that can place a call can broadcast with no internet in the path. License the TRP/1 protocol and the reference implementation for your app or your own device, or use a keyed API on the grid.
One rail, three ways to look at it: the four models say how deep TELRPC goes into your product, the seven shapes say where the key and the call sit, and the three ways in say what a developer licenses or calls.
The TRP/1 protocol and its reference implementation, the TELRPC Android app, licensed to partners with source under licence. It frames a signed transaction with a checksum, keys it as tones on an ordinary call, places a refused frame again, reads state by QR or echo, and checks the confirmation echo. It signs on the device or carries a transaction your own signer made. The same frame logic ports to firmware and servers under licence. Your interface, our rail.
For hardware you build yourself, the TRP/1 specification, the whitepaper and the reference source are shared with licensed partners under NDA, as part of an integration, with our engineers alongside yours. Every frame carries a checksum, so a damaged frame is refused, never broadcast.
A keyed JSON API over the grid: ask for the dial plan, register the addresses you serve, read back broadcast receipts, check grid status, and manage your end-clients and their usage. You build everything above it. Metered and tiered.
Frame the signed bytes. Key them on a call. Read the echo.
TELRPC need not be the signer: bring a transaction your own signer already made, frame it in TRP/1 with its checksum, and key it as tones on an ordinary call to the grid's numbers. The grid checks the frame, broadcasts, and calls back with a short confirmation echo in the caller ID. The transaction ID never needs fetching, because it was computed at signing. Chains that need live state to build a transaction read it by echo or from a QR with the camera, still with no socket open. For your own systems, the keyed console API reports what the grid has done.
# illustrative: read back the broadcasts on your account# your partner key is issued in the TELRPC Console and shown oncecurl https://HOST/console/api/v1/broadcasts \ -H "Authorization: Bearer $TELRPC_KEY"# returns { account, broadcasts: [ { ts, chain, txid, status, fee_micro } ] }# illustrative: attribute an address you serve to your accountcurl https://HOST/console/api/v1/wallets/register \ -H "Authorization: Bearer $TELRPC_KEY" \ -d address=0xYourClientAddress -d label=desk-1# returns { registered: { address, label, balance_code }, account }The call is the broadcast. The tones are the transaction. This is a real TELRPC frame; sound plays only when you press.
*103175824609317#
The grid answers by calling back with a short value in the caller ID, which the device reads and declines in silence (how the echo works). For an integration, four frames cover the whole send lifecycle.
SYNCThe account's current sequence (nonce) and fee level, after a short call from the device. The next transaction can be built and signed offline at once. One of four ways to sync, alongside a QR, a spoken readback, and typing by hand.
BALANCEThe account's balance, delivered the same way, with no screen and no data connection involved.
CONFIRMAfter a broadcast, a reference to the transaction id. The device checks it against the id it computed at signing; only a match moves its sequence forward. Completion is a signal, not a question.
RESENDThe frame failed its checksum, so nothing was broadcast; the device redials the same signed transaction, which can land only once (self-healing calls).
The rail does not care who signed. A hardware wallet, an MPC quorum, an HSM or your own code produces the signed transaction; TELRPC carries those bytes over the call and returns the state and confirmation a send needs. The grid holds no key that can move your funds: it can carry or refuse a transaction, and a changed byte fails the signature. Its only keys are operational: a Solana co-signer limited to one fixed setup template, and a small fee-payer for setup slots. TELRPC deploys no contract on any chain, and every send pays its own network fee.
Native and token sends, token swaps and smart-contract calls, signed offline and broadcast over the call. Swaps run through Uniswap on Ethereum, Base, Arbitrum, Optimism, Polygon, BNB, Avalanche, Linea and Blast, priced by call (10 cents), with a minimum output and a deadline. Sends are never charged a percentage. Every fee is shown on the review before a swap.
The 36 EVM networks (Ethereum, Base, Arbitrum One, Optimism, Polygon, BNB Smart Chain, Avalanche, World Mobile Chain and 28 more), Bitcoin, Solana, Litecoin, Dogecoin, XRP, Tron with USDT, Cardano, Stellar, Cosmos, TON, NEAR, Tezos, Bitcoin Cash and Nano. Any ledger whose transactions are signed, with no change at the device.
Real USDC payments on Base from a phone with no internet access, each over an ordinary call and public on the explorer. About 95 seconds of tones per USDC transfer. See one payment, start to finish
When you run your own build and want the grid underneath it, every call is a plain JSON request authorised by your partner key, a key issued in the TELRPC Console and shown once. No key material of your users ever appears here, and the grid holds no key that can move user funds.
Dial planThe call-in numbers the grid publishes, grouped by country, with the rule for picking one per call.
Wallet registrationRegister an address you serve, so its broadcasts are attributed to your account for metering and receipts.
BroadcastsRead back the broadcasts on your account, each with its chain, transaction id and on-chain status, for receipts and reconciliation.
Grid statusA health read of the grid and its broadcast path, for your own monitoring.
ClientsYour end-clients, provisioned programmatically with your partner key, so onboarding runs from your own systems.
Client addressesThe wallet addresses under each end-client, so every broadcast lands on the right client.
UsageUsage per end-client, for your own billing and resale.
The device that places the call can be a phone, the hardware wallet itself, a module, a SIM or a server. Each target is marked with how it is delivered: Self-serve, which you deploy yourself, or Built with our team, which our engineers deliver with you. All of them are ready today.
The reference implementation in your app under licence, or the TELRPC Wallet in your brand. It places the call, reads state by QR or echo, and carries transactions signed on the phone or handed over by an external signer. This is the TELRPC Wallet in production today.
Self-serveThe frame logic inside the device: it keys its own tones through its own audio path, into any phone held to it or a headset jack. The key and the signed bytes never meet a networked machine.
Built with our teamA voice module and a SIM or eSIM inside the device or an appliance, running our firmware. It places the call itself, with no phone at all.
Built with our teamStandard SIM toolkit commands let a SIM place a call and send tones. An applet issued with a mobile-operator partner carries the frame from any handset, even a basic phone.
Built with our teamFor desks that already run telephony: a dedicated private trunk on Minutes Network's carrier network into the grid, with dedicated numbers, so the call never crosses the public internet.
Built with our teamWhich device holds the key, which device places the call, and how the signed bytes travel between them, for wallet makers, exchanges, custodians and treasuries.
See the integrationsThe integration guide is open to read. The SDK reference, the TRP/1 specification and the whitepaper reach licensed partners under NDA.
The TRP/1 specification and the reference source reach licensed partners under NDA, with our engineers on the line. Beneath them run the grid, the carrier backbone, the interconnects and local numbers in 93 countries on request (15 live today), plus a US line callable from anywhere. Integration support is part of the deal, across every device target and all seven deployment shapes.