Tutorial: How to tokenize your marriage

Recently my wife and I decided to take the leap and exploit the blockchain to its full potential.

So we tokenized our marriage!

And things have never been better. Decentralization really is all the great things they say about it. 

In this post I’ll share a bit of what the experience has been like, some details of how we did it and how the blockchain has changed our lives forever. With this tutorial you too can tokenize your marriage and live a happy trustless life.

Taking the Leap

Every day it’s the same. Kids (11 and 14 year old) either needed their school lunch cards recharged or some small cash for daily expenses. Phone credits, library money, candy, whatever.

For the bigger stuff, wife and I had “work meetings” deciding where (what was left of) the budget went. We get along well but these meetings end up putting a strain on us after tiring work days. It’d be great if somehow we managed to not make these small burdens a daily thing and put it off for longer spaced periods instead.

Unexpected expenses: car, dentist, you name it. All these things can be taken care of by either of us in their own time. Independence has been central in our relationship for years and I figured that cryptocurrencies could help us.

All these little things we end up doing require some coordination within the family structure and I noticed that, making an analogy with bandwidth bills, we were spending more time on metadata than on data itself (which is a well known problem in any project).

The communication and decision processes ended up consuming more than the actual things that had to be done. Reminds me of Peopleware and Death March software project books that everyone had to read back in the 90’s.

Decentralization

It suddenly came to me: decentralization. Isn’t this exactly what decentralization was made for?

Each of us could then make more decisions on their own, everything gets done. Responsibilities get delegated. Then we sit together once a week or twice a month and check whether things went alright. The meta part then became a weekly or bi-weekly event, instead of something permanent and scattered throughout the day.

How exactly did we do it. I came up with a starter framework for a Family Autonomous Organization – FAO.

If you’re still here, then read on for the details.

Getting Started

First I needed to make the idea concrete. What, exactly, was I going to be doing here?

I slept over it for a couple of weeks until I finally had mentalized what I’d like to do : create my own RingToken (I’ll call it RTOK here, although for privacy reasons I used a different name on the blockchain), come up with a converstion system between U$ and RTOK then establish the business rules for the Family Autonomous Organization (FAO).

Take all this, code it up in some smart contract and bam!

I’ve tokenized my family!

So, next step : I had to decide on a blockchain infrastructure. I thought about reinventing the wheel, but why? There are smart people worrying about that – I just need some kind of smart contract to get my FAO idea off the ground. I also thought about making it fancy and allowing the kids to mine their own tokens so they’d learn mining. But then I figured that proof of work is so 2010 and it’d end up becoming one more thing for me to maintain. Plus ...the electricity bill. So I decided against forking Bitcoin to create my own crypto.

Ethereum seemed like the perfect fit. It’s been tried and tested for years, its smart contracts work a charm for thousands of crowdfunded projects. Why wouldn’t it work for the crazy GoF (gang of four)?

Smart Contract

I can program Javascript so learning Solidity was easy. I began with a basic ERC20 skeleton program I got from the WWW, compiled it using “hello world” examples and then tested it on Ethereum’s make-pretend network (Ropsten). It seemed to work fine but I noticed that some functions spent a lot of “gas” just to get through some basic stuff and so on, basic smart contract foo. I survived this phase by stackoverflowing myself through the process.

Anyway, my smart contract ended up having the basic ERC20 functionality (transfer, approve, allowance, etc) plus some stuff I wanted the FAO to do on its own.

Mum and pop have the private keys, obviously, so we can use the special functions: allowance, approve and transferFrom.

Kids have their own private keys but they can only be “clients” in the FAO smart contract.

I made a special admin-only func called authorizeAddr(addr) where I could authorize which public addresses could join the FAO. If the kids lost their private keys they could just go to myetherwallet and create new ones. Then I’d burn the old addresses and re-authorize their new ones. I decided to have this func, even though it made the contract more complex, because I knew they’d lose their keys, eventually. If I hard coded the addresses in the contract then I’d have to reboot the FAO every time they lost the keys. No can do.

Fiat Uno

Then I had to figure out the fiat money part. Obviously I’d have to invest some actual cash into a starter fund to make this work. I thought of forcing the kids to participate in my own ICO and return their recent allowances in exchange for RTOK’ens but their mum decided that wouldn’t exactly be a great idea education-wise. So she kindly convinced me to find a different funding strategy.

Alright, so….I’d be my own angel investor.

I set U$ 2500 apart and now had to find out how to wire RTOK up to the fiat money in a way that everyone could go on doing their stuff without requiring central authorization each time. This, plus the blockchain registry of everything everyone did, would form the FAO. If anyone did anything outside what we agreed, it’d be on the blockchain forever and would likely be one of the subjects in the next Fcrum meeting (Fcrum = FAO Scrum).

In short, I needed to :

• Come up with my own RTOK ↔ U$ exchange rate;
• Find a rechargeable debit card the kids could use;
• Request an account holder card for the wife;
• Wire a serverless system up that would handle RTOK ↔ fiat exchange upon command.

RTOK Exchange Rate

Deciding the exchange rate was the easy part. It’s good to be the FED in your own midget kingdom!

RTOK would equal a penny. So 100 RTOK = U$ 1 and Bob’s your uncle.

Which means that my initial fund consisted of 250,000 RTOK.

Rechargeable Card

I decided to test a well known cryptocurrency payment processor’s rechargeable Visa cards. In case you’re curious, when I searched for rechargeable cryptocurrency card, it was the first thing I found so I thought I’d give it a try. I don’t want to make this about their specific product since you can build the same idea yourself using any system that provides you with API access. Most traditional banks don’t so that’s why I went with a more modern payment processor’s API.

I went through their excruciating KYC procedure, got my DNA, blood type, retina, pee, feces and fingerprints authenticated and finally, after 6 weeks of torturous bureaucracy I was able to obtain a U$ 2500 transaction limit. After which I requested 4 cards, 2 administrator-level and 2 precharged for the kids.

This step also solved mum’s card issue. Now for the fun part. Gotta wire all this together to create the FAO.

Going (Almost) Serverless

I’d been tinkering with Amazon AWS for a while and thought their Lambda thingy was pretty cool.

So, the idea was to create a few Lambda routines that would react to some stimulus that I’d send them.

This had to be authenticated of course and what better way than to sign transactions using the RTOK smart contract private keys themselves!? Single authentication for the whole administrative part of the FAO! Private keys are then master keys both for the smart contract management and the serverless procedures.

So far so good.

I loaded up the RTOK smart contract public signing keys into a Javascript string, packaged it into a separate JS file and wrote a makefile that would concatenate the key as a var pkey_x variable into the top of all my Lambda scripts in my development notebook.

The keccak crypto routines are built into Solidity so signing stuff on the smart contract side was pretty simple. The hard lifting is done by the Ethereum Virtual Machine which has these functions built into its core, so no need for a bloated smart contract.

AWS Lambda on the other hand was a bit more complicated. Took me a while to get a keccak routine working on the client side and testing it against the smart contract on the Ropsten test network to get the exact same signature out of both when using the same key (duh). Once again I stack overflowed myself through the code and in the end had 1500 lines of Javascript that I could again load up on top of my Lambda scripts via a makefile at deployment time.

The Appliance

So I need an oracle to interact with my ERC20-based smart contract and give me signals to send to AWS Lambda. How do I make an oracle in a blockchain with no support for oracles?

I decided to create a python script running on the cheapest possible EC2 instance. Yes, it’s supposed to be serverless but I’m not really serving anything from EC2, it’s just a virtual appliance. I called it Appliance. (Reason for the name is I initially thought of building this up on a Raspberry Pi. More on why I decided against this below. Just keep in mind I’m using EC2 as an appliance, not as a server.)

I probably could’ve figured out how to create something like a periodic daemon on Lambda (by sending itself a message every once in a while) but I didn’t have the time. Plus Lambda’s supposed to be reactive short microservices, not a long running routine. (Well I might be wrong here, software architecture purists might not like my solution but my end goal was to not have to keep a PC on 24x7 at home. )

In my region we have frequent short blackouts. Like 10 to 15 minute outages at 3 AM. We mostly don’t notice these except for the fact the long running processes I left on the night before, hoping to find it done in the morning, greet me with a black screen and complete silence from the box. So I don’t want an additional thing to have to monitor at home. This is, after all, supposed to be an autonomous organization.

So I got the cheapest possible EC2 instance and pushed a short python script to it that routinely performs the following functions:

• Sign and send an administrative command to the smart contract requesting the latest transactions;
• Retrieve said transactions;
• Send appropriate commands to Lambda instructing it to perform the fiat transactions on the credit card processor.(This led me to question why I’d use Lambda AND EC2 together. Perhaps I should code everything in python and run it all on the EC2 instance? Sure. But I had coded the Javascript stuff before and it was working fine, so maybe I’ll refactor this into 100% python in a future update.)

Kids’ Interface

For the kids’ interface I made a simple Android app that sends messages to the smart contract. What it does is have a very very simple UI where they simply type in a RTOK amount and sign a message that calls the smart contract’s requestFunds(amount, addr, nonce) function.

The smart contract checks the address against the addresses we authorized to operate within the FAO. The nonce is meant to avoid any caching along the way, just so 2 requests for the same amount from the same address don’t compile down to the same exact bytecode. It could be used for something smarter in the future, but that’s what it is for now.

If authorized, the smart contract then checks my kid’s balance against the allowance amounts in the contract. If allowance >= requested amount, it then adds the address and amount tuple into an associative array like so:

ok_requests[address] += amount

If it fails, smart contract will instead run this line:

failed_requests[address] += amount

That’s all the kids’ smart contract does. The client user interface is just one text field and one button. There is no authentication because it is assumed all this runs among trusted people. The brothers' phones have their fingerprint password. If they get stolen I will burn the authorized addresses on the smart contract. Otherwise any other theft will be like any other theft - you can't do much but pray about a gun to your head when you're 11 anyway.

When the Appliance checks the smart contract it gets the list of ok_requests, failed_requests and saves them locally. Then it calls clearRequests() to set all amounts to zero.

Appliance then goes through each request. For the failed_requests it sends me an email letting me know that address requested an amount that isn’t available. I’ll then contact my boys to find out what happened.

The ok_requests requires more processing.

For each request, the python script grabs the (address, amount) pair and sends the appropriate commands to the credit card processor’s API. Funds get then loaded onto the kids cards accordingly.

I get Appliance to check on the smart contract about once an hour (it sets a new 60 minute alarm every time it finishes running the basic loop, so it ends up being 60 minutes + delay every run).

The reason I don’t increase the frequency is because each request consumes a bit of Ethereum gas.

If I ran the basic maintenance loop several times an hour it’d add up to a good amount monthly. So hourly money on their rechargeable card is as good as I can make it. Beats when I was young and I’d ask for some spare change for a soft drink once a day max.

The private keys were loaded by me on a text file in the client app. If they lose the key, I gotta take their phone, go to myetherwallet and generate a new pair and load it up manually. Then gotta re-authorize the new addresses on the smart contract and burn the old ones.

This could get improved in the future but for now it’s as simple as I could make it.

Mum/Dad Interface

Our interface is also a single screen and 2 input fields in a homemade hello-world grade Android app.

One field is a drop-down box where I select the address and the other is a text field where I insert an RTOK amount.

I have a makefile where I put the kids’ current addresses. Same file I use to build their own Android app – when I run the local makefile it substitutes the keys on both build directories.

The select box simply shows the addresses contained in that file in a list and which kid it belongs to.

This way I select the drop-down, type in some RTOK value and it sends the funds straight to their allowance balance on the smart contract.

That’s all there is to it.

I do the accounting by hand at this time, it’s not too hard to track anyway it’s just 4 people. For a larger DAO a more sophisticated mechanism would obviously be required for many of these procedures.

Wiring it all up Together

So here’s in short how the FAO works:

* I have a funded account with a payments processor that has an API and rechargeable cards;

• A daemon running in a virtual appliance behaves like an oracle, taking and emitting real world signals to/from the FAO smart contract;
• Balances, authorization and authentication are taken care of by the smart contract;
• I can operate this from anywhere with extremely low bandwidth;
• I control their balances by mind because it’s just 4 people and simple for me to manage. If this were a larger scale FAO then a more sophisticated accounting system would be mandatory.

FAO Architecture

So this is what the FAO architecture looks like.

I know I can probably get rid of either the appliance or the lambda code, but this is how I built it so it’s staying that way for now.

Conclusion

Being a tinkerer, this was a fun thing to make and to play around with the kids.

The family got a feel for the future, seeing how decentralization works. I guess they’ll remember this when, in the future, cryptocurrencies are a normal thing like credit cards once were alien and then became commonplace.

Proper delegation of responsibilities is crucial here, so we have a good chat every now and then to discuss what went right, wrong and so on.

One important detail is: my system does not have much in terms of security. It’s just 4 people and there’s trust between us. The family structure would break up before any such system if that trust were broken. So in this scenario it’s fine to simply let things run loosely. For instance, there’s no quota check on the smart contract. So it doesn’t check if allowance1 + allowance2 > available balance. That way, one of the brothers can withdraw more than the other. This will, of course, get discussed in a family meeting up ahead. Surely one of them would put up a tantrum faster than any virtual alarm could warn me if it ever happened.

It’s impossible to overspend the overall balance in this system, though. The kids also know we’ll have to discuss every good and bad withdrawal attempt, so they end up behaving.

Your mileage may vary but overall it was a fun experiment and something I could definitely turn into a commercial offering in the future. For now, the FAO has been a fun and rewarding personal experiment that I wanted to share with you all. My source code is full of private details so I didn't publish it for the time being. I might also make this into a product sometime in the future, but I'll definitely work towards making it a github open source base when I get to it. Cheers!