Your device already signs offline, but the broadcast still leans on an online phone or computer. TELRPC carries that signed transaction over an ordinary phone call and brings the confirmation back the same way, while your signer stays exactly as it is.
Four models on one rail. Each carries the same signed bytes to the same grid. Choose one per product line, or combine them.
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.
Your companion app gains the offline broadcast-and-state path, built on the TRP/1 protocol and its reference implementation: carry a transaction your device already signed, read state by QR or echo, show the confirmation. Your UX, our rail, source under licence. The fastest route to market.
Self-serve
The device itself carries the transaction it signed, with no network interface at all. Two ways to build it:
The device keys the tones itself, into any phone held to it or through a headset jack. The phone is only a handset on a call; it never sees a key.
A voice module and a SIM or eSIM inside the device. It places the call itself, with no phone at all.
A whitelabel companion app, fully yours, owned by you, run on the grid, with the same no-internet manifest anyone can verify. The TELRPC Wallet shows what your users get, in production: every major chain, 36 EVM networks and 144 verified tokens.
Self-serve
You build everything above the wire. We run the voice grid, the decoders, the broadcasters and the echo. A keyed interface for dial plans, receipts, grid status and your client book. Metered, tiered, and yours to shape.
Self-serveYour hardware wallet signs exactly as it does today. What changes is how the signed bytes reach a phone call. There are three ways to do it, plus a fourth way through the SIM itself, and each 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 SIM route exists because a SIM is already a secure element in every handset, and Minutes Network is a carrier business. Each shape, with what signs, what places the call and what we supply, is set out on the integrations page.
The seven shapes in detailTELRPC need not be the signer. Keep the key exactly where it lives today: your secure element, your MPC quorum, your device. Hand the rail the already-signed transaction and it travels the call to the chain. A transaction is valid by its bytes, not its channel, so nothing about your signing changes. The grid holds no key that can move your funds: it can carry or refuse a transaction, never alter it or redirect it. Its only keys are operational: a Solana co-signer limited to one fixed setup template, and a small fee-payer for setup slots. A compromised line can delay a payment, and cannot redirect one.
Your hardware signs as it always has. The signed bytes leave by a phone call instead of an internet connection, from your companion app, a whitelabel build, or the device itself.
The quorum produces one signature; the rail carries the finished transaction. No share, no key and no policy of yours ever passes through the grid.
Anything that produces a signed transaction can hand it over: by QR into a TELRPC companion, through the reference implementation under licence, or keyed directly from your own build.
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, from your app, a hardware wallet, or an MPC setup, frame it in TRP/1 with its checksum, and key it as tones on an ordinary call to the grid's numbers. The grid broadcasts it and your keyed console API reports it. The transaction ID never needs fetching, because it was computed at signing; the confirmation echo is checked against it. 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.
The developer page# 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 } ] }A licensed product with a running network under it, not a design to rebuild.
Wholesale per-broadcast pricing by volume tier, an annual platform licence, and coverage tiers that decide which markets are a local call for your users. Partners settle by monthly invoice.
Your users pay 10 cents of prepaid broadcast credit for each call request: a broadcast, a sync or balance read by call, a swap price check, a swap, a token approval or a contract read, charged only when it succeeds. Sends are never charged a percentage. Every fee is shown on the review before a swap. The call itself is ordinary airtime at the carrier's normal rate.
Every send pays its own network fee from its own account, on its own chain, exactly as it does today.
Whitelabel builds carry a one-time engineering fee. Certification under the TELRPC INSIDE mark comes with every model.
TELRPC deploys no contract on any chain. There is nothing of ours for your users to approve, and nothing of ours on-chain to audit.
Your signer already produces one; nothing about how it signs changes.
A companion phone, your own hardware, or a whitelabel build. The TRP/1 frame logic from the reference implementation frames the transaction, keys the tones, and handles the checksum and the automatic resend.
The camera reads a QR, or on Android 10 and later the echo arrives through the call-screening role, which grants no network access and reads only an incoming caller ID.
for the dial plan, metering and receipts. No key material of your users ever touches it.
No internet permission anywhere in that list.
The key never meets a networked machine. The broadcast and the state a send needs travel the voice network instead. In a build with no internet permission, the absence is verifiable in one command, as it is on the TELRPC Wallet today: no internet, and four permissions, CALL_PHONE, ANSWER_PHONE_CALLS, CAMERA and USE_BIOMETRIC, none of which can open a network connection.
Anywhere a call can be placed: no mobile data, 2G, a roaming handset, a blackout, a network that is blocked or watched. Native and token sends and contract calls across the EVM family, Bitcoin, Solana and more, and swaps on Ethereum, Base, Arbitrum, Optimism, Polygon, BNB, Avalanche, Linea and Blast. A swap is signed against a price read by call, with a minimum output and a deadline, so a stale or bad price reverts, never overpays. In Swap, any token on Uniswap's default and extended lists (2,841) can be used, plus custom tokens marked Not verified; Swap is not offered for hardware wallets.
The grid calls back in silence and the wallet checks the reply against the transaction id it computed itself, so nobody has to ask whether it went through. How the echo works
A lost tone or a dropped call broadcasts nothing; the wallet redials the same signed transaction, so it lands only once. How it recovers
A real payment on 11 October 2026, exactly as the phone showed it. One USDC on Base, sent from a phone with no internet permission, under three minutes from opening the send screen to the confirmation on the device.
Asset, payee and amount. The account's sequence and fee are already on the phone, synced offline.
Amount, recipient, network and fee. Placing the call signs it on the device; the key never leaves it.
The signed transaction travels as tones, about 95 seconds for a USDC transfer. The grid checks the checksum and broadcasts the exact bytes.
The grid calls back with a reference to the transaction id in the caller ID. The wallet matches it to the id it computed itself.
On-chain at 09:18:25 UTC, 11 October 2026, block 52460479: 0x54cc6d…78b1a7 on BaseScan. Phone clock shows local time (UTC+2).
Under NDA, your security team gets the whitepaper, the threat model, the TRP/1 specification and the reference source. We answer everything, then agree the model, the shape and the markets.
Request the documents under NDAOne market, live grid, your build or ours. Your team dials the line, sends to an address it names on the spot, and watches value land with no internet in the room.
The TELRPC INSIDE mark, wholesale terms in writing, and a rollout that follows your calendar, with our engineers on the line.
The specification, the whitepaper and the reference source reach partners under licence and NDA, as part of an integration. What sits beneath them is not a document: the grid runs on carrier infrastructure Minutes Network operates: carrier interconnects, local numbers in 93 countries on request, 15 live today, and a US line callable from anywhere, run by a team whose day job is running voice traffic at carrier scale. Integration support is part of the deal, across all seven deployment shapes. The next step is one message: tell us your device and your model, and we send the brief, the integration guide and a live test line.