The team at tune.fm is proud to present the 3rd and final iteration of the JAM token on the Hedera Token Service (HTS). Our mission has remained the same, to democratize music for all. Our vision to achieve this has always been the tokenization of streaming through real-time micropayments. We chose Hedera to realize this vision since it has the fastest throughput, highest security, lowest fees.

Our goal has always been to utilize the Hedera services to their fullest extent. Previously, we reached our goal through smart contracts on the Hedera Smart Contract Service and minting the first token (JAM) ever created using Hedera-based smart contracts, analogous to an ERC-20 token on Ethereum.

While this was a groundbreaking achievement, we also faced headwinds associated with smart contracts and idiosyncrasies running such a model on Hedera, a fundamentally different architecture from blockchain. We doubled down on smart contracts to fix these issues and created an even more unique architecture utilizing sharded smart contracts, enabling us to scale our token on Hedera without hindrances. I've detailed this journey in a lengthy blog post titled "Scaling Smart Contracts on Hedera." If you enjoy deep dives on building on distributed systems, this is worth reading to get up to speed.

Through this exercise, we realized that even though we "fixed" a lot of the issues fettering our smart contracts, we never really escaped their inherent limitations since we were still using them. At the time, this was our only choice because there was no way to mint a decentralized token on Hedera without smart contracts until the Hedera Token Service (HTS).

It's worth briefly surveying the downsides and tradeoffs with smart contracts to understand the benefits of what something like HTS provides. This will make it clear why HTS is the ultimate service for the JAM token and more closely aligned with tune.fm's original vision than any other previous iteration.

First off, smart contracts are inherently slow, expensive, and inefficient. They are slow and costly as a result of being inefficient. One might ask, why is this? Smart contracts run on the Ethereum Virtual Machine (EVM), a Turing-complete virtual environment running on nodes. The programming language, Solidity, is employed to write smart contracts that can run the programmatic logic necessary to achieve their goal. While this has upsides, it also comes with tradeoffs.

Because there are very few limitations on what one can potentially program in a distributed environment, there are potential security vulnerabilities and memory leaks from writing imperfect code. Developers pay for the computing resources they use on Ethereum with something called "Gas." Hypothetically, an infinite loop in a smart contract (written in Solidity) could end up costing unlimited Gas until terminated. This is the reason for smart contract audits to make sure the code deployed is entirely bug-free since it is immutable.

Because there is so much more going on to run a smart contract in Solidity on the EVM, it takes far more network resources to compute this logic across all nodes and save the state of each account in the smart contracts, thus, it is far more expensive. Not only are the smart contracts costly to run, but they also operate a lot more slowly since they are abstracted away from the core network or blockchain. Because of this disconnect, it is an inefficient use of computing resources to run smart contract-based tokens for any high-usage decentralized application.

This inherent inefficiency is misaligned with what we were trying to do: to utilize a native token for micropayments. With the downsides of smart contracts being much higher fees and lower throughput (speed), we got farther and farther away from the original micropayments use-case since micropayments are not possible with high fees and low throughput. While we still retained some of the foundational benefits of Hedera, like security, stability, and governance, we missed out on the core benefits that attracted us in the first place. We had to implement creative 'hacky' ways to get around these limitations, such as 'bulk transfer' methods running hourly to reduce fees and 'parent-child sharding' to get around state limits. While we remain proud of our technical accomplishments, we were trading away product experience to "make it work" and getting farther away from the original vision of real-time micropayments.

Upon completing our implementation of scalable sharded smart contract tokens on Hedera, the knight in shining armor (HTS) came to save us. We would no longer have to compromise our original vision and instead utilize HTS to create a native JAM token running directly on the Hedera network sans smart contracts. JAM now operates with the same high fidelity as HBAR with equally low fees ($0.001 per transaction) and super high throughput (10k+ txn/s). We can create our own HBAR-equivalent token, but also utilize our unique token economics, distribution, and pricing models. All of this is now possible without the overhead of smart contracts since the native token is directly transacting on the network "on-chain". One of the added benefits is automatic compatibility out of the box with exchanges that support HBAR and the latest HTS protocol. Listing JAM on several exchanges (more news to come) will be as simple as enabling our token without building costly custom integrations.

Now that we can take full advantage of all the benefits of Hedera with our own native JAM token, we can finally achieve our mission of decentralized real-time micropayments for music. Transactions worth fractions of a penny for just a few seconds of music streamed can now be processed in real-time as they are created, so when the music gets played, the artist gets paid.