Swarm City - Shortcodes

Swarm.city’s mission is to bring Ethereum to the masses. One of the main strategies is to have a UX experience that is clean and simple and does not confront the user with blockchain jargon, hashes, public keys, gas and other complicated concepts.

In Swarm.city, token transactions are simplified by generating a short code on the receiver’s device. This shortcode is communicated to the sender over another channel. The sender enters the shortcode and gets to see the receiver’s account information. With this info, the sender device can make the transaction.

To do this in a truly decentralized way is not as trivial as it might seem. We have to mitigate brute-forcing, pre-mining and man-in-the-middle attacks as much as possible. This hackathon project solves this in a reasonably secure way. The result is a protocol, to be found in our project repo. This repo also contains a very basic UX demo.

We initially started by brainstorming ideas about how the protocol could be designed. We came up with different attack vectors and ways to protect against them. Initially, we thought that doing this type of transaction with only one shortcode (4 or 5 digits) was impossible in a decentralized way. We thus started to investigate longer handshakes, where multiple shortcodes would have to be communicated over an external channel. However, this didn’t quite feel appropriate, and we ended up redesigning the protocol entirely. The latest version uses Proof of Work, shortcodes derived from signatures, timing constraints and proof of recent generation. This means that attackers should not be able to brute-force a code in the time constraints, cannot “pre-mine” shortcodes for further use, and thus cannot execute a man-in-the-middle attack. More details are provided in the README of our project. The protocol is executed over Waku, but can be done over any Pub/Sub or communication channel.