Assume the line is hostile.
The carrier, the grid and everyone in between can be fully hostile, and the worst they can do is delay a send. There is no network path to the key, and a changed byte fails the signature. Every property on this page is verifiable on the published build.
The security model, in under a minute.
One real payment, start to finish: the permission list of the shipped app, the key made on the phone, the call, the echo, and the result on Base.
No internet permission, so no remote attack surface.
The TELRPC Wallet holds no internet permission, and four others. One command reads it back from the compiled binary: aapt dump permissions shows CALL_PHONE, ANSWER_PHONE_CALLS, CAMERA and USE_BIOMETRIC, and no INTERNET. The operating system therefore denies the process a network socket for the entire life of the install.
$ aapt dump permissions telrpc-wallet.apk package: network.minutes.hardline uses-permission: name='android.permission.CALL_PHONE' uses-permission: name='android.permission.ANSWER_PHONE_CALLS' uses-permission: name='android.permission.CAMERA' uses-permission: name='android.permission.USE_BIOMETRIC' $ aapt dump permissions telrpc-wallet.apk | grep -c INTERNET 0
CALL_PHONEPlaces the call that broadcasts a signed transaction.ANSWER_PHONE_CALLSEnds TELRPC's own call if the network forgets to hang up.CAMERAReads a QR code shown on another screen.USE_BIOMETRICLets the phone's own fingerprint or face check unlock the app.INTERNETNot declared. No network socket, ever.
CALL_PHONE places the call that broadcasts a signed transaction; ANSWER_PHONE_CALLS ends TELRPC's own call if the network forgets to hang up; CAMERA reads a QR code shown on another screen; USE_BIOMETRIC lets the phone's own fingerprint or face check unlock the app. None of the four can move a byte to the internet. The echo, the grid's reply carried in the caller ID of a call the wallet declines in silence, adds Android's call-screening role, which reads an incoming caller ID and grants no network access. From version 0.9.39 the owner can also make the wallet the phone's default phone app, an optional Android role that lets it key its own calls and show the phone's calls on its own call screen; it adds no permission and grants no network access either. No remote or network attack has a way in, because there is no network path from the app to the key. What still reaches the wallet is local: a QR code the camera reads, the caller ID of an echo, and the phone itself, with its operating system and radios. A QR code or an echo carries only public chain data, and the wallet acts on an echo only when it matches the transaction it computed itself; neither can sign or send. A purpose-built TELRPC device with no radio proves the same isolation another way: it has no network interface at all. For the strongest setup, run the wallet on a dedicated phone that never goes online. See the command and its output
Keys are born on the device from your own entropy, never leave it, and there is no server copy, no account, and no recovery desk. Minutes Network has no custody and no way to acquire it. The grid that carries your call holds none of your keys and no key that can move your funds (its only keys are an operational Solana co-signer limited to one fixed setup template, and a small fee-payer for Solana setup slots), and there is no TELRPC contract on any chain: nothing of ours is deployed on-chain to audit, exploit, or trust. The only contracts you ever touch are the chain's own mechanics and the asset issuer's.
What each party can and cannot do.
Account identity is the address recovered from the signature itself, which no one can produce without the key. Caller ID is a routing hint only. Replay is bounded by each chain's own rules. No protocol message contains key material, so the channel has nothing of the key to leak.
The return path is held to the same rule. A confirmation echo moves the wallet's sequence forward only when its reference matches the transaction id the wallet computed itself, so a forged echo is ignored, and a wrong sequence is corrected against the chain's real value. A garbled frame fails its checksum and never broadcasts. A resend replays the same signed transaction, which can only land once, so it cannot double-spend. The worst a compromised line can do is cause a delay, never a loss.
No internet permission.
At all.
That absence is engineered in, not left over. The operating system enforces it, the build holds no code path around it, and anyone can read it back from the compiled binary. It is the first of four layers.
The manifest
The manifest declares no INTERNET permission, so the operating system grants the wallet process no network socket for the entire life of the install. There is no setting to toggle and no code path from a key to a network: the capability was never requested, so the operating system never grants it.
The proof
The compiled APK lists exactly four permissions, CALL_PHONE, ANSWER_PHONE_CALLS, CAMERA and USE_BIOMETRIC, and no INTERNET. aapt dump permissions reads them straight from the binary, and the wallet page shows the output. Anyone can run it, on any copy of the app.
The key
Keys are generated on the device. The recovery words are sealed with AES-256-GCM under a non-exportable AES key that the Android Keystore generates and holds, in the phone's secure hardware where the phone has it. The signing keys are derived from those words on the phone. Keys are never transmitted, because there is nothing to transmit them over: no server copy, no account, no recovery desk.
The chain
Transactions are signed offline and carried by a phone call that cannot alter them: a changed byte fails the signature. There is no TELRPC contract on any chain to audit, exploit, or trust; the only contracts you ever touch are the chain's own mechanics and the asset issuer's.
Nothing on the line ever contains your key.
Only public information is transmitted: a signed transaction destined for a public ledger, and nothing else. Key material crosses no channel, in any direction; the protocol has no message that could carry it.
The strongest configuration pairs TELRPC broadcast with hardware-wallet key custody: the key in dedicated silicon, the broadcast on the voice grid, the internet nowhere. A party that signs on its own device, hardware wallet, HSM or MPC setup uses the rail only to broadcast the signed transaction and read the state a send needs. The channel is narrow by design. It settles value, calmly and finally.
In the TELRPC Wallet that pairing is one cable long, or no cable at all: a Ledger, Trezor or BitBox02 Multi plugs into the phone over USB-C, and a Keystone, Passport or Jade passes each send by QR through the camera. The device approves and signs each send on its own screen, and the phone carries it by call. The keys stay on the device. Use your hardware wallet
Answered plainly.
How do I know it can never reach the internet?
Read the permission list out of the compiled app: aapt dump permissions shows CALL_PHONE, ANSWER_PHONE_CALLS, CAMERA and USE_BIOMETRIC, and no INTERNET. With no internet permission declared, the operating system gives the process no network socket for the life of the install. There is no setting to toggle and no code path to a network, because the capability was never granted.
What can the camera do?
It reads a QR code shown on another screen, and nothing else. The camera is a one-way sensor: it takes in a picture and can transmit nothing. It is how the offline device imports the public chain state it needs to build a transaction on chains that require live state. No data leaves the device through it.
What does the call-screening role do?
It lets the wallet read the caller ID of an incoming call and decline it silently, which is how the echo return channel works: the phone never rings and there is nothing to answer. The role is an Android feature (Android 10 and later) that grants no network access. It reads one incoming number; it cannot sign, send, or open a connection, and the wallet still holds no internet permission.
Why does TELRPC ask to be my phone app?
From version 0.9.39 the wallet can be the phone's default phone app, if you choose. As the phone app it keys each request at a steady, measured pace the moment the call connects, instead of the phone's own dialer pausing and keying, and it takes the grid's call-backs quietly while a wallet call is in progress, so a call-back can never interrupt a send. Ordinary calls keep working on its simple call screen, and emergency calls are never held back. It is an Android role, not a permission: the list stays at four, with no INTERNET, so nothing about your calls can leave the phone. Say no and everything works as before; to switch back later, open Settings → Apps → Default apps → Phone app. It suits a phone kept for the wallet alone.
What if someone forges an echo?
It cannot move funds. An echo carries public chain data or a reference to a transaction, never a key or an instruction to spend. A confirmation counts only when it matches the transaction id the wallet computed itself, and every echo is honoured only in a short window after the wallet asks for one. At worst a forged echo is ignored, or it causes a resync against the chain's real value.
Do you hold my keys, or run any contract?
No to both. Keys are generated on your device and never leave it: there is no server copy, no account, and no recovery desk. The grid that carries your call holds no key that can move your funds: its only keys are an operational Solana co-signer limited to one fixed setup template, and a small fee-payer for Solana setup slots. There is no TELRPC contract on any chain, so there is nothing of ours on-chain to audit, exploit, or trust.
Is this custodial?
No. The grid can never move funds. It relays transactions you signed and can only broadcast or refuse them. The worst achievable outcome of full grid compromise is denial of service.
Why a USB-C cable or QR for hardware wallets, and not Bluetooth?
Because a cable cannot be reached from across the room, and neither can a QR code. The TELRPC Wallet talks to a Ledger, Trezor or BitBox02 Multi over a USB-C cable, and to a Keystone, Passport or Jade by QR codes on the two screens, and carries no Bluetooth at all. USB adds no app permission: Android asks you to allow each device when you plug it in. QR uses only the camera the app already has. The keys stay on the device, which signs only what you approve on its own screen.
What if the call drops?
Nothing is broadcast, and the call heals itself. A garbled frame fails its checksum and never reaches a chain, and the wallet redials the same signed transaction, which can only land once. How self-healing calls work
Can the operator steal a transaction?
No. The signature binds payee and amount. Digits can be dropped, never usefully changed. Replay is bounded by chain rules: nonces, spent outputs, single-use authorizations.
What if someone swaps my SIM?
Nothing they can spend. The SIM is never a security factor: your identity is the cryptographic signature, not the phone number, and only public information is ever transmitted over the line. A SIM swapper cannot sign, move, or touch a single cent. The attack that empties SMS-secured accounts does not apply here: the number is the only thing they gain.
What does a call cost?
The call itself is ordinary airtime at your carrier's normal rate: a local call where a local number is live (15 countries today, 93 on request), or a call to the US line from anywhere. A broadcast is $0.10 of prepaid credit, as is every other call request (sync, balance read, swap price check, swap, token approval or contract read by call), never a percentage of a send. Every fee is shown on the review before you swap. With no credit, the wallet points you to top up at telrpc.com/topup. Every send pays its own network fee from the account.
What about the phone-to-address link?
That link is the one privacy cost, visible to us and to the carrier. The digits on the call carry only a signed transaction, which the chain publishes anyway, and never a key or a seed; the grid processes them and then deletes them within 24 hours. The balance line and the balance echo only read back a balance the chain already publishes.
What does the grid do with my phone number?
It uses the calling number to call the phone back with the echo, and to apply the per-number limits that stop abuse of the line. The digits of the call are processed and then deleted within 24 hours. Any SIM works, including prepaid, so a privacy-minded owner can give the wallet a number used for nothing else.
What if TELRPC disappears tomorrow?
You lose nothing. We never hold funds, keys, or the ability to move either. Your wallet and its history live on the public chain; any raw transaction it signs can be broadcast by anyone, anywhere, through any channel. We are a road, not a bank, and roads closing do not empty your accounts.
Why has nobody done this before?
Because two things had to meet. The technical insight that keypad tones travel the world as signalling and survive the codecs that killed every modem, and a carrier network to receive them. TELRPC brings the two together: Minutes Network runs the carrier side, and the wallet is built on it.
Can our security team review it?
Yes. The TRP/1 specification, the whitepaper and the reference source are shared with partners under licence and NDA as part of an integration, and onboarding runs alongside your own security review. The permission readback needs nothing from us: run it on any copy of the app.
How does this fit an institution's controls?
As design properties your risk committee can test. No network path to the key. The carrier path can delay but cannot alter or redirect a transaction. The grid holds no key that can move your funds and deploys no contract. Treasury addresses on your allowlist broadcast on your subscription; any other address needs its own paid credit. Each seat is recorded with its role (admin, operator or viewer) in a seat register, and an audit log records every change and every broadcast, with CSV export. For institutions