OMG Network

Nick is an entrepreneur using Dai in underbanked communities. Ask him questions!

@nick is known in the Muggle world as Nick Williams. He is a cofounder of Sempo, a startup that has experimented with cash aid using blockchain in a number of scenarios, and recently finished a pilot program in Vanuatu in partnership with Oxfam.

The tl;dr of the Vanuatu pilot is that residents of two villages were given smart cards preloaded with Dai, and vendors were given smartphones with an app for accepting payments. The cards are read/write capable so they can be used even if the app isn’t connected to the internet. A cash-out system was established (after a couple of hiccups) so that vendors could exchange their Dai for local currency.

In the many conversations I’ve had about using crypto for cash giving, the question always arises: will people actually use the tokens they are given or just cash them out at the first opportunity? If they’ll just cash out immediately, what was the point?

In this case, they were able to achieve some pretty massive increases in efficiency with onboarding. Between ID checks and bank visits cash aid onboarding had been taking around and hour; getting a new user signed up for the Sempo cards took around 6 minutes. Overall adoption was pretty expedient - within the first week of the pilot, about half of the money that was given had been spent.

Nick also mentioned that while most wanted to cash their Dai out for Vatu, some vendors did use the Dai they received from sales to program participants to transact with other vendors. It will be really interesting to see what happens on a longer timeline. My own theory is that the more Dai people receive and spend, the more they will come to think of it as “real” money - and the more willing they’ll be to just skip cash altogether…but the only way to find out is through more of this type of interaction.

There are posts about weeks 1-3 of the first phase of the program on the Sempo blog (they returned about a month later for another two-week visit, which has yet to be as thoroughly documented):

There’s also an interview with the Oxfam project lead here:

And a Coindesk article about the pilot here:

Sempo’s 2018 learnings report is a good place to dive into some of the more technical aspects, although things have come a very long way in the year and a half since that was published.

The intersection of humanitarianism, capitalism and decentralization - where empowering people is actually a business model and the “business” is a network of thousands that blurs the lines between user, creator and service provider - is absolutely fascinating to me and I think it’s the best possible future of blockchain. I think Sempo is sitting neatly in this space, so I’ve thoroughly interrogated Nick about this and I thought you all might like to do the same. He’s kindly joined us here to answer any questions we can come up with about Sempo’s experience trying to bridge the Ethereum-reality divide.

Ask away, ONC!


This is quite significant in terms of taking the humanitarian route to DeFi adoption (hello unbanked).

A few questions:

  1. How did the government respond to the use of DAI?
  2. What were the steps from DAI to…DAI (settlement)?
  3. Where is the system open and/or closed?
  4. Was there any formal study conducted by the charity?
  5. What problems still need to be solved? Or are we saying this works?

Thanks and well done


Hey all, and thanks @AA for the intro!

Please do ask anything you want; happy to go into the tech challenges, our messaging approach given we were working in communities where ~70% of people hadn’t even used a smart-phone - you name it!

Gonna kick-start this by responding to a couple of interesting points @AA raised.

A cash-out system was established (after a couple of hiccups) so that vendors could exchange their Dai for local currency.

Blurrrgg, “a couple of hiccups” for sure - we really underestimated this one at the start. Our initial scoping had found that despite most vendors being run by a single person in a space bigger than a garden shed, almost all of them had a bank account, as there had been a big drive by the local community leaders to get vendors banked. Incidentally all the vendors I spoke to hated the banks, but that’s another story.

The plan was that we’d just act as a direct exchange for vendors - Oxfam would distribute Dai to recipients via the Sempo platform, recipients would spend the Dai at vendors, and then we’d purchase the Dai from vendors and send them fiat from our bank account in Australia, direct to their bank accounts in Vanuatu. We’d tried something similar for a refugee community in Athens and it worked a charm.

Going into the pilot, we’d planned to partner with maybe a dozen vendors. We ended up partnering with 34, which was the majority of the vendors in the communities we were working in. This was great because it meant that recipients (and in turn, vendors) could use their Dai for a heap of things - food, clothing, medicine, school fees, even phone and electricity bills.

The increase in the number of vendors also meant that with repayments of vendors happening every three days, the amount we were needing to reimburse some of the smaller vendors was only about 2,000 Vatu (18 USD).

When it came to making the first reimbursements, we were horrified to discover that the SMALLEST transfer from Aus to Vanuatu that we could make using our bank was 20,000 Vatu, so we were literally an order of magnitude off. We’d never run into this problem in the past because we’d never worked with such small vendor reimbursement sizes.

We had a look at some other Australian banks, but it was a similar story - either there was a minimum transfer amount, or such a high flat-fee for transfers that our remittence overhead would have been over 200% for a 2,000 Vatu transfer.

We couldn’t just ask Vendors to wait until they had 20,000 Vatu either, as the vendors were reliant on getting cash to buy more supplies.

What we came up with was the idea of a “super vendor” - vendor in the community that had quite a lot of cash reserve and volume through their store. We asked the super vendor if they’d be willing to take Dai from other vendors and cash them out. This way we’d just have to make bulk payments to one or two vendors.

We offered a 5% commission in Dai as encouragement, and the vendor agreed. The commission was handled by building in a special “Cash Out” feature into the app, which was only accessible on the apps of vendors that we’d designated as super-vendors. This cash-out feature ran through our regular payment-flow, but let our system know that the vendor required their commission. Then we’d automatically trigger a small Dai disbursement from Oxfam’s address to theirs.

The UI for the supervendor was less than ideal, and I don’t think she fully got her head around the fungibility of money - we repaid her for both goods purchased through her store AND for her cash-outs in combined payments, and she kept on wondering where her other payment was, but I think this could have been improved with better communication on our behalf. Given that this process was conceived, iterated through with the community, and hacked into the platform in a space of 18 hours, I think it went really well. Other vendors actually much preferred the process of getting repayments via the supervendor as it saved using their still-hated bank accounts, and it massively reduced our overheads.

My own theory is that the more Dai people receive and spend, the more they will come to think of it as “real” money - and the more willing they’ll be to just skip cash altogether…but the only way to find out is through more of this type of interaction.

We’ve definitely seen evidence of this ourselves. When we piloted with Syrian refugees in Lebanon last year, everyone made an effort to spend ALL of their funds on the first day, even though they’d been given enough money to buy supplies for a month. Because people didn’t want to leave any balance behind, they’d end up buying stuff they really didn’t need, like cake mix. In cases were recipients received a second and third round of funds, we noticed that they’re behaviour slowly transitioned back to a more regular behaviour, with balances being exhausted over two or three shopping trips, rather than just one.

In Vanuatu we really concentrated our messaging around the idea that “this card is loaded with Vatu, spend it just like you would regular money”. As a consequence, from the very beginning we saw a lot more tiny purchases that were more reflective of how people spent their physical cash - people would go to stores multiple times a day, buy a singular bag of rice, can of tomatoes and so on. In only three days, our first 100 recipients made over 500 purchases using the platform, which was super exciting to see.

1 Like

This seems functionally quite similar to the “local exchange shop” in Will Ruddick’s Eco-Pesa experiment ( In general this model seems to serve two opposing, but both necessary, purposes:

  1. Provides an exit ramp from the decentralized digital currency, which is crucial for demonstrating that the the digital currency can in fact be seen as “real money” and
  2. Introduces just enough of a pain point that there’s an incentive for participants to continue to exchange Dai rather than cashing out, once enough trust in the digital currency is established.

For anybody not familiar, Will Ruddick’s work is in this vein as well and has had extremely promising results - the Eco-Pesa program mentioned above introduced a “complementary currency” which was backed by the Kenyan shilling. In that experiment, according to the research report linked above, “An estimated $4,176 USD worth of trading was facilitated through the circulation of only $352 USD worth of Eco-Pesa.” That’s extremely promising for this whole concept of using a non-fiat exchange currency to facilitate exchange within trusted networks!

1 Like
  1. How did the government respond to the use of DAI?

This was a big challenge for us. The Vanuatu government is very anti-crypto at the moment:

  • Vanuatu is a tax haven and has huge problems with grey-market money laundering
  • Vanuatu has recently fallen prey to a number of pretty scammy ICOs etc from foreign orgs

For this reason, Oxfam orginaly didn’t want to use a cryptocurrency at all, rather just an ERC20 token to track the movement of funds only - similar to the WFP’s Building Blocks project.

Technically easy, but I think this doesn’t realise the full potential of blockchain technology; because there’s no actual value transferred on the blockchain, as there’s still a reliance on a single trusted party to reimbursement of vendors, which means:

a) There’s not truly end-to-end transparency

b) The system can’t ever be open loop

c) There’s no motivation for third party exchanges who find cheaper ways to get cash to vendors to step in

We came up with this idea of a “crypto-collateralised voucher” - rather than giving Dai directly to recipients, we used it as collateral to mint a second ERC20 token which was then distributed to recipients. The ERC20 contract included a simple whitelist of who was allowed to burn vouchers to access the underlying Dai collateral. Only organisations that met the regulatory expectations of the Vanuatu Government (in this case just Oxfam and Sempo), were included on the whitelist.

This ends up centralising things a lot more than what’s ideal, but critically, it once we had it in place, the Vanuatu Gov was comfortable that random people wouldn’t be using the platform to launder funds, while we still get access to a), b) and c). Critically, it also meant that we only had to conduct KYC checks on vendors that were to receive fiat, which was a huge bonus because a good proportion of the recipients didn’t have the identity documentation necessary for KYC. Ultimately the government appeared to really like the process, because it gives them far more transparency into how foreigners (govs and charities) are spending money inside their country.

  1. What were the steps from DAI to…DAI (settlement)?

If I’m understanding your question properly… In theory:

  1. Australian Government Department of Foreign Aid (the donor for the project) buys Dai
  2. Dai is sent to the crypto-collateralised voucher contract, and an equivalent number of vouchers are minted
  3. Vouchers are sent to Oxfam’s wallet on the Sempo platform
  4. Oxfam uses Sempo platform to distribute vouchers to all the individual addresses of recipeints.
  5. Recipients use the tap-to-pay cards at local vendors to buy things
  6. Vendors either spend the vouchers themselves, or request reimbursement
  7. Sempo sends the vendors fiat via bank transfer (and via supervendor, see previous comment(
  8. Sempo then receives vouchers in exchange
  9. Sempo burns vouchers to access Dai
  10. Sempo sells Dai on your-favourite commercial exchange

In reality, Aus Government had already allocated the money in fiat, Oxfam team couldn’t get board approval to purchase Dai in time, so we ended up purchasing the Dai on Oxfam’s behalf. We did get direct approval from Aus Government to convert their aid funds into crypto, which is a huge win for an organisational change point of view!

  1. Where is the system open and/or closed?

Given the use of the voucher, it’s a little hard to define the open-closed split - anyone was free to send vouchers to anyone, but these vouchers aren’t a lot of use unless you can find someone who’s willing to accept them. That being said, vendors also received a disbursement, and because they’d been KYC’d, they were free to take to the super-vendor and exchange for fiat, so one interpretation is that the system was open for anyone who’d passed KYC checks.

  1. Was there any formal study conducted by the charity?

Yeah, they did detailed Monitoring and Evaluation of the the entire process. Results are in the process of being analysed and written-up.

  1. What problems still need to be solved? Or are we saying this works?

Things that need to be fixed:

  • The local communities had (understandably) absolutely zero interest in working in USD rather than the Vatu. We used a pretty hacky way to get around this - we just hard-coded a conversion rate between USD and Vatu that kicked in right before a transaction was actually signed and sent to the blockchain. We could only get away with this because we knew we’d be the ones who’d end up taking the FX risk, which was ultimately pretty small.
    This process completely falls apart once there’s more than one party putting money into the platform, or acting as an exchange for off-ramp.

Our plan is to swap over to using a Synthetic Vatu Asset rather than Dai; taking Dai-USD and re-pegging it to the Vatu in the same way that Dai is taking Eth and re-pegging it to the USD. We’re currently working with MakerDao and an organisation called UMA to pull this off.

This is actually something I’m SUPER excited about. Everyone talks about how blockchain has the capacity to massively reduce the cost of cross-border payments, but I think the general thinking around this is pretty unsophisticated - one of the biggest cost in cross-border is getting your hands on the local-currency, so it doesn’t really matter if you’re using Ripple or Stellar to send XRP or XLM at 0.00001 cents if you’ve still got to find a way to convert that at the the receiving end into a currency where there’s a lack of market depth - you’ll still loose a tonne on the spread/slippage. By using a Synthetic Currency asset, you can basically have anyone act as that trading counter-party, which massively increases your exchange depth, and thus reduces those transfer overheads.

Our plan is to open up the platform so that ANYONE (not just NGOs and their recipients) can send and receive funds through it, but we’ve got a lot of work to do for that to work.

  • Honestly, just too many bugs. We’re only a team of three people (two of us technical), and if we were at any sort of scale we’d be completely overwhelmed by the number of transfers that just didn’t go through for some unknown reason. We’re working on that one lol.
1 Like

Yep - I’m a masssive fan of Will’s work. I guess the main difference is that Will has off-ramp friction by design, where as for our platform we try to reduce that friction, will also acknowledging that it exists and trying to make everything work as well as possible with its presence.

Hello @nick :wave:

Thank you for sharing your experience. I loved it.

I have few questions for you :

  • What was the biggest challenge?
  • Would you have done something differently now that you have a strong insight on the topic?

You’re welcome, glad you liked it! It’s nice to able to get into the weeds and talk about the details of it all.

Firstly the terrible banking experience mentioned above. On that topic I forgot to mention on that:

  • bank transfers took anywhere between 3 to 5 working days to arrive
  • if you entered the recipients name even slightly incorrectly for the transfer, it wouldn’t arrive at all. This wouldn’t be a problem if it weren’t for the fact that a significant number of vendors had slightly different spellings on their ID documentation to what was on their bank account; eg Rosy on the ID, Roesy at the bank - definitely saw some creative spellings! We only worked this one out after a whole bunch of transfers failed.

We also had huge issues with the mobile phones we provided to vendors. They were old HTC M7s that we bought of Alibaba for about 60 USD - the cheapest phones we could find that supported reading NFC cards. Sent one over ahead of time for Oxfam to test, and it worked great. Arrived in country to launch with another 20-something phones, and ~70% of them could barely connect to the internet. It’d take about 5 minutes to load up the vanilla Google home-page. Trying to download an image was out of the question. Turns out that lots of these phones had a slightly different radio chip/firmware on them - one that wasn’t terribly compatible with Vanuatu networks. Spent a couple of days trying to upgrade the firmware, but no dice.

Our platform is designed to work offline, so this shouldn’t have been too much of an issue: when a vendor taps an NFC card against their phone, the phone checks the balance on the card, and if there’s enough, updates the balance on the card (using a couple of cryptographic tricks and one-way counters to stop the card-holder reversing it back), saves the transaction locally, and lets the vendor know the transaction is good. Then when there’s an internet connection detected, the phone syncs the transaction back to the main platform (and the mainnet). So in theory, the phone should have been able to sync back to the platform at its own leisure, regardless of internet speed.

Unfortunately, our app would only try and sync when it was open. This was fine in testing, because assuming there was an internet connection, the syncing process would be over in seconds. In the real world with horrific internet, syncing would take at least a couple of minutes, and vendors never left app open long enough for the process to complete. We managed this to some extent by telling all the vendors to leave the app open and running whenever possible, but it was a real pain.

Having the app set up to background sync would have been an easier solution. Phones that actually worked would have been better still.

I’m kicking myself for not doing a better job of QA-testing critical third-party elements (phones, banks). We made far too much of an assumption that our experience with banks in Vanuatu would be roughly equivalent to our experience with banks in Greece, and phones that worked here would work equally well over there. It’s so stupid and obviously wasn’t the case in hindsight. Everything worked great in the end, but it would have saved many sleepless nights if we’d tested these elements better.

Also, if I’d known beforehand how successful the concept of the supervendor was going to be, I would have built that more deeply into the app to give supervendor’s a better user experience. I think it’s a really great way to get cash into a community, but the process we ended up using was pretty hacked together at the last minute. Which is totally fine of course - you only learn these things by getting out there and trying stuff!

1 Like

First off, welcome to ONC @nick and many thanks for sharing your experiences with us.

I’d love to dig into these points to start :slight_smile::

Can you elaborate more on your experience working with the Aus Government, getting their approval? Were they aware of DAI before your project?

This seems like a fascinating way to square KYC and introduce DAI to new users // can you share more about the design and erc20 code?

1 Like

To be honest, most of the conversation with DFAT handled by Oxfam, since they were the organisation who’d secured the funding from DFAT (Aus Department of Foreign Affairs and Trade) to do a blockchain-based aid pilot. All I did was write a formal looking letter that Oxfam then passed on to DFAT.

Key points that I think won them across:

  • UNICEF has used Dai. Even that UNICEF has only really used Dai for collecting donations and other low risk stuff, it makes a government way more comfortable if you can point to another more conservative organisation such as the United Nations that has already used the tech. (No one ever got fired for buying Microsoft, or something like that).

  • We promised to cover any costs in the case of price-slippage from a black swan event. No ideal, but helped us get our foot in the door.

I can’t confirm, but I’d wager DFAT hadn’t heard of Dai. We’re finding that even the concept of stablecoins isn’t that well known, even when working with people who are approving funds for blockchain projects and so on. Which is great, because we largely get to set the tone of the conversation going forward, and I think just getting our foot in the door and giving DFAT a positive initial impression of Dai/Stablecoins as something quite distinct from speculative cryptos like bitcoin was a huge win for this. My understanding is that MakerDao is now using this pilot as evidence to persuade other government agencies that cryptocurrency doesn’t have to be scary.

Sure thing. The code ER20 contract (source code here) is incredibly simple - minting a voucher triggers a “transferFrom” call to the Dai Contract to lock up an equivalent number of Dai, while burning a voucher unlocks Dai, but can only be called by addresses that are on a whitelist defined by the contract owner.

Looking at everything from a more conceptual level is where it gets a bit more interesting. We spent a fair bit of time with lawyers trying to determine what constitutes a cryptocurrency versus a plain token, and it’s pretty murky. It appears that a lot of it just comes down to the language you use in framing it, so two smart contracts with identical code can be classified quite differently depending on the context. (Is a knife an illegal weapon or a kitchen tool?) The diagram below outlines how we viewed the flow of value.

The key thing for us was that we wanted to be able offer some assurance to the Vanuatu Reserve Bank that someone couldn’t run off with tokens and use them to launder dirty money or buy illicit items. We did this by ensuring they didn’t free-market value to anyone except organisations (ie Sempo and Oxfam) that were reimbursing vendors who’d been vetted to ensure they were above board.

An extension on this concept would be to set the contract up such that the tokens couldn’t even traded unless the recipient was on the whitelist, but that was apparently overkill.

If you’re interested, I’ve attached a document that outlines this token-design process in a lot more detail. Once again, all the smart contracts are actually incredibly simple - it’s largely the choice of language that makes everything work.