A crypto token that passes the Howey Test is deemed a Security token. Security tokens are designed to represent complete or fractional ownership in an asset. While utility tokens have no limitations on who can send or receive the token, security tokens are subject to many restrictions based on identity and jurisdiction.

In the same way that the ERC20 token standard helped to create a boom in utility tokens, a security token standard would help drive the adoption of security tokens.

In this article, let’s look at the current state of security token standards in the Ethereum ecosystem and each of their approaches to build a self-regulatory governance mechanism for these tokens.

Web applications today are built iteratively. With continuous delivery, developers release hotfixes and new features hundreds of times a day. We upgrade our software all the time with little ceremony.

Upgradability is something that you don’t truly appreciate - until you’ve written smart contracts. Why? Because smart contracts are immutable - it’s not possible to upgrade the source code of an already deployed contract. In this aspect, developing smart contracts is closer to hardware programming than web development.

At the same time, decentralized applications and smart contracts are a new and highly experimental space. There are constant changes in the security landscape and the cost of failure are in the high tens or hundreds of millions of dollars. Code will need to be changed if errors are discovered or if improvements need to be made. It is no good to discover a bug, but have no way to deal with it.

As software engineers, we seek to build software systems that is modular and supports upgradable components. To handle the large space of smart contract attack vectors, we need a mechanism through which we can safely and securely upgrade our smart contracts. This is especially true when you build complex, perpetual contract systems instead of one-time token sale contracts.

In traditional software development, security vulnerabilities can be fixed by patching. When there’s a bug in your system, you can write a fix, deploy it, and prevent future exploits of that specific bug. Patches are frequent and easy.

Patching security vulnerabilities of decentralized applications on the Ethereum blockchain is not so straightforward. Due to the immutable nature of smart contracts, it’s difficult (and sometimes impossible) to upgrade already deployed contracts.

On the other hand, the potential losses of smart contract hacks can be exorbitant, with losses of more than US$70M for the DAO Hack and US$200M for the 2nd Parity Hack. Considering both the difficulty of upgrading contracts and high exploit risk, smart contract developers need to be vigilant and apply defensive programming techniques when designing smart contracts to prevent vulnerabilities in the initial design.

In this article, let’s look at common security vulnerabilities in Solidity smart contracts and how to mitigate them.

Learn about the most popular projects and product offerings in the Serverless ecosystem today! (Last updated 19 June 2018.)

An API without proper documentation is no better than no API at all. Having a great developer portal is critical part of your API’s developer experience and is instrumental in driving adoption.

The user experience of a developer portal, the completeness of the API documentation, the ease with which you can search for the right solution for their needs, and the speed at which developers can start calling your endpoints are all fundamental to the success of an API product.

This guide documents best practices to having a great API Developer Portal.

You’re building an API.

You develop a backend service with a few endpoints and deploy it to production. You publish several official language-specific API clients as well as an API documentation. The day ends on a happy note.

The following day, a new feature is being added the API. You have to:

• Update the server implementation to support the new feature.
• Update all client libraries (one SDK for each supported platform and language.)
• Update the documentation.
• All the above must be consistent with each other.
• Also, the frontend team is blocked until your backend API is complete.

You let out a heavy sigh.

On January 2018, AWS Lambda released official support for the Go language.

In this guide, you’ll learn how to get started with building Go applications on AWS Lambda with the Serverless framework. This brief guide consists of two parts: a brief section on the Go language and a hands-on section where you’ll build a Serverless Go CRUD API.

The final application is available on Github. Just hit deploy!

First, let’s have a quick look as to how software was traditionally built.

Web applications are deployed on web servers running on physical machines. As a software developer, you needed to to be aware of the intricacies of the server that runs your software.

To get your application running on the server, you had to spend hours downloading, compiling, installing, configuring, and connecting all sorts of components. The OS of your machines need to be constantly upgraded and patched for security vulnerabilities. For servers to run well at high load they must also be provisioned, load-balanced, configured, patched, and maintained.

In short, managing servers is a time-consuming task which often requires dedicated and experienced systems operations personnel.

In this article, learn about the distributed saga pattern, how it helps ensure correctness & consistency in microservices, and how you can use AWS Step Functions as a Saga Execution Coordinator.

This is an aspirational transcript of a talk I gave on ‘Sagas with Step Functions’ for an AWS meetup.

Let’s learn how we can use JSON Web Tokens to add authentication and authorization to our serverless functions! We will be using the Serverless framework.

The sample application is available on GitHub.