Building Gift Cards 2.0 on the block chain

The problem with gift cards 1.0

Everyone’s bought or received a gift card at some point in their lives. Gift cards are very popular with merchants and consumers alike. They’re an excellent last minute gift for friends or family and used commonly for corporate rewards and incentives.

The stats say they’re good for business, too. According to CEB, 65% of consumers spend 38% more than the face value of their gift cards.

Here’s the technical backstory that hardly anyone knows.

Gift cards 1.0 are inherently insecure

Gift cards in their current form are very insecure. Let’s take a closer look.

A plastic gift card is typically composed of two codes:

  • A 16–19 digit card number printed on the front or back of the card and encoded on the magnetic stripe. It’s usually enough info to redeem the value on the card.
  • A 4–8 digit PIN, sometimes hidden behind a scratch-off label or gift card package. It’s typically required to check the balance and sometimes to redeem.

A gift card 1.0 is just a static serial number, sometimes with secret PIN

Digital gift cards are essentially these codes without the plastic.

Where do the codes come from? The codes are typically generated by the issuing merchant’s gift card processor and transmitted in electronic form through secure channels to distributors who may print them on cards for sale at retailers, or further transmitted in digital form to aggregators and resellers (Gyft is one), until they end up in the hands of a buyer and ultimately the gift card recipient. From the moment these two codes are issued to the moment they are redeemed, these numbers never change.

If a gift card 1.0 is viewed as a lockbox with a secret key to open it, this is equivalent to sharing the secret key to transfer ownership of the card, trusting no-one leaks a copy to a thief.

like passing the key hoping no one makes a copy

Each party in this chain of exchanges must be trusted to keep the codes safe from thieves. Unfortunately, gift card codes do get compromised, which results in a bad customer experience and financial loss for the issuing retailer. Retailers themselves estimate that 62 percent of gift card losses are attributable to dishonest employees and 13 percent to counterfeit or skimmed cards.

Once a code is compromised, it might not be detected until redemption, and upon redemption. But upon detecting that a code was compromised at redemption, it is impossible to look back provably identify the party who broke the chain of trust.

Fragmented and incomplete APIs

Gift cards are unlike credit and debit cards. Credit and debit cards require a standard infrastructure between thousands of financials institutions and millions of merchants. This ubiquity has led to the emergence of a few large global networks and associated protocols and APIs. A gift card, on the other hand, is a singular instrument typically redeemed only with the merchant who issued it. This has allowed a much wider variety of gift card APIs to coexist.

In addition, wallets such as Google Wallet or Apple Wallet each have distinct APIs to load gift cards.

Ultimately, this fragmentation of APIs results in a poor user experience. For instance, a few issuers may support balance check or transaction history while many don’t, meaning a consumer buying or receiving a gift card may have to go to a store and try to redeem a potentially empty card to know whether it has funds or not.

What’s to be done about all this insecurity and lack of standard protocols?

An introduction to Bitcoin and the block chain

Understanding Bitcoin is key to understanding the value of moving financial assets such as gift cards onto the Bitcoin block chain.

I’ll start with addresses, then explain transactions, then the block chain.

Bitcoins are sent to and from Bitcoin addresses, which are essentially random numbers with no identifying information. — Satoshi Nakamoto


A fairly accurate metaphor for a single Bitcoin address is a transparent public lockbox.

It’s a lockbox, meaning a private key is required to unlock and move the bitcoins in it (to another public transparent lockbox)

It’s public and transparent, meaning anyone can see how many bitcoins are received or sent from it, and anyone with the public address may send bitcoins to it.

While it is possible to have a single Bitcoin address to send or receive money from, it is not desirable. Remember, the lockbox is transparent so anyone can just watch money coming in and money coming out. If for any reason your address is linked to your identity, someone would know everything about your related transactions, which may disclose such private information as your income and expenses. In other words, addresses are how you leak or control your privacy on Bitcoin.

The good news is that — unlike bank accounts and traditional lockboxes — one can generate as many Bitcoin addresses (and matching secret keys) as one wants, for free, on their own computer with just software.

To protect one’s privacy, the best practice is then to generate and use new addresses for each transaction. For instance, when sending bitcoins from one of your addresses to a merchant’s address, the unsent — also called unspent portion — of the bitcoins would be sent to a brand new address called a change address. Conversely, when receiving bitcoins, the receiver can protect its privacy by providing the sender with a brand new receiving address for each new transaction.

So with Bitcoin, one quickly ends up with thousands of addresses, each potentially with some bitcoins. Which is why we need wallets.


Wallets are best viewed as a software or service that provides secure access to the public addresses and corresponding private keys you own. Wallets hide the complexity of dealing with many addresses. Instead, they show the sum of all the unspent addresses that it has the private keys of.

For instance, the wallet below is comprised of 4 public addresses and corresponding private keys, each with an unspent amount of Bitcoin, which adds up to 12.8Ƀ.

Another function of wallets is to build transactions from addresses with unspent bitcoins.


To stick to the public lockbox metaphor, a Bitcoin transaction starts with requesting the recipients’ lockbox address, unlocking the lockbox and transferring the bitcoins to the recipient’s lockbox, like slipping an envelope into a locked mailbox.

The beauty of this push model is that the private key required to unlock the bitcoins at the recipient’s address does not have to be disclosed to the sender.

Bitcoin is fundamentally different and more secure than card payments. Cards are pull payments: you give your money lockbox key to the merchant. Bitcoin is push payments: you’re slipping money into the merchant’s own lockbox.

In practice, a transaction is built and signed by the recipient, and posted to the Bitcoin network to be verified and included in the chain of transaction blocks.

A Bitcoin transaction

The block chain, the chain of blocks of Bitcoin transactions, showing confirmed blocks and a new unconfirmed block

How do Gift Cards 2.0 on the block chain work?

Here at Gyft, we’re building gift cards 2.0 with the intention of creating a secure, instant and trustworthy gift card issuance, trading and redemption platform.

Gyft Block leverages several open protocols to issue gift card assets on the Bitcoin block chain.

We leverage the Bitcoin block chain itself:

  • To prevent unauthorized access to gift card assets with multi-signatures,
  • To ensure privacy with one-time addresses (hierarchical deterministic wallets),
  • To prevent double-spending of prepaid assets,
  • To enable atomic exchange of assets or chained exchange transactions.

In addition we leverage the following protocols:

  • Open Assets Protocol to issue and transfer gift card assets
  • BIP 70 with new BIP 70 Open Assets extensions for payment method discovery and open asset redemption at the point-of-sale.

How gift card asset issuance & transfer works

Since Bitcoin 0.9.0, there is an official way to attach an arbitrary string of 40 bytes of data to a Bitcoin transaction using a mechanism called OP_RETURN.

Attaching arbitrary data to Bitcoin transactions

While it doesn’t seem much, 40 bytes are plenty to add an entirely separate layer of meaning and value to existing Bitcoin transactions’ inputs & outputs.

If a particular transaction output is marked as an issuance transaction for a particular asset, a unique ID of this asset can be derived from the output, and it becomes possible to track subsequent transfers of this asset from address to address. For anyone who knows what to look for in the Bitcoin block chain, it is then possible to reconstruct the ledger of transfers of such asset between addresses, and compute up-to-date balances of each address for this asset.

For instance, we can record issuance and transfers of gift cards of a particular issuer.

To fit as much information as possible in 40-bytes, the Open Assets Protocol specifies efficient information encoding techniques for asset amounts transferred. Below is an example of an OP_RETURN data string encoding a transfer of 5000 units of a gift card asset.

How do we know that this is a gift card asset and that 5000 really means $50.00? The answer is in the asset definition file attached to the first issuance transaction of the particular asset (or just kept off-chain in a private database for privacy).

The Open Assets Protocol defines a basic set of parameters for assets. A number of additional fields have been added to cater to the unique requirements of store-issued prepaid cards, a.k.a. gift cards.

Below is a sample gift card asset definition file:

"asset_ids": [ "AJFBvf2FdGiGmia2MFkMc357ps8RTLPJYu"],
"name_short": "USD",
"name": "Truth Coffee Gift Card",
"contract_url": "",
"issuer": "Truth Coffee co",
"country": "US",
"state": "CA",
"cash_redemption": {
"maximum": 500
"description": "Truth Coffee Gift Card is redeemable at any Truth Coffee location for products and services.",
"description_mime": "text/x-markdown; charset=UTF-8",
"type": "storeCard",
"divisibility": 2,
"link_to_website": true,
"icon_url": "",
"image_url": "",
"version": "1.0"

How gift card terms and regulations are enforced

Gift cards fall under prepaid regulations, which vary from jurisdiction to juridisdiction and terms vary from merchant to merchant, so it is important to provide a rich framework to programmatically enforce these terms & regulations.

In the U.S., gift cards are regulated by the federal CARD Act, state regulations and by FinCEN’s Prepaid Access. The federal and state rules mainly focus on fees, while Prepaid Access mandates reporting and customer information collection for certain kinds of prepaid programs.

In this document, we’ll focus on Prepaid Access.

Prepaid Access for instance exempts programs that provide “closed loop prepaid access to funds not to exceed $2,000 maximum value that can be associated with a prepaid access device or vehicle on any day.” A closed loop program is further defined as “prepaid access to funds or the value of funds that can be used only for goods or services in transactions involving a defined merchant or location (or set of locations), such as a specific retailer or retail chain, a college campus, or a subway system.” Unfortunately, transferability of prepaid access within users of the programs challenges the exemption.

To minimize compliance costs, in particular to avoid MSB registration and AML requirements, it is necessary for an issuer of gift card assets on the block chain to ensure that:

  • daily spending limits of $2,000, or conservatively $1,000 daily, are enforced.
  • transfer among users after initial purchase is made impossible (FinCEN does exempt transfer through secondary markets/exchange so this is a grey area).

A pratical way to achieve this is to issue cards as multi-signature open asset wallets where the co-signer is the asset issuer or a third party trusted by both the issuer and the cardholder, called the program manager. In the Bitcoin community, this model is sometimes called third-party oracle.

The co-signing program manager is trusted to enforce the terms & regulations of the assets, including daily spending limits and unauthorized transfers, by rejecting any non-compliant transactions.

Effectively, only transactions authorized by both the user and the program manager can be executed. Such a model can be easily integrated in a variety of wallet providers.

A co-signing service for gift card assets must therefore support a number of key technologies and capabilities, including but not limited:

  • asset-aware wallets maintaining transaction history and balances in each asset,
  • real-time enforcement of smart executable policies, whether machine-read from the gift asset definition file or pulled from a knowledge base of jurisdiction-specific rules,
  • keychain management and protection,
  • together with an always available Bitcoin-aware service layer. provides such capabilities and accordingly is a solid foundation to build a co-signing service for gift card assets, or any other financial asset with similar requirements.


It’s not free to issue and transfer assets on the Bitcoin block chain. There are tiny Bitcoin costs.

In each transaction output, we’ll transfer a minimum or dust amount of Bitcoin equal to 0.00000546Ƀ, about 0.001365$ at $250/Ƀ. Each transaction, including the original prepaid asset issuance transaction, and subsequent transfer transaction will involve one or two outputs, the second being the change address.

For instance, assuming a $25 gift card, redeemed in full in two transactions. The cost break down looks like this:

  • Issuance transaction 0 for $25 prepaid card: 0.00001Ƀ estimated fee + 0.00000546Ƀ dust temporarily immobilized in output 1 of transaction 0 or TX0–1
  • First redemption transaction 1 with $20 redeemed and $5 remaining: 0.00001Ƀ estimated fee+ 0.00000546Ƀ for the change output TX1–2 carrying the remaining $5 value. Dust in Tx0–1 output is reused and becomes TX1–1.
  • Second and last redemption transaction 2: 0.00001Ƀ estimated fee. Dust in TX1–1 is reused and becomes Tx2–1.

Assuming dust is only temporarily immobilized, eventually returns to the issuer, and therefore can be ignored as a cost, we have:

Total: 0.00004096Ƀ transaction fees, which is ~0.96 cent per card for its full lifecycle at current Bitcoin price.

In addition to Bitcoin costs, there are wallet & program manager costs. Still, for a level of security fundamentally superior to cards (including bank-issued open loop gift cards), this is cheaper than the 2.5%+$.20 bank card transaction fee, or $1.5 per plastic gift card.

Conclusion: benefits of gift card assets on the block chain

Reduced gift card issuance costs with a level of security superior to bank cards will have profound effects on the payment industry. It is difficult to envision all the merchant and consumers benefits it may enable.

Beyond gift cards, merchants now have the tools to print their own digital currency, which will likely openly trade on secondary markets. They will use it to reward their best customers and attract new ones, to bolster their cash or practice better yield management. Merchants can also publish offers that target customers with particular assets as assets may become a way for consumers to design personas.

For consumers, it means more flexibility, usability and value. Prepaid cards can be bought or reloadable in any amount, instead of fixed denominations. Balance can be reliabily checked from any merchant in the world. They can be easily added up in one balance and one transaction history, easily bought & sold instantly from issuing merchants or on secondary marketplaces with/for any other asset. Virtually any asset can be converted on-the-fly to any asset acceptable by a merchant.

Ultimately, intelligent wallets will be able to connect to marketplaces, identify arbitrage opportunites and perform in the background complex chains of trade that maximizes the consumer’s purchasing power without compromising their privacy or control.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>