Merry Christmas everyone 🎅

The winners of our Christmas lucky draw are:

- Bitcoin: bc1qrg0y2z2896hvlgdaa727jmwl9zx2tp28p97yfk

- Ethereum: 0x5696462DFf0D6C24b53772374Aa8bCA21a01F179

We already sent the prize to the lucky winners 🎁

Continue reading...

Today we are excited to release our solution to conveniently send cryptocurrency to any email address.

To start sending bitcoin to any email address, simply head to . On this page, you can choose the amount and crypto you want to send, together with the other person’s email address and your signature and email. We use this information to keep you up-to-date with the status of your payment by email.

After filling out your details and clicking “Review Payment”, you can review the information you provided. On this page, you can find the secret unlock code that we will email to the other person.

After confirming your details, LockerX starts creating your smart contract and locking it so that only the other person can unlock it using their secret unlock code. When the contract is locked, you’re asked to send your bitcoin payment to it, at this point only the person with the secret unlock code can withdraw the funds. After you deposited your crypto, LockerX emails the other person to inform them of your payment.

The other person simply has to visit the link LockerX sends them to claim their payment.

After filling out and reviewing their information, they will receive the payment to their wallet. That’s it!

If you noticed you made a mistake, for example you sent the wrong amount or used the wrong email address, you can easily cancel the payment and send the crypto back to your account.

If you want to learn more about Flash Locker and see all available options, visit the Flash Locker documentation page .

How Flash Locker works

Flash Locker works by tokenizing your Bitcoins on the Stellar blockchain. When you deposit your Bitcoin into the Flash Locker, we issue a token on Stellar for the equivalent amount of Bitcoin, this token can be redeemed for the same amount of Bitcoin. The Flash Locker Stellar account is locked so that only users with the secret unlock token can use it. In more technical terms, we set the signer of the Flash Locker account to the hash of the unlock token.

Continue reading...

Today we introduce a new service to bridge cryptocurrencies to the Stellar network.

As an anchor, we will keep your cryptocurrencies safe and, at the same time, we will issue you an equal amount of that cryptocurrency token that you can use on Stellar, taking advantage of Stellar fast and cheap transactions.

We like the transparency and auditability that blockchains provide, for this reason we decided to link every deposit and withdrawal by storing their hash in the Stellar transaction.

For example, this transaction that issues 0.1 Bitcoin Cash contains a memo that links the transaction on Stellar with the transaction on the Bitcoin network . Because of this, the circulating supply of our tokens can be independently audited by everyone, ensuring everyone can trust it.

At launch, we support the following cryptocurrencies, with plans to expand to include more cryptocurrencies in the future:

  • Bitcoin
  • Bitcoin Cash
  • Litecoin
  • Dash
  • ZCash

Are my funds safe?

Yes, your funds are completely safe and can be redeemed at any time. We store your cryptocurrencies in an industry-leading multi-signature wallet service.

All our tokens are backed 1-to-1 by cryptocurrencies, you can check this by monitoring our issuing account . Every transaction contains the hash of the deposit transaction to link the two transactions together.

Getting started

You can get started by visiting , we provide an easy-to-use interface to deposit and withdraw funds to and from the Stellar network.

Continue reading...

One question that often comes up when building smart contracts is how to attach documents to them. For non-technical users, attaching documents to payments is a feature that is taken for granted. After all, if you look at your email inbox you will almost surely find an invoice attached to each of your payment confirmations.

Attaching documents to blockchain transaction is not simple, the main problem is that documents (especially PDF documents) can be huge compared to the size of a transaction sent to the network. Blockchains are designed to store transactions that are a few bytes in size, not documents that can weigh several megabytes!

Another issue is that the data on the blockchain is visible to everyone, this is great from a transparency point of view but documents may contain sensitive information that we are not willing to share with the world. This poses an additional challenge since we may want to prove the existence of a document (for example, an itemized invoice) while at the same time keeping the content of the document private, to be shared only with trusted parties.

You can use a service like LockerX to create smart-contract transactions that also include document attachments, without being an expert yourself. In the next section, we will describe how we implemented document attachments in LockerX.

Hash it!

As mentioned in the previous section, the challenge in attaching data to blockchain transactions is the limited amount of storage space and the need to keep documents private. Luckily, both problems can be solved with the same tool: hash functions!

Hash functions are mathematical functions that map data of different sizes (for example documents) to values of the same size. Cryptographic hash functions are hash functions with some additional guarantees:

  • Given a hash value, it’s infeasible to generate a message that produces that hash value,
  • It’s infeasible to produce two different messages that have the same hash value, that is the function is collision-resistant,
  • A small change to the message produces a completely different hash value.

Link your document

Computing the hash of documents it’s not enough, we also need to make sure this data is included on the distributed ledger. Storing the hash on the ledger is important because it proves that the data itself existed at the time the ledger was computed:

  • Blockchain ledgers are immutable. Storing a hash value in a ledger is enough to prove that we had that value at the time since it is impossible to retroactively change a ledger.
  • The document was not altered in any way. Since any small change to a document produces a completely different hash value, then if the document produces the same hash value that is stored on the ledger it means it was not modified in any way. Additionally, since it’s infeasible to have two documents produce the same hash value, then the document must be the same as the original document.

One last question is where to store the document itself since only its hash is stored on the ledger. The answer to that depends on your use case and how private your document is. Publicly available documents can be stored unencrypted on distributed file systems such as IPFS, while private documents should be stored encrypted and only shared with trusted parties.

On LockerX, documents are stored securely by us and are shared only with the parties you give access to.

Why not give it a try?

In this post, we described a strategy to use blockchain to prove the existence of a document at a given point of time. If this sounds exciting to you, make sure to check a live version of these ideas on LockerX.

Continue reading...

Every LockerX user has available a Stellar wallet they can use to create smart contracts.

To access your wallet (identified by its public key), you need to use the corresponding secret key that is known only to you. Usually, the secret key is safely stored by the wallet software you use. Knowing an account’s secret key gives complete control over it, it is then clear that the secret key should never be shared with anyone and should be kept as safe as possible.

Every time you create a smart contract using LockerX, we will create a new Stellar account on the network for the smart contract. This means that we have to manage hundreds or thousands of secret keys, and make sure they are safe!

The basics of keeping keys secure are:

  • Never transmit the keys over the network. Ideally, the unencrypted keys should never leave the process memory.
  • Encrypt the keys before storing them in the database.
  • Encrypt the database data at rest.

When we started this project, we decided to use Google Cloud because of its security-focused features and the simplicity of the platform. The Stellar secret keys are encrypted using envelope encryption (described in the next section), using keys managed by Google Cloud KMS and stored in Google Cloud SQL, which is encrypted at rest by default. Knowing how keys are used is an important component of secret key management, Google Cloud provides audit logs that can be used to understand which services have been using KMS keys for encryption and decryption. This feature allows us to monitor the infrastructure to detect unauthorized access to the secret keys.

Envelope encryption

Envelope encryption is a technique where one key is encrypted using another key. One key, the Data Encryption Key (DEK), is used to encrypt the data itself. The DEK is then encrypted using a Key Encryption Key (KEK).

The DEK is generated locally and is stored (encrypted) together with the Stellar key it encrypts. DEKs are used to encrypt only one Stellar key and never reused, for this reason, they don’t need to be rotated.

We use Cloud KMS to centrally manage and store KEKs. KEKs are regularly rotated. KEKs are never transmitted over the network to our application, instead, we use the Cloud KMS API to encrypt and decrypt the DEKs.

The process to create and encrypt a Stellar key is:

  • Generate a random Stellar key, e.g. using KeyPair.random(). This will be our data.
  • Generate a symmetric encryption key, this is the DEK.
  • Encrypt the Stellar key using the DEK.
  • Encrypt the DEK using KMS.
  • Store the encrypted Stellar key and the encrypted DEK in the SQL database.

When we need to retrieve the Stellar key:

  • Retrieve the encrypted Stellar key and the encrypted DEK from the database.
  • Decrypt the DEK using KMS.
  • Decrypt the Stellar key using the DEK.
  • Generate the KeyPair from the Stellar key.

The image below shows how the DEK is used to encrypt the Stellar key and is then encrypted using the KEK managed by the KMS. The encrypted Stellar key and DEK are then saved to Cloud SQL.

Signing transactions

Secret keys should never be transmitted over the network, this means that transactions can’t be signed by individual services and instead have to be signed by a centralized service. This is the job of the signing service. The signing service is responsible for:

  • Creating new public/secret key pairs.
  • Signing data on behalf of other services.

All other services that need to sign data to submit a transaction to the network will need to make an API call to the signing service.

As an example, the service responsible for creating smart contracts requests the signing service to generate a new account id and then store the account id together with the smart contract.

When it’s time to sign and submit the transaction, the smart contract service requests the signing service to sign the transaction using the contract key, and then sends the signed transaction to the network.


In this post, we discussed how we store Stellar secret keys at LockerX. The intent of this post is to be a starting point for developers looking to store users' secret keys securely. Storing secret keys should be done only when strictly necessary since it makes your application a much nicer target for attackers (it’s the ultimate bug bounty program). When possible, projects should delegate transaction signing to the user wallet.

Continue reading...

When Bitcoin was presented in 2008 it showed that it was possible to have a decentralized and trustless currency. In the following decade we witnessed the rise of many different cryptocurrencies, each one with a different goal and philosophy.

While cryptocurrencies can differ greatly from each other, they can be divided into four groups:

  • Cryptocurrencies/Payment Tokens: these tokens have no inherent value and are used as a medium of exchange on the network. Payment tokens are usually used to pay for network fees. Stellar Lumens are an example of cryptocurrency.
  • Stablecoins: these are tokens that are backed 1:1 by another asset, usually a fiat currency held in a deposit account. Users trust the stablecoin issuer to exchange back the token for fiat currency. Coinbase USDC is an example of stablecoin, you can always redeem 1 USDC for 1$.
  • Utility Tokens: these tokens are used to pay for a service. The Basic Attention Token (BAT) is a utility token used to obtain advertising-related services and it’s exchanged between users, publishers, and advertisers.
  • Security Tokens: these tokens represent ownership of an asset, for example, a company or a property. This type of tokens is less common because securities are regulated in most countries and early-stage companies (the most likely candidates for Initial Coin Offerings) don’t have the resources to comply with all the regulations.

Originally new tokens were created by forking an existing project and changing the protocol to meet the requirements. Ethereum revolutionized this process by letting users program smart contracts that behaved like currencies, later it was formalized in the ERC20 standard.

The Stellar Network supports non-native assets directly, letting users issue and exchange their different assets. In this blog post we begin by giving a high-level overview of Stellar Assets, compare them with ERC20 tokens, and finally delve into the technical details.

Native and Credit Assets

There are two types of assets on the Stellar network: the native asset and credit assets. The native asset, known as Stellar Lumens (or XLM), is the asset that’s used to pay transaction fees and as a base reserve for the account. The supply of Lumens increases by 1% per year from inflation.

Credit assets have no inherent value, they can’t be used to pay for transaction fees, instead, their value is given by the trust users have on the asset issuer. Assets are used mainly to issue stablecoins by anchors , but there are projects that use them for security and utility tokens. The supply of credit assets is up to the issuer account. A fixed supply can be created by distributing the initial supply amount and then locking the issuer account.

Since credit assets are based on the user trust of an issuer, users have to explicitly add a trustline to an issuer before they can use an asset. Usually, this is done in a few clicks from the wallet software.

Credit assets have additional features compared to Lumens, making them suitable for more complex use-cases. As we discussed previously, securities are heavily regulated and for this reason, security tokens should only be held by authorized users. Stellar includes a mechanism for issuers of security tokens to authorize who can hold their assets, making it possible to comply with Securities and KYC/AML regulations. Issuers can also freeze the assets held by another account.

The difference with Ethereum ERC20 Tokens

Ethereum is the most popular platform for ICOs . ICO on Ethereum involves creating an Ethereum smart contract (not to be confused with a Stellar Smart contract ) that follows the ERC20 standard for tokens. This standard defines a common API for a smart contract that enables users and issuers to:

  • Retrieve basic information about the token (Name, symbol, and total circulating supply)
  • Get an account balance
  • Transfer the token between accounts
  • Set an allowance (allow an account to withdraw a predefined amount)

The ERC20 standard allowed the Ethereum ecosystem to grow by enabling wallets and exchanges to support a wide range of tokens.

Stellar assets are different because they are backed directly into the Stellar protocol. This is important because it means that assets are supported by all wallets, right from the beginning. Users can enable support for the most common assets on the network with only a few clicks. Non-native assets transactions are equal to Lumens transactions in everything and are handled in the same way by the network validators, thus they are as secure as native transactions. Finally, because they are part of the protocol, all assets are improved by updates that add new functionality or that improve security (without the headache caused by upgrading smart contracts ).

Technical Overview

At the core of Stellar assets, there are trustlines. Trustlines are stored on the ledger, you can find them on Stellar Expert or, if you have access to stellar-core, you can explore the trustlines table.

A trustline contains the following information:

  • AccountId: the account this trustline refers to
  • Asset: the asset code and issuer of the trustline
  • Limit: the limit for which the account trusts the issuing account
  • Balance: the account current balance, in units of the asset
  • Flags: contains the trustline flags, for example, Authorize
  • Buying Liabilities: this equals to the total amount the account is offering to buy. Buying liabilities plus balance must be less than the account limit, if you try to create a new offer that would put you above the limit you will receive a trustline full error
  • Selling Liabilities: this equals to the total amount the account is offering to sell. Selling liabilities must be less than the account balance, otherwise, you won’t be able to create a new sell offer

Anyone can issue assets on Stellar, all you have to do is pick an asset code and get users to trust you! After users have added the asset code and issuer account to their trustline, they can start receiving payments from the issuer. As we mentioned earlier, sometimes an issuer may want to restrict who can hold its asset. To do this, it must:

  1. Submit a transaction to set the issuer account AUTHORIZATION REQUIRED flag
  2. Wait for users to add a trustline, users won’t be able to receive the asset yet since they are not authorized
  3. Authorize each individual user account by setting the trustline authorized flag to true

Bonus: Allowance in Stellar

As we have seen in the previous section, ERC20 tokens let users set an allowance and let another account withdraw a predefined amount. In Stellar, this behavior is let to the users and not the asset issuer. It is easy to create an allowance thanks to Stellar support for multi-signature accounts. If Alice wants to let Bob withdraw up to 100 XLM, all they have to do is to create a new account with 100 XLM in it and add Bob to the account signers. When Alice wants to increase the allowance, they will simply transfer more funds into the shared account. Likewise, Bob will transfer funds from the shared account to their account.

Continue reading...

With the term smart contracts we usually define computer programs that are executed by a distributed computer. This is the case, for example, of Ethereum smart contracts, built using the Solidity programming language. While targeting a Turing-complete virtual machine empowers programmers to build exceptionally complex contracts, it also increases the possibility of bugs that result in the loss of millions of dollars .

Stellar takes a different approach to smart contracts. Contracts are built by composing transactions together and taking advantage of the following features:

  • Multisignature, Thresholds, and Key Weights We can specify what signature are required to change the state of an account
  • Batching Either all operations in a transaction succeed or none of them does
  • Sequence Transactions are processed only if their sequence number is increasing
  • Time Bounds Limit the time frame within which transactions can be accepted by the Stellar Network

While this limits what it’s possible to build on top of Stellar smart contracts, it also results in contracts that are more safe from unexpected bugs. As we will see later in this post, it is possible to model smart contracts as state machines, resulting in contracts that are easier to verify and test.

Continue reading...

Stellar Protocol version 10 is going to be released soon . This release brings several changes to the distributed exchange and introduces a new BumpSequenceOperation.

The bump sequence has been in the work since last October and it was added to simplify writing complex Stellar smart contract workflows. The operation allows bumping forward the sequence number of the source account of the operation. If the sequence number specified in the bump sequence operation is less than the account current sequence number, then the account sequence number will be unaffected. In practice, it means Stellar now includes a no-op operation.

Let’s now look at two use cases for the bump sequence operation.

Invalidating Transactions

The first use case for the bump sequence operation is to invalidate previously disseminated transactions that have not yet been submitted to the network (for example because they have a minimum time-bound). A Stellar transaction to be valid has to have a sequence number that is the successor of the current account sequence number. Increasing the account sequence number will make the network reject all transactions submitted that have a sequence number less than the new one.

In the following diagram, we see two possible workflows for a Stellar account: at the top every transaction increases the sequence number by one to n+t, while at the bottom a single transaction bumps the sequence number to n+k, where n+k > n+t.

Normal Workflow vs Transaction Invalidation

As a no-op

As we previously discussed, using a target sequence number that is less than the current one will result in a transaction that does not change the account sequence number. This is what is called a no-op .

This use of the bump sequence operation can be used to add a specific account to the required list of signers of a transaction.

Let’s consider an example smart contract C where we have two pre-authorized transactions: one to merge C into A (call it #1), and one to merge C into B (call it #2). The weights are as follows:

  • C: 0
  • A: 1
  • B: 1
  • #1: 1
  • #2: 1

and the thresholds are set to 2. With the current setup, A could send transaction #2 to the network, while we want to transaction #1 to be submitted only by A, and transaction #2 only by B. Let’s ignore that it does not make economic sense for B to send #1 and for A to send #2.

If we change the definition of transaction #1 to:

Transaction #1

source: C
sequence: seqnum

  • Merge C into A
  • Bump Sequence to 0 (Source: A)

and transaction #2 to:

Transaction #2

source: C
sequence: seqnum

  • Merge C into B
  • Bump Sequence to 0 (Source: B)

then transaction #1 can only be sent to the network by A and transaction #2 by B. Mission accomplished!


In this post, we looked at one of the new features in version 10 of the Stellar Protocol. While the bump sequence operation does not introduce any new feature, it makes it more convenient to build smart contracts with Stellar.

Continue reading...