Hello Steemians, the SMT testnet has now been running for almost two weeks and SMTs have been enabled since last Monday! That means that, since that time, developers have been able to create their very own SMTs. In fact, 
The SMT whitepaper is still the most authoritative reference for understanding what SMTs can do, but that is far too technical for most people. For those people, the best way to understand the capabilities of an SMT are to understand the capabilities of STEEM. We have often said that the SMT protocol would give anyone the ability to launch their own STEEM-like token, and that was based on a very technical reality.
Thanks to the intelligent design of Steem, it was fairly straightforward to take all of the features that STEEM already had and make them available to SMT creators. In a very real sense, when you launch an SMT it is like you are getting a “Do Over” with the STEEM token.
Because STEEM was designed to have token emissions (i.e. inflation) you can set a token emissions rate for your SMT. That can be 10%, 23%, 1423% or 0%. But STEEM’s token emissions rate also changes over time based on a graph that was specified during a hardfork. So SMTs have that ability too.
If you can describe how you want your token emissions rate to change over time in a mathematical formula, you can specify that formula when you are creating your SMT and the Steem blockchain will faithfully execute that code. Of course, since that formula is locked in consensus, you can’t change it once the SMT has been launched. That is one of the many reasons developers should thoroughly test their SMT before finalizing its design.
Because STEEM was designed to have emissions directed at specific accounts, like the Rewards Pool, and distributed to those with vesting STEEM, SMTs have that capability too. You can set a token emissions rate of 10% (or any other number) and direct those emissions to the Rewards Pool for distribution via Proof-of-Brain. You can set a token emissions rate of 35% (or any other number) and have that distributed amongst those who have your SMT powered up.
In total there are 8 “special places” to which the SMT creator can specify token emissions be directed. These are:
#define SMT_DESTINATION_PREFIX "$"
#define SMT_DESTINATION_ACCOUNT_PREFIX SMT_DESTINATION_PREFIX "!"
#define SMT_DESTINATION_VESTING_SUFFIX ".vesting"
#define SMT_DESTINATION_FROM unit_target_type( SMT_DESTINATION_PREFIX "from" )
#define SMT_DESTINATION_FROM_VESTING unit_target_type( SMT_DESTINATION_PREFIX "from" SMT_DESTINATION_VESTING_SUFFIX )
#define SMT_DESTINATION_MARKET_MAKER unit_target_type( SMT_DESTINATION_PREFIX "market_maker" )
#define SMT_DESTINATION_REWARDS unit_target_type( SMT_DESTINATION_PREFIX "rewards" )
#define SMT_DESTINATION_VESTING unit_target_type( SMT_DESTINATION_PREFIX "vesting" )
As you can see, by customizing just a few SMT features, you can create an infinite variety of tokens. That complexity, and how it impacts other parts of the blockchain, was the really difficult part of implementing SMTs. The benefit of the intelligent design of Steem is that we can rely on a huge amount of preexisting code that has already been tested for 3 years: the STEEM code. The reason why SMTs can have as many features as they do is because STEEM has so many features, and SMTs essentially leverage that exact same code.
While most of the features of STEEM that have been included within SMTs have customizable parameters, one that does not is the Power Down. The benefit of the design approach we took with respect to SMTs is that it enables us to “piggyback” off the security and stability of existing work. With respect to SMT vesting, that enabled us to add a vesting feature relatively quickly. Unfortunately, the work required to enable SMT creators to adjust the vesting parameters would have led to significant delays and we do not think the value added would justify the additional delay. For that reason, SMTs launched with v1 will have 13 week power downs, just like Steem Power.
None of this is to say that any feature cannot be added to SMTs in the future. All of the ICO code, for example, is brand new, since STEEM never ICOed. The decision to develop any code is always the result of a cost-benefit analysis. We want to offer the most secure, stable, and powerful software possible, and these goals often conflict with one another. Additional features which might be quite powerful, can also increase complexity which can negatively impact security and stability.
While SMT v1 is a replication of the STEEM feature set with customizable parameters, we created the SMT protocol specifically so that new features can be added through subsequent hardforks; including features that do not exist for STEEM. V1 consists of those features that give the widest range of capabilities, without introducing too much risk into the ecosystem.
Thanks to Steem’s 3-second fee-less transfers, any capability that does not yet exist in SMTs can be replicated using an off-chain bot. This combination of features means that under the least ideal circumstances SMTs are still a great option for a developer who is looking to integrate a powerful token into their web application, and under many circumstances SMTs will be far and away the best option.
These are just a few of the features of SMTs. We plan to explore more in future posts, so be sure to follow 
The Steemit Team