Can you accept a digital payment while you offline? Yes! Let me explain how…

How amazing would it be to make a secure payments without network connection — this will remove all advantages of cache in compare to digital currency. And this is possible but within limited use cases.

One of use cases is a payment for taxi ride — taxis are moving around the city all day and all night and occasionally they entering offline zone if not whole operational area is covered by mobile network. The technology described here can let the passenger to pay for his ride if the ride finished within offline zone where there is no network connection. This technology however have some limitations those I will describe later and it cannot be used for any type of purchases but is good enough for taxi service.

Here is how it works

Vocabulary

• passenger app — mobile application used by passengers to pay for the ride, registration and KYC is required
• driver app — mobile application used by taxi drivers to accept payments — registration and KYC is required
• online zone — area of service with mobile network coverage
• offline zone — area of service without mobile network coverage
• account address — EVM externally-owned account address of driver or a passenger
• passenger account — a record inside accountant contract that contains account address of passenger, his balance, nonce, timestamp of last transaction, timestamp of wothrwawal request . There is a hourly-spending limit (let’s say no more than $15 per hour). Balance of passenger account could only be used as a payment for taxi ride. Passenger can withdraw his assets with time-lock of one hour
• driver account — a record inside accountant contract that contains account address of driver and his balance
• digital check — payment order signed by payer’s private key — produced by passenger app
• nonce — a sequential number added to digital check for preventing re-play attack
• accountant contract — smart contract that accepts transfer orders, validates and executes them. This contract stores balances of customer accounts and driver accounts
• transfer order — a data of a trnsaction to accountant contract that contains digital check signed by driver’s private key. Driver’s signature is needed in order to make re-play attack more difficult
• local cache — storage within driver app that contains balance and nonce for each passenger registered in system. Updates constantly while driver is within online zone
• transfer orders pool — storage of transfer orders within driver app — keeps transfer orders collected while driver was in offline zone, once driver enters online zone, the app sends them to accountant contract via relayer
• withdrawal process — state of passenger account when passenger initiated withdrawal. He can claim his funds after a cool-down period of one hour. If any transfer orders will arrive within one hour they value will be deducted from balance
• relayer — a service that exposes API to accept meta-transactions, converts them to EVM transaction and sends it to accountant contract, this service pays network gas fees

The workflow

• If ride is finished within offline zone client could pay to driver by issuing a digital check — it is produced by passenger app by scanning QR-code with address of driver account and entering an amount to pay
• When driver accepts digital check by scanning QR-code that contains digital check it gets validated by driver app Passenger’s signature is verified, using the data from local cache verified data of passenger account balance, nonce, and that passenger account is not in withdrawal process
• Let’s say one hour ago passenger’s balance was $30 (data from local cache) and passenger made a digital check for $10 — driver app knows that now user’s balance is not less than $15 (as accountant contract will not let to spent from passenger account more than $15 an hour)
• If all those checks have passed then it’s safe to accept digital check as a payment for the ride and driver will be notified about it by driver app
• Once accepted digital check will be signed by driver’s private key and stored in transfer orders pool
• Once driver enters online zone his app will send all transfer orders from transfer orders pool to relayer via API and relayer pays the blockchain gas fees and submits transactions to accountant contract
• accountant contract will verify each transfer order it received and transfers funds from passenger account to driver account. List of checks: passenger’s signature is valid, driver’s signature is valid, nonce of digital check doesn’t breaks the sequence, amount is not exceeds $15, last transfer from passenger account was earlier than 1 hour ago
• If passenger wants to withdraw his funds from passenger account he send withdrawal request to accountant contract and one hour later can claim his funds with additional transaction. All digital checks produced within withdrawal process will be considered invalid, but transfer orders those arrive during withdrawal process will be executed

Possible hacks

Front-running attack:

• Attacker is a passenger who wants to get a free ride
• Attacker pays with digital check to driver A and driver app accepts it
• Attacker enters online zone before the driver A and issues digital check with same nonce but for another driver: driver B (attacker’s companion)
• Attacker should be able to sign fraudulent digital check with private key of driver B and produce fraudulent transfer order
• Attacker sends fraudulent transfer order to accountant contract via relayer
• Accountant contract makes a transfer from attacker’s passenger account to driver account of driver B
• By the time driver A submits original transfer order from his transfer orders pool it will be rejected because of duplicated nonce and driver A will not receive a payment

How much attacker can get: no more than $15 in a form of free taxi ride

Multiple spending attack:

• Attackers are a group of passenger who wants to get a free ride and all of them shares the same passenger account
• All attackers finishing their rides within the same time inside offline zone
• Each of attackers pays to the driver with digital check and each digital check contains the same nonce
• Only the driver who submits his transfer order first will receive the payment — other transfer orders will be rejected by accountant contract because of duplicated nonce

How much attackers can get: (N-1)*$15 in a from of free taxi-rides where N is a number of attackers

This attack requires precise coordination as taxi ride have to be finished approximately at the same time for all attackers and before each driver is moved to online zone

How to deal with hacks

There is no way to prevent those attacks but each attack is easy to discover. It only takes to search inside rejected transactions list and from there all dishonest passenger accounts could be derived. Then all those passengers could be banned from the system. As we can see the reward for attackers is relatively small and doesn’t worth the efforts needed to perform this attack. That’s why this technology is good enough for paying for the taxi rides.

Limitations

It is not suitable for high-value purchases and for the scenarios when multiple purchases could be done within short time frame and when recipient can stay in offline zone longer than minimal interval between one-customer purchases

Inspired by Quito taxi drivers who never have a change