Feature Story

TurtleCoin­® v2 Overview

In the early days, at least two forevers ago, we blew the dust off a legacy Bytecoin codebase and launched a coin using just enough special sauce to call TurtleCoin our own, all on a whim. As a new network, there were the usual struggles, like when ASIC for CryptoNote emerged, or when we found a pretty serious RPC issue in Simplewallet.

As our team and their contributions grew, we eventually found ourselves in a new codebase, rock solid, but still carrying the scars of our past.

Fast forward to now, we are 3 million blocks wiser, our team is many lines of code more experienced, and as we have chiseled our way through, we made a list of a some areas where we can do better. Taking a step back, the last few years have shown us that we are reaching the limit of our current software, and the time is now for us to think radically different and put something new on the table. It is time to build something of our own.

With great respect and thanks to the CryptoNote family, Forknote, Bytecoin, and those who enabled us to get where we are now, we humbly begin our own path and embark on a new journey. What we produce next will be from scratch, written by us, exactly how we have always wanted it.

TurtleCoin v2 is the future, and we are excited to share it with you!

– RockSteady

The Goal

We aim to redesign TurtleCoin from the ground up to avoid the mistakes of the past while putting an eye to the future state of the network. This is accomplished by replacing traditional Proof of Work (PoW) based mechanisms with a round-based hybrid Proof of Stake (PoS)/PoW model. We’re going to be talking about some of the fundamentals required in this model so buckle your seat belt and be ready for a ride. Be warned, there’s a bit of math below.

Proof of Work

The traditional approach to cryptocurrency networks is to deploy a PoW model such that miners perform endless repetitive hashing of block data searching for a hash that meets a set difficulty. The miner is rewarded for burning fossil fuels via a specially constructed transaction (the “coinbase transaction”) that allows the miner to create new funds as a result of mining that block.

Proof of Stake

PoS deviates from the PoW consensus model in that PoW is typically no longer performed, instead passing the torch to block producers (the “producers”) whose work is then validated by the block validators (the “validators”). These parties are typically elected via users staking, or otherwise backing, their preferred candidates for those roles. Selection of producers and validators typically takes place via an election mechanism as part of the consensus rules.

Our Vision, Round Based Hybrid Delegated PoS w/ PoW

We are planning on combining the best of PoW with the stability and speed of PoS to create one kick ass network. We’ll use DPoS for managing the distributed ledger and PoW as part of the transaction construction and validation process.

Operational Overview

When a user wishes to send a transaction, they generate the transaction in the “normal” way. However, there is a nonce field included in the transaction that requires for the user to perform PoW for that singular transaction to meet a preset difficulty for transactions. The resulting transaction and the nonce is then forwarded to a node for broadcast to the network.

Every transaction will require a base amount of work (PoW) before it can be submitted to the network in addition to a fee-per-byte network transaction fee. However, if a user wishes to discount their transaction fee for a particular transaction on the network they may submit a PoW for the transaction that meets yet a higher tier of difficulty. While the discount tiers have yet to be defined, the maximum discount for the transaction fees will not exceed 50% of the fee-per-byte fee. There are no free rides.

Fusion transactions will no longer exist on the network. As a wise man once said, “ass, cash, or hash, no one rides for free”. Everyone pays their fair share for transacting on the network regardless of the reason for that transaction.

Once a transaction is received by a node, the node performs basic checks (i.e.. transaction construction, valid nonce, PoW meets required difficulty, verifies signatures, etc.). Once that node completes the basic verification, it forwards the transaction to the rest of the network including the producers. Producers hold the transactions in the global memory pool after performing their own validations of the transaction ensuring that it is indeed a valid transaction. At this point, users can presume some level of assurance that the transaction will be committed to a block solely because the producers have accepted the transaction into the pool.

Once enough PoW transactions have accumulated in the pool to satisfy the network difficulty, the then current producer creates a block that ratifies the selection of transactions necessary to meet (or exceed) the network difficulty requirement. When doing so, the producer creates a block reward equivalent to a 1 for 1 matching of the aggregate transaction fees included in the block.

This means that emission is directly tied to the actual use of the network as a transactional platform. We will no longer be emitting currency on a pre-defined schedule as a result of this change. The more the network is used, the more currency that will become available.

The block reward is distributed proportionately between the block producer, the validators, and a subset of the users who staked that producer. Upon completion of the block the block is signed by the producer and transmitted to the network.

The validators, upon receiving the block, validate (at minimum) that:

  • The producer was permitted to produce the block (their turn)
  • Enough PoW transactions have been included to meet network difficulty
  • Transaction hashes included in the block have been included such that the hashes are arranged in descending order
  • The block is properly signed by the producer
  • The transactions in the block meet all of the consensus rules of the network (no double spends, etc.); and
  • No unnecessary data is included in the block
  • That the producer claimed and paid out the proper block rewards.

A minimum of 51% of the validators must then sign the block and submit their signatures to the network thus ratifying the block itself.

After the block is ratified, the network difficulty is adjusted (if necessary) to account for things such as the number of transactions included, the PoW of transactions included, and any other metrics required to keep the network operating correctly.

No Empty Blocks Means Storage Saving Is Built In

One of the largest benefits in this scenario is that we no longer produce empty blocks and thus save tons of storage space. This makes the chain faster to sync, easier to store, and overall much easier to manage.

Tut, Tut: The Reward Lottery

Gone are the times when a single miner/pool received the entirety of a block’s reward. In this new model, the block reward is distributed to multiple recipients via the payments to the producer, a pseudo random validator, and a pseudo random subset of users who have staked the given producer and validator.

The Reward, Divided

We’re still playing with the numbers but there’s a pretty good chance that the block rewards will be divided as follows:

  • 20% to the producer of the block
  • 20% to the one of the validators of the block
  • 30% to the users who staked the producer
    • Maximum of 10 randomly selected stakers
  • 30% to the users who staked the validator
    • Maximum of 10 randomly selected stakers

Becoming a Block Producer / Validator

A user (“Alice”) wishing to operate a block producer or validator “announces” their intent for candidacy by staking their node(s) with a minimum stake of a yet to be determined amount of TRTL. Upon successfully staking their node, Alice’s node is now a candidate for either a producer or validator spot in a round. It is important to note that Alice simply staking her node does not automatically make Alice a block producer or a validator.

To be a candidate for either role within the network, Alice must be “endorsed” by other users of the network via users staking their funds in support of Alice. Once Alice has at least 1 TRTL staking her, she is now a candidate in the running for a producer or validator spot.

The details of how these stakes are sent, recorded, recalled, etc. will be discussed in further articles and will undoubtedly involve a lot of math. Don’t worry, we’ll warn you ahead of time so that you can bring a protractor and a compass.

Electing Producers & Validators

Producers & Validators are elected for spans of blocks such that each producer is entrusted to create ten (10) new blocks in the round for which they are elected. How they are elected into these rounds takes place as follows.

In the event that a producer or validator fails to perform the work that was entrusted to them, their “trust” rating will fall for each block that they fail to producer and/or submit a validation result. If their trust rating falls below the lower threshold (TBD), the stake they put forth to submit their node as a candidate will be locked indefinitely (aka. burned).

First, we take the hashes of every block in the now closed round \{B_1, B_2, B_3, \dots\} and calculate the Merkle root for those hashes to establish M as the election seed for the next round.

We then take M and convert that to a scalar p:

p = H_s(M)

Then compute the public key P of p:

P = pG

We then tally T the individual bytes of S to determine if the result is odd or even.

T = \{S_1 + S_2 + \dots\} \mod 2

  • If T is odd (T \equiv 1) we collect public keys from the candidates list that are T \geq P.
  • If T is even (T \equiv 0), we collect public keys from the candidates list that are T \leq P.

Once the collection of public keys in the new defined range have been collected. We review the number of votes (stakes) received for each public key and construct a listing of candidates with their tally of active votes. The list is then sorted by vote count in ascending order and the top and bottom candidates in the results are discarded. The total votes submitted for the remaining candidates are then tallied to arrive at a total votes casted count (V).

The resulting candidates are then assigned ranges for which the selection algorithm must land for them to become a producer/validator.

If the remaining candidates consist of:

Candidate 1: 11,583 votes
Candidate 2: 25,749 votes
Candidate 3: 99,000 votes
Candidate 4: 127,342 votes

The the ranges for each node are as follows:

Candidate 1: 0 - 11583
Candidate 2: 11,584 - 25,749
Candidate 3: 25,750 - 99,000
Candidate 4: 99,001 - 127,342

We then perform the selection of the first producer via e_1 = p \mod V. The value of e_1 is compared against the node ranges thereby establishing that node as a producer.

On the next iteration of the election process, the previously selected node (e_n) is removed from the collection and V is recomputed before the selection algorithm runs again. Thereby guaranteeing that we do not elect the same producer/validator into more than one round slot.

The process is repeated until the required number of producers (more detail later) have been selected for the next round. At which point, the same process is performed for the candidates on the opposite side of P as T had dictated for producers until we have selected enough validators for the next round.

In the event that we are unable to select the necessary number of producers or validators from the pool of candidates as required for the round (i.e.. there are less candidates than there are required slots) the number of required producers/validators will be decreased until there are enough candidates to fulfill the request; however, at no point shall the number of producers and/or stakers for a round be an even number of spots.

There will always be a minimum of three (3) producers and/or validators required in a round. The number of required producers and/or validators for any given round will adjust dynamically (details to come later).

Pseudo Random Selection of Validator & Staker Selection for Block Rewards

When a block is produced, the producer must include relevants outputs to not only pay themselves but to also pay a deterministicially selected validator as well as stakers that staked the producer and that validator.

To select who receives the reward(s) we perform the same selection algorithm as we do for producers and validators with the exception that the prior block hash is used in place of the Merkle root for the previous round (M).

In the case of selecting which validator gets rewarded, the process is ran exactly once (1) for the set of validators for that round.

For determining the stakers to reward, the process is completed exactly ten (10) times for the set of stakers staking the winning producer/validator and the number of stakes the staker has submitted for the given candidate determine their “vote count”.

If, any time during the loop used in selecting stakers, the number of available stakers is exhausted (there are less than 10 stakers that backed that producer/validator), the process resumes as if all stakers are included in pool again and the iteration(s) continue until the necessary ten (10) stakers are identified for reward.

After completing the above, the producer then constructs a transaction for inclusion in the block that rewards the parties in the percentages necessary such that there are twenty-two (22) outputs in the miner transaction that is included in the block.

  • 1 for the producer
  • 1 for the selected validator
  • 1 each for the 10 stakers of producer
  • 1 each for the 10 stakers of validator

The entire process is designed with a sense of pseudo-randomness that can be recreated by every node on the network using the defined process. In essence, the whole reward structure is a bit of an election with an upper and lower house as well as a lottery for those that backed the elected producer/validator.

The Issues in a Nutshell


Problem: The current blockchain is very, very, very big, and growing every day whether transactions are included in blocks or not. There is also an insane amount of bloat in the chain including transactional spam (fusions anyone?), CantiPixels, and gobs of other useless data that is like walking around with cement shoes with two boat anchors tied chained to your ankles.

Solution: Relaunch the chain. Out with the old and in with the new. To facilitate this, we’re going to need to let the coins on the old network burn in a provable way to prevent errant inflation or other nefarious incidents. In addition, the old chain must be spun down in such a way that the chain officially ends at a certain block. Users need a way to transfer their funds from the old chain to the new chain and that means we’re going to need a…

Coin Swap

Problem: We have to efficiently move funds from the old chain to the new chain.

Solution: A coin swap window of opportunity. The coin swap window to the new chain will be 1,000,000 blocks (as measured by the old chain) during which time users will submit transactions on the old chain to a predetermined wallet address that will serve as a burn address whereby no one user can pick up the funds out of that address (this will be a multisig N:N wallet to make sure no one party controls it). An outside watcher server will watch for transactions on the old chain going to that wallet as instructed by the swap “service”, and release funds on the new chain to the address/keys provided by the user. The swap itself will be funded via a pre-mine on the new chain equivalent to the estimated circulating supply at the time of of the end of the old chain.

After the swap window completes, the remainder of pre-mine funds will be redistributed on chain.

Note: The redistribution of any unclaimed (whether through inaction or as “lost” wallets) via block rewards will be executed over a number of rounds on the new chain to attempt to ensure a somewhat even distribution of those funds to producers, validators, and stakers. Details on the exact schedule of distribution will come later as it will be highly dependent on how much TRTL will have to be dealt with.

In short, the swap mechanism will be a website that helps you transition from old coins to new coins. The technical mechanics of which will be discussed in later articles.

Wait… the chain is massive… we can’t just carry over everything from old to new we have to think about…

Swapping 107,198,508+ Outputs…

Problem: Swapping over 100M outputs to the new chain is… let’s put it simply, incredibly stupid. If we were to do that, yes, the new chain would not have the history of all of those outputs, but considering that we don’t know which outputs are still spendable, there is an unknown number of outputs that we have to create on the new chain as part of the swap process. That number is somewhere between 0 and 107,198,508 (as of the time of this writing). That’s just insane not only to think about but to also execute on.

Solution: During the relaunch of the network and required coin swap, we will be performing the equivalent of a 100,000:1 TRTL (or 10,000,000:100 atomic units) swap while maintaining two decimal places. Swaps of less than 1,000 TRTL will simply become dust and will not be swappable. Don’t worry though, the swap “service” will gladly take your unoptimized outputs and give you brand spanking new optimized outputs.

This swap ratio will eliminate the need to transfer more than ~81% (as of the time of this writing) of the outputs on the old chain thereby avoiding the pollution of the new chain with much of the problems that exist with the current chain.

A Note on Coin Swap Transaction Fees

The swap service will be set up such that as long as 100% of the funds in a transaction sent to the swap service are actually sent to the swap service (no change outputs) then all network transaction fees you pay to send those coins to the swap service will be included in the amount that you receive on the new chain. Furthermore, the swap service will have the ability to bypass the new chain transaction fee mechanics so that you receive the full value of your swapped funds at the ratio given (truncated to two decimals).

A Sustainable, Usage-Based Emission

Right now our blocks come out every 30 seconds, empty or not, and this keeps our emission at a steady pace toward the maximum of 1 Trillion TRTL some time over 100+ years from now. On the new network, there are no empty blocks, and block times won’t mean anything, so we cannot rely on that timing to release new coins into the supply.
Given that the converted supply is quite low (10 Million, two digits after decimal), and block time is now irregular, we have come up with a new way of keeping new coins entering into the system.
On TRTL v2, the network will match all fees 1:1 with additional coins, making our emission tied to actual usage on chain. 10 Million would be a soft cap, and given enough usage to provide a demand for more coins, more coins will automatically become available via the fees produced by transaction volume.

Now What?

From here, we’re working at solidifying protocol level communications, working on designing the next generation p2p network itself, working on basic structures (transactions, blocks, etc.) and defining some of the inner workings of the actual consensus mechanisms that we’ll be introducing. We’ll provide additional details as they become available. Until then, keep chatting and don’t forget to let us know what you think at

Feature Story


Have a seat, pour a cup of whatever drink you celebrate with, and think about where you left those old TRTL wallet keys. Whether you like what we say next or not, you’re going to need them, soon..

My friends, it is time for us to say goodbye.

Today we hit block 3,000,000. We upgraded our network and our proof of work algorithm for the last time. By block 4,000,000 or in about 1 year from today, the TurtleCoin network as we know it will begin on a path of its own destruction.

A short time after block 5 million, the chain will be dead, and completely gone, unable to produce more blocks.

Don’t panic, we have a plan. I said this would be celebrating 🙂

Sometimes you have to know when it is time to move on, and for us the time is now. Starting today we will be freezing the main core software repository. In the year that follows we will be writing code, documentation, and testing the new software we are already building for TRTL v2.

The next iteration of the software will work best with a blank slate to allow us to improve the network based on the things we learned in our current software. The main changes are:

  • Chain relaunch near December 2021
  • Coin swap w/ reverse split
  • Fair proof of stake
  • New core software

Let’s look into each one of those points and explain what is happening from a high level.

Chain Relaunch

Launching with a fresh chain on new software will enable us to be more flexible in the things we can make the new network do. If we have to operate with the constraints of backward compatibility, we will have to write a lot of code twice and basically build another version of what we have now, instead of something completely new.

Coin Swap w/ Split

Despite having a low emission atomically, our transactions average a large number of inputs. A lot of these smaller inputs now become smaller than the cost of handling them, so we call them “dust”. Think of how many handfuls of pennies you would need to pay for lunch.

To cut down on this dust, we will be reducing our supply by 100,000:1.

If you currently have 10,000,000.00 TRTL on the old chain, on the new chain you will have 100.00 TRTL. If you have 1,000,000.00 on the old chain, on the new chain you will have 10.00 TRTL. We will be keeping the 2 digits after the decimal point and will be keeping the TRTL ticker and wallet prefix.

The above examples of the coin swap amounts were updated after publication to reflect the proper swap math in atomic units.


The new total supply of TRTL will go from 1 Trillion (1,000,000,000,000.00 TRTL) to 10 Million (10,000,000.00 TRTL).

If you have <1,000.00 TRTL today, you will have 0.00 TRTL on the new chain.

The swap will be organized via a website that takes your new wallet address and helps move your coins to the v2 chain. When the swap is complete and the old TRTL chain is dead the old funds will be burned never to exist again.

Proof of Stake

We don’t have a fancy name for it yet, but we have designed a system that could kind of be compared to proof of stake, but it still has a little proof of work sprinkled on top.

TL;DR – There will be staking. There will be no more proof of work for mining.

We have developed an algorithm in-house that involves staking and uses a fair system for selecting block producers where whales have a hard time dominating production without significant cost. To cut down on spam and wasteful transactions, we are using proof of work to derive a proof of importance for each transaction, offering a user the option to compute more rounds of work to lower the fee, or pay a higher fee to send more rapid transactions.

The end result is a block chain that consumes less resources, is less centralized, and incentivizes good peers to stay online and provide good network throughput as we grow in volume. On the new network, there are no empty blocks, either.

New Core

We have already started specifying and building the new core protocols. It made sense to keep the modular approach of daemon+wallet, so starting with the daemon, we are writing it all from scratch. While this means we will no longer be a CryptoNote project, we will still have privacy the way we do now, and with the added bonus of not being a fork of anything, as that seems to bother some people.

Part of focusing all our efforts on the new core suite is to stop slapping duct tape on the old code base. From this point forward, there will be no new features, enhancements, or active development on the current repository. We will, however, review and address any critical issues and bug fixes that are required to keep the network in stable operation. In due time, you will find the current repository archived and read only once we are ready to nail the coffin closed via a consensus mechanism that brings the current chain to its final resting place.

We hope to be able to testnet the new network daemon soon, and I am sure we will need testers when we are ready, so if you have Discord, pop on by the TurtleCoin Discord and let us know so we can put you on a list of testers for when the time comes.

Until then, take care, we look forward to another 3 years with you all 🙂

TurtleCoin® Core Team

Feature Story

TurtleCoin v1.0.0 Upgrade



Master Build Status

Build Status

Special Notes

Upgrade to this release is required

Network Upgrade at block 3,000,000

This release includes a mandatory network upgrade at block 3,000,000 that implements a change to the Proof of Work (PoW) algorithm for the network to Chukwa v2 (1 Thread, 1MB memory, 4 iterations). Pools, nodes, and services are required to upgrade to this new PoW to continue mining blocks at block 3,000,000 as blocks mined with the previous version of Chukwa will be rejected.

Daemon API Changes

The daemon API has changed significantly in this version. The vast majority of the API calls have been removed, migrated, or otherwise adjusted such that all services using such API require that you perform updates to your packages. The API calls have moved to a most RESTful approach and the endpoint routes have changed. Please see for information on what the new API looks like and update your packages accordingly.

Note: Please be mindful when updating your packages that the property names in the returned responses including their name, case, structure, and/or data type may have changed.

Client / Wallet Upgrades are Mandatory

The API changes indicated in the daemon require that you use the latest version of the core wallet software. If you use a wallet other than wallet-api or zedwallet++ that wallet software must be updated to support the new API. As such using older wallet software with public node(s) that have upgraded to this release will fail until your wallet software is upgraded.

End of Life (EOL) and End of Support (EOS) Notice

Please note that v0.28.3 was the last release to contain turtle-service. This release no longer contains the turtle-service binaries or source code and thus is no longer supported. You must convert to wallet-api to continue working with the network as it is the only service to be upgraded in conjunction with numerous daemon API changes. If you have not converted your wallet(s) and or services over to Proton, zedwallet, or wallet-api you are encouraged to do so now. Should you experience any issues working with wallet-api, please make sure that you open an issue so that the issue may be resolved as quickly as possible.

Legacy Wallet Support Removed

Support for legacy wallets (ie. those created with simplewallet and/or turtle-service) has been removed from the project. We highly suggest that you upgrade your wallet(s) using a prior version of the core suite via wallet-api or zedwallet++ or recreate your wallets from the recovery mnemonic or keys using zedwallet or wallet-api.

As always, make sure you have backed up your keys as that is the only foolproof way to restore your wallet in the event of an issue.

Release Notes

General Updates

  • Bump version to 1.0.0
  • Removed turtle-service
  • Removed NodeRpcProxy
  • Removed support for legacy wallet versions
  • Removed WalletUpgrader
  • Removed support for upgrading legacy wallets to new wallet format
  • Removed WalletGreen
  • Implemented consensus change at block 3,000,000 via major block v7 to Chukwa v2
  • Replaced all usage of nlohmann::json with rapidjson
  • Updated coverage of TX_EXTRA field parsing
  • Numerous CI/CD process changes in support of newer GH runners

TurtleCoind Updates

  • Required P2P minimum version bump to v11
  • Upgraded API endpoints to RESTful style calls (see.
  • Resolved a bug in the retrieval of headers such that the iterator was decrementing below 0 and thus trying to look for blocks that will not exist
  • Change the /indexes endpoint to be inclusive of the end height supplied
  • Added explorer property to the /info API call
  • Adjusted TX_EXTRA field ordering in block templates such that they are ordered by tag type (ascending)
  • Catch and handle segfaults when block is not found in some explorer methods

zedwallet++ Updates

  • Updated user expoded file path opening with error messages
  • Added --reset CLI flag
  • Added rewind to height CLI flag
  • Updated WalletBackend to rewind on subwallet import

wallet-api Updates

  • Updated WalletBackend to rewind on subwallet import
  • Added rewind endpoint (see documentation for more information)
  • Prevent the import of wallets that already exist in the wallet container
  • Update Regex matchers in API endpoints

miner Updates

  • Updated support for new daemon API
  • Updated support for Chukwa v2

cryptotest Updates

  • Inclusion of Chukwa v2 test hashes and verification

Known Issues

  • N/A

How To Sync Quickly

Visit the checkpoints how to use site for simple to follow directions on using checkpoints.

How To Compile

Please see the How To Compile section of the project README for instructions on how to compile this release on your system.


See the TurtleCoin Release page for the full change history.


Cryptonote Developers, Bytecoin Developers, Forknote Project, TurtleCoin Community

Feature Story

The Return Of Market Talk

Why? Because it’s fun to do bad things.

For those of you who paid attention during the last roundup, we mentioned that some discussions were happening at the old sandwich cart about a few potential changes around the chat. Turns out we were discussing whether or not the time was right to give a shot at letting market talkers have their own channel in the server.

If you go to the chat right now, there is a room called turtle-traders. If you are surprised, so are we. Keep reading though..

In the beginning…

When the TRTL discord first launched, it was during crypto December and what seemed like the entire world was in the chat talking about all topics under the sun. This had the positive effect of attracting a lot of otherwise unoccupied bright minds… along with a few shitheads, as can be expected with a sample size that large.

We hit 10k chatters almost instantly.

In our price history if you look back far enough when total emission was very low, and sell orders were very thin, we had an early investor who meant well end up purchasing and entire BTC worth of TRTL from the one exchange we were listed on at the time, which caused an instant spike to something in the low 30 Satoshi range.

We have been living that down ever since. Naturally that spike sent what I would say in hindsight are the wrong signals, and buyers poured into the chat with hands on hips, demanding ridiculous things of brand new devs who had just signed, clapping at the nerds while telling them to work harder for their investment and basically justify their commitment to their new crypto-tradegod overlords.

I do not remember how long this went on but we quickly lost a few great devs who were really pushing things forward at the time in interesting directions, because they didn’t sign on for that, they just wanted to be devs, and the rapidly declining price didn’t make that any easier. People I knew personally even left the project. Things were getting bad and something had to be done.

Right when things were coming to a tense crescendo between traders and devs, the SEC began alluding to pending legislation on cryptoasset networks like us, and to pre-emptively get our little Turtle nuts out of the fire, we made the decision to push the traders out of the chat.

It was not a difficult decision.

The first market server

Naturally the traders had to go somewhere. We had two rooms named General in the main server and the lines of chat would move so fast you could not get a word across at all, just type something and send it into the fray while praying for the best. Needless to say there were a troupe of people who needed somewhere to go, and we were just sliding them out the door.

A developer contributor by the name of Madk stepped up and formed his own Discord, which was convenient since he was not closely linked to core at the time, and was not an American, so risk of being hassled by the SEC was very low for him.

I don’t remember exactly how long this server lasted but it filled up quick, and attracted all types. There were many friendships formed there, and a few horror stories as well.

Eventually Madk decided he wanted to take his mod hat off and unceremoniously nuked the server one night. There are a lot of details I am deliberately leaving out here, but you will just have to ask someone who was there to tell you if you are that interested.

Personally, it is my opinion that those who endured those years were better for it as a result, but I am also aware that my opinions aren’t always great.

Except Madk.

The guys might say he was always this way, but I don’t think Madk was ever the same after that.

The next market server

Again, being cast out of their native home land, a group of lads still claiming to be traders along with their pet bots were not ready to let the party die, so a new market server guy emerged from the crowd ready to lead the charge. His name was Buggles.

Buggles created the second market server for those of you around long enough to remember the switch. It was a natural fit and easy transition for many of the people there. Buggles had been part of the community for quite some time at this point, and everyone just moved over.

Ironically this market server did not have much trade discussion. It mainly consisted of the aforementioned lads doing lad things, and being nice, then over in the corner, a few people being berated by the ‘cool kids’ for their support of TRTL. There were accusations of us being a shitcoin, the name ToiletCoin gained popularity in some circles (Xaz still has the username TRTL = ToiletCoin to this day in fact) and though the good times mostly outweighed the bad, that type of stuff is just bad for the image and morale of the users of the network and disrespects those who continue to contribute code and documentation to it. It wasn’t Buggles fault, these problems just seem to dog us since our early history, I don’t think it would be any different if we were another network.

Until that time we had always referred users to a read-only room called Market Talk in the main server where a direct link to whichever market server we were using at the time would be for easy access. It is not that we did not want people to ever talk market topics, we just wanted to keep the main server for support and development so it seemed natural to at least help folks find their way out of the server to keep market talk where it belonged.

As the price dipped further and people got worse and worse views and opinions of parts of our community, I kinda got tired of how users were treated by the traders and removed the link to the market server one day, a decision which even Alien our TurtleCoin CEO said was a good idea.

What followed, I would say, was just unworkable. Probably not my finest moment.

How to kill a crypto discord

After removing the link to the 2nd market server, I was at wits end with having to explain to people who had just agreed while entering the server not to market talk and that yes it was indeed a serious rule, and it started to feel like a chore to exile people. We just want to write code, and all this market talk stuff was distracting us from that.

I made a critical mistake.

If you are not already shouting at me through the screen, I made a critical mistake at the time. I removed the link to an alternative market chat, giving traders nowhere to go. And even if they did get the link, the first impression would be poor when they arrived at the market server, and when they inevitably look for a place to talk shop in the main server, we would send them to the origami chain gang.

This was an unworkable solution obviously.

While everyone was being sent home for COVID and signing on to our discord, I was busy with a broom chasing them out of the chat for trying to blow off steam and shoot the shit with their friends about market stuff.

Soon, less and less people were chatting daily, and while it was the most productive time of my own time at TRTL, pushing code to what I felt was the most impactful project I had contributed to so far, I was frustrated that we were still sinking slowly. I felt like every day was treading water, but it was my own fault.

Market talk & other things we never thought would happen in 2020

A few days went by when maybe only 20 people or so were active in the discord chat, and while these were some of our most productive and dedicated members, I could feel morale draining and just had one of those Fuck it moments.

Fuck it. What is the worst that happens?

I figured, you know, right now is the time when we need eyes on us.. There is no way we are putting all this work into a brand redesign for 2020, we finally have a stable core suite, we are working on completing Karai, one of our biggest milestones this year, and still trying to pump life and fresh memes into a dead discord all day and the chat was still dying.

I am not sure if a market discussion channel will breathe some life into a once very lively server, but we have never been a team to sit around doing the same shit that does not work, or even worse, doing nothing.

We are giving this a shot, we hope you guys make the most of it, and most of all, I hope this brings more adoption for TRTL and its users for 2020 and beyond. We still push code to multiple projects every day, and still see new faces, so while we give ourselves this second chance we hope you guys join us and shoot the shit in the new market room.

Have a good night 🙂

RockSteady TRTL

Feature Story

Migrating from fixed fees to fee per byte – A developers guide

Welcome, developer!

As you may have seen, we are moving to utilising a minimum fee per byte at block 2,200,000. For more information on the reasons behind this decision, please check out this article from the core team:

What do I have to do?

If you have an application which sends transactions on the TurtleCoin network, you will likely have to update your code to work correctly with fee per byte.

Step one is ensuring you have the latest code. This is currently only available in the development branch on GitHub, but will become a published release once fully tested.

Once you are running version 0.22.0 of the software, you will need to update your code to work with it correctly.

The lazy, expensive way

Since we charge a fee per byte of 5.00 TRTL (Or 500 atomic units) per 256 bytes of transaction, and transactions are limited at 124400 bytes if you’re using the core software, you can just set a fixed fee of 2430 TRTL, or 243000 atomic units.

This fee will always be large enough to cover the biggest transactions, so you can just update your fee parameter in your sendTransaction JSON, for turtle-service, and with wallet-api, update your /send/transaction/advanced fee parameter and you’re done. If you’re currently using /send/transaction/basic with wallet-api, you will either want to migrate to using /send/transaction/advanced, or read on for a method that works with /send/transaction/basic.

However, this is not the cheapest way. In addition, if the minimum fee per byte is increased in a later fork, you will have to update your code again. Booooo!

Read on if you want to make your users like you more. Don’t worry, it’s not hard!

The cheaper way

If you just want to use the minimum fee per byte allowed, all you have to do is not specify the fee parameter in your sendTransaction or /send/transaction/advanced JSON. The wallet application, be it turtle-service, or wallet-api, will then automatically calculate the minimum fee for the transaction. If you are currently using /send/transaction/basic, it does not have a fee parameter, so this is the default behaviour.

Once the transaction is sent, the actual fee paid will be returned along with the transaction hash. This way you can update your database, display the fee to the user, and so on, as needed.

“Hang On!” – I hear you shout. How do you know how much the fee will be before sending the transaction? Not to fear – we’ve thought of that.


With turtle-service, instead of using sendTransaction, you can use createDelayedTransaction. This method works exactly the same as sendTransaction, except it does not relay the transaction to the network – so no funds are sent. It will return the transaction hash, and the fee of the transaction.

If the fee is fine, and you want to send the transaction, you can use the sendDelayedTransaction method.

If you’re not happy with the fee, or want to cancel the transaction for some other reason, use the deleteDelayedTransaction method to cancel the transaction. If you do not delete the delayed transaction, the funds will remain unspendable, so don’t forget this step!


With wallet-api, the process is very similar. Instead of using /transactions/send/basic or /transactions/send/advanced, you can use /transactions/prepare/basic or /transactions/prepare/advanced.

As will turtle-service, these methods are identical to the standard ones, and take all the same parameters.

Again, like turtle-service, these methods will return the fee of the prepared transaction, and the transaction hash.

You can then use /transactions/send/prepared to send your prepared transaction if you are happy with the fee. If you want to cancel a prepared transaction, use the /transactions/prepared/{transaction hash}/ DELETE method.

Unlike turtle-service, a prepared transaction does not lock your funds for spending, and therefore cancelling a prepared transaction is not mandatory. It will, however, save a little bit of RAM usage from not having to store the transaction data.

Due to the funds not being locked, this can result in a previously prepared transaction no longer being possible to be sent – If you sent another transaction meanwhile, it could include inputs that the prepared transaction also included.

Finally, due to a deterministic input selection algorithm, even if your prepared transaction is no longer valid, the fee for sending the same transaction again is likely to be very similar. This means you can essentially use the prepare transaction methods as a means to estimate the fee of a subsequent transaction with the same data.

Specifying the fee per byte

If you desire to pay a higher than minimum fee per byte, we have you covered. Simply include the feePerByte argument in your transaction JSON, in replacement of the fee parameter. This value can be a floating point value, and should be greater or equal to the minimum fee per byte of 1.953125.


turtle-service example

Request before fee per byte
   "fee": 10
Response before fee per byte
Above: Before, Below: After
Request after fee per byte
    "fee": 4500

wallet-api example

Before fee per byte

Request before fee per byte
  "destinations": {
    "address": "TRTLv2Fyavy8CXG8BPEbNeCHFZ1fuDCYCZ3vW5H5LXN4K2M2MHUpTENip9bbavpHvvPwb4NDkBWrNgURAd5DB38FHXWZyoBh4wW",
    "amount": 1234
  "fee": 10,
  "sourceAddresses": "TRTLv2Fyavy8CXG8BPEbNeCHFZ1fuDCYCZ3vW5H5LXN4K2M2MHUpTENip9bbavpHvvPwb4NDkBWrNgURAd5DB38FHXWZyoBh4wW"
Response before fee per byte
  "transactionHash": "396e2a782c9ce9993982c6f93e305b05306d0e5794f57157fbac78581443c55f"

After fee per byte

Request after fee per byte
  "destinations": {
    "address": "TRTLv2Fyavy8CXG8BPEbNeCHFZ1fuDCYCZ3vW5H5LXN4K2M2MHUpTENip9bbavpHvvPwb4NDkBWrNgURAd5DB38FHXWZyoBh4wW",
    "amount": 1234
  "sourceAddresses": "TRTLv2Fyavy8CXG8BPEbNeCHFZ1fuDCYCZ3vW5H5LXN4K2M2MHUpTENip9bbavpHvvPwb4NDkBWrNgURAd5DB38FHXWZyoBh4wW"
Response after fee per byte
  "transactionHash": "396e2a782c9ce9993982c6f93e305b05306d0e5794f57157fbac78581443c55f",
  "fee": 1000,
  "relayedToNetwork": true


There are a few things you can do as a service operator to decrease the fees you pay.

The first is sending round number outputs. For example, sending a transaction of 20000 TRTL will result in a single output, while sending a transaction of 22222 TRTL will result in 5 outputs. Outputs are not the only thing that make a transaction bigger, but this is one of the variables that you can easily control.

The second is increasing default payouts. Instead of creating 10 transactions of 1000 TRTL, and thus creating 10 outputs, you can instead create 1 transaction of 10000 TRTL, which will only create a single output.

Applying these changes will result in you paying less fees, and will also mean your users pay less fees when they come to spend their funds – they will have less resulting inputs in their wallet, so will create smaller, cheaper, transactions.

Closing remarks

Confused? Want some more help?

Start by checking out the documentation of the API you are using.

Finally, if you just can’t get the hang of it, or want some clarification on how it all works, stop by the #dev_learning or #dev_general channels in our discord, and we’ll happily help you out. If you’re not in discord already, you can find the invite at

Happy Hacking!

Feature Story

The TurtleCoin Journey: 2 Years and Counting…

Earlier this month, TurtleCoin celebrated its two year anniversary of starting the project. The community and project have come a long way in the last 24 months and we are all proud of what we, as a community, have accomplished during that time. That’s not to say that we didn’t have a few set backs, learning opportunities, and challenges to overcome that tried our patience at times and ultimately drove the community to make changes to how the network and core suite operates. From multiple PoW algorithm changes, difficulty calculation changes, and a move to static mixins, each change was evaluated and adopted by the community with excitement and hopes for the future health of the network.

We’ve heard the pleas of the community over the last two years and by far the majority of the requests revolved around the folowing:

  • What is the community doing about the chain storage size?
  • When can the community expect more stable daemon/node operation?
  • Is RockSteady Satoshi? (TBD)

These pleas have not fallen on deaf ears and the result of those requests include a culmination of upcoming changes to the network and software with the next release of the TurtleCoin core suite. We are very excited about these changes and believe they are important for everyone to understand.

zedwallet (Legacy Edition)

The application formerly known as simplewallet

Zedwallet Legacy: End of Life

We announced in the v0.20.0 release notes that the legacy version of zedwallet contained in that release would be the last and final release containing legacy zedwallet. This statement still holds true and the code for that old version of zedwallet has been removed from the project. The next release of the core suite replaces the binary named zedwallet with zedwallet++ which is a new, faster, stronger version of the CLI wallet software. The zedwallet binary released going forward will be powered by zedwallet++.

Zedwallet Legacy: End of Support

We also announced in the latest release, that support would end for legacy zedwallet December 31, 2019. Starting January 1, 2020 if you ask for help with legacy zedwallet issues, we will kindly insist (with a stick in hand) that you upgrade your wallet using the latest release of zedwalletwallet-upgrader, or wallet-api. Again, the old code has been removed, lost, buried, and forgotten about at this point.

But, Why?

Don’t be that guy, don’t say you didn’t know.

Simple: portability, maintainability, and scalability. Legacy zedwallet (also turtle-service) based on WalletGreen creates wallets using a very unfriendly internal wallet schema that makes it very difficult to work with in different languages, platforms, and etc.

The new hotness, WalletBackend, creates a friendly, easy to use, fully documented, and portable wallet schema that is a JSON object when decrypted. WalletBackend lowers the barrier of entry for other developers to work with data created by the core tools and thus makes it far easier to develop other cool portable projects like TonChan and many others.

Deterministic Subwallets

It’s pretty much like a choose your own adventure book

We’ve updated the code in WalletBackend to default to the deterministic creation of subwallet addresses and support the restoration of those addresses in a deterministic way. This change is designed to help services in being able to quickly restore subwallet in the event that they lose any subwallet keys.

Instead of generating new random spend keys for each new wallet created in a single container, new wallets in the same container are now derived from the primary wallet address. The details of the how we derive subsequent private spend keys for subwallets is detailed in Issue #831.

Making subwallet private spend key generation deterministic allows for the restoration of any subwallet by just maintaining its index (position) in the wallet container. No more need to store all those extra keys! This is a major improvement for the teams in the community that handle subwallet addresses and users who use subwallet for a variety of purposes.

TurtleCoind Threading

Threading solves everything


Zpalmtree has worked tirelessly to implement process threading into the core daemon for the RPC interface. This helps keep the RPC interface responsive during heavy load and greatly reduces the impact to the network when the transaction pool gets hit with an influx of transactions. This change will help minimize the effects of heavy load on the network and improve the overall stability of node operations.

Transaction Input Validation

Zpalmtree also added support for threading of the input validation routines for new transactions entering the network. This allows inputs to be validated in parallel and thus drops the transaction validation time considerably. In doing so, transactions enter the network, are propagated across the network, and are ultimately included in blocks faster.

Transaction Pool Changes

How the transaction pool is managed by the core software has been changed recently to help decrease the effects of transaction spam, chain bloating, and other less than helpful actions on the network. We quickly noticed some less than friendly transaction activity taking advantage of our 30 second block times, low network transaction fees, and our good nature as turtles to bloat the chain with low-cost and free transactions that consisted of only breaking apart their funds into shells and recombining them into whole TRTL over and over again.

Transaction Selection Process

We are not the sort to create our own sorting algorithm to sort our sortables

We’ve improved upon the transaction pool ordering and selection criteria for when a miner creates a new block. In short, we’ll always de-preference transactions that are fusions and low total amount transactions as the odds are considerably better that such transactions are “spam”. As always, miners will prefer transactions with higher fees, size, and other metrics to move transactions through the network faster.

Fusion Transaction Limits

We’ve employed additional changes to the transaction pool where each node’s copy of the transaction pool can no longer accept any more than 20 fusion transactions at a time. All other fusion transactions will be rejected until there is room in the transaction pool for more.

This may result in an extended number of fusion rounds for highly disorganized (non-optimized) wallets. If you haven’t fused your wallet in a while, you might want to do so soon.

The line for the Coinstar starts at the back…

Network Upgrade at Block 2,200,000

We have a few consensus changes coming at block 2,200,000 to help improve the stability of the network. These changes are designed to be as transparent as possible but some will reach out and hit you in the face.

Some of these changes are the result of previous discussions in a meta issue and a thorough review of where the network and software can improve the overall experience of the community while maintaining the goals of the project.

Events unfolding over the last few months solidified in our minds the fact that some people just want to see the world burn and as a community, we must take precautionary steps to ensure the longevity of the project.

Output Creation Limits

Starting at the next network upgrade, the network will no longer accept transactions that create more than 90 outputs per transaction. Why apply a maximum you may ask?

+3,500 new 0.01 TRTL outputs created… why do we need those?

There is no legitimate use case in which a transaction need ever create 3,500+ outputs. All this type of transaction traffic manages to do is bloat the blockchain at the expense of every community member. It also ultimately causes the reverse effect and bloats things even further by stuffing the transaction pool and chain full of fusion transactions. Such transaction cycles serve absolutely no purpose and degrade the experience of all users.

Oh yeah… that’s why we need those: fusion spam.

Fee Per Byte

The Backstory

While setting the minimum transaction fee to 0.10 TRTL at the project’s launch sounded like a good idea at the time, such a minimum has serious long term implications. Most importantly, it costs just 0.10 TRTL to send data (transactions) on the network and that data is stored indefinitely and processed by thousands of nodes across the globe thereby consuming a growing amount of resources.

Using such resources is not free and unfortunately, as the chain grows, the resources required to operate nodes grows. The more resources required to operate a node, the less people will be able and willing to commit the necessary resources. Simply speaking, 0.10 TRTL per transaction is not maintainable for the long haul operation of the network.

Okay, Great, Now What?

That math stuff you hoped you’d never need, well… I hate to tell you…

Keeping this in mind, with the network upgrade at block 2,200,000, the network will require a minimum fee for each transaction that is based on a calculation of 0.01953125 TRTL per byte of data of the transaction. This equates to 5.00 TRTL for every 256 bytes of data sent across the network.

Increasing the minimum network fee for transactions means that each transaction is required to pay for its existence and the consumption of network resources proportionate to its size in bytes.

This means that the if you send a transaction using a lot of inputs, or a lot of outputs, contains extra data in the transaction, payment IDs, or etc. (increasing the size of the transaction), you’ll be required to pay your fair share to use the network to transmit and store that data.

As the fees for each transaction are included in the miner block reward, miners will be rewarded with these higher fees for processing transactions. The vast majority of nodes on the network are operated by miners (and pools) so the increase in fees will help to offset the costs of operating those resources to run the network.

So… What Now?

What does this mean for the average user? You’ll see an automatic calculation of the minimum network fee when sending transactions. Depending on how optimized your wallet is, how much you’re sending, and what data you include in a transaction, you’ll see the minimum network fee climb from 0.10 TRTL to about 10.00 TRTL at a minimum.

Fusion transactions will remain free so we highly recommend that you keep your wallet optimized. As a miner, you’ll also benefit from raising your minimum payout with mining pools to higher thresholds as you’ll indirectly pay less in fees for the transactions that pay you for your mining efforts.

If your wallet is mostly composed of shells, you’ll want to optimize your wallet before this new fee structure kicks in. If you mine only on the biggest pool or make most of your TRTL through tips, you’ll definitely want to optimize your wallet immediately.

What’s The Catch?

Sending small transactions, when we needed more mixable outputs for fungibility purposes, helped provide the necessary data to make everything possible. This could be done at a relatively low, low, low cost of 0.10 TRTL; however, with this change, sending 1.00 TRTL to someone will now incur a cost of 10.00 TRTL. We’re sure you can do the math there and understand the sending small amounts (ie. tips) less than the network fee won’t make sense going forward.


Changes to the core software, including moving to fee-per-byte network fees, better transaction selection algorithms, and limits on fusion transactions will bring additional stability to the network, the operation of nodes, and help to address the concerns of the community.

Our work doesn’t stop with these changes and we’ll continue to work on enhancing the network, tools, and experience for all of the TurtleCoin community members.

You can do your part by spreading the word regarding these changes, showing your support, and voicing your opinion(s) in the chat.

As always, Pull Requests are your best avenue to shape the TurtleCoin experience.

Feature Story

Oh shit, I think it’s dead

For 27 minutes the TurtleCoin blockchain was dead on the table. We shouted at it, poked it with sticks, it was muerto.. Difficulty went from a healthy 2 Billion-ish area to 1, not 1 Billion, but 1, a single digit.

What went wrong? What does this mean?

First, you’re reading this because we’re back online and working. Rest assured everything is fine. We were down for less than half an hour and stayed in touch with services the entire way. Had this gone any worse, you’d be reading this story from the back of a milk carton.

The difficulty with difficulty

Difficulty is the part of mining that makes sure that whether there’s 1 person mining, or 100 million people mining, that blocks stay difficult enough for a miner to solve so that we crack one every 30 seconds. Sometimes it can be 15 seconds, sometimes it can be 45, but as long as it averages 30 seconds over a few day’s worth of blocks, everything is fine.

Our difficulty algorithm is LWMA2, by Zawy12. This algorithm is suitable for networks of our size to keep our block difficulty smooth of spikes in the graph. It uses a moving average based on the blocks that came before the current one being mined to keep a constant adjustment of this difficulty factor so that no matter how many miners join us, all blocks come out as close to 30 seconds as possible.

Normally our difficulty algorithm works just fine, however during fork upgrades, especially ones that will radically change our hashrate, we have to make a best guess ahead of time of where we’ll be before, during and after fork hashrate wise. In this case, our test scenarios told us the difficulty adjustment we chose was good, but as with all things, running in production was a different story.

You can see the actual shit hitting the fan right here.

7:51 PM We first knew something was up, the first 11 blocks on the new algorithm came immediately, and difficulty immediately dropped to 1.

7:56 PM We had formed a plan and had an upgrade in the works when we realized what had happened. At this time we notified in #announcements on discord that there was a momentary delay and to stay tuned for a patch. Major exchanges and block producers were also notified.

Only a single exchange responded to our advisory. Their response time was 3 minutes.

8:03 PM We began tweeting the situation live after a mad scramble to find the login credentials. Not a single complaint was received during the delay, which was absolutely wonderful.

8:12 PM A patch is submitted and being built by CI on github to produce binaries. The source is released as 0.18.1 for others to build on their own while CI builds.

Wait a minute… did he merge without waiting for CI/CD tests to finish?!

8:14 PM Patch seems to work, we begin passing it on via Twitter and Discord to users. To bring some light to the situation we adopt the hashtag #BorkedFork

8:15 PM At this time we’ve received no complaints and only a single exchange responded to our message, which they responded in 3 minutes (Thanks TO, you’re a real one). We hold our breath and wait for the block producing (read: really big) pools to pass enough blocks to make it official.

8:33 PM Things have been going smooth enough at this point that we feel we can say we’ve revived the network and things are currently humming along at a blistering 159MH.

Well done everyone. You all helped each other to relay the correct information regarding the patch and we all made it through this small stumble.

This likely won’t be the last time we’ll go through this but a lesson learned is a lesson earned and we won’t be letting go of what we were taught tonight for quite some time. Thanks everyone who participated, especially IBMCD for providing the patch like a champ in just minutes. Bravo, all of you.

TurtleCoin®  Core Team

Feature Story

Reminder to upgrade your software tonight!

With the upgrade taking effect in less than 24 hours, we felt it was important to remind everyone to upgrade your software before you turn into a pumpkin!

Before we begin, go here and start the appropriate download for your system:


Chukwa, it’s the name of our new hashing algorithm. To make it brief, it’s Argon2id based, loves CPU miners, and is the first significant departure away from the Cryptonote family of hashing algorithms. Read more here >>


This upgrade mainly concerns people who run mining pools, web wallets, asset exchanges, and other services that rely on the core software for their connection to the network to provide services to you. If you’re just a user, you’ll still want to upgrade, but just be sure to do it before the next time you want to access your funds.


As with all of our network upgrades, you can track them with our handy countdown on the official block explorer. Click here >>

We do these types of upgrades several times per year as part of our commitment to a fair mining environment.


You can always get the latest software you should be running at this URL:


We believe mining should be fair for as many people as possible, and that means no ASIC on the network until everyone can have that advantage, which means there needs to be more than a handful of competitive ASIC manufacturers and it needs to be a decision the entire community comes to before we can allow it.

Thanks for reading and being a part of this evolution of the TRTL Network 🙂 if you started downloading the new software when you started reading this, it should be done now.

We thank you for choosing TurtleCoin for your services!

Feature Story

TurtleCoin Roles and Achievements

know your roles!

Colored chat names, so hot right now

You may have noticed in our weekly roundups that we have a new section for recognizing those who’ve gained new roles in the past week. We get asked a lot about the colored names and ‘roles’ in our Discord chat, and whether people just want the colored name or actively want to contribute to the community, we’re always glad to see someone wanting to involve themselves with TurtleCoin.

This article will be an explainer for each role and what it means to us, and the way to gain them. If you have questions, just ask us!

Let’s start at the top of the list, and work our way down, from what an admin sees when they log in to TRTL discord.

Green names, some say they aren’t even real people

Green names are Ninja, these are founders of TurtleCoin. This is a closed role, there is no way to earn it, it doesn’t even have any extra privileges other than having a green name. There are a few people with a green name, however this is the most chat-inactive role group on the server.

The first troop of goons to step foot off the Mayflower

Footclan is the role that was created when we were just a few weeks old. TurtleCoin started out with a bang, and we worked around the clock for about a month before taking a break. A few of us took vacations with our families and on our return two weeks later, we found the community still ready for more. We made a decision to move forward with the project in earnest that day, and to remember those who were present and helping, we created the footclan role. Footclan, like ninja is a role that is just a color, and has no functional role advantages on the server.

The exalted pink names. Rumor has it they control the media.

Developer is the first of the roles we’ll discuss that can be attained by anybody, and has some merit attached to it. The one requirement to be a developer is to have code you contributed merged into our repositories. Typos don’t count necessarily but if you submit a patch or a fix for something, or if you maintain your own project in our GitHub organization, you get the hot pink Developer role. This role has functions on the server such as managing messages and access to dev-bridge feeds to IRC for other organizations (IPFS, Monero, currently). A good way to get this role is to check out our Good First Issues which are easy, low hanging fruit objectives.

Do you have a liberal arts degree? We’ve got a job for you!

Some folks want to help with stuff like writing guides, fixing typos, creating branding material. We needed a way to acknowledge people who share non-code contributions with us, and this seemed like a good way to do it. Obviously this one is pretty easy to attain, so to maintain some degree of exclusivity, we require that you register an account and Pull Request your contribution yourself. We’ll help, we just want you to be a well-rounded contributor, otherwise we’d have to give this role to every pedant who points out a spelling error, and that’s no fun!

Nobody knows about this role

Core contributor is a Developer who has had code merged into our core software. If you complete a Good First Issue on the core repo, you’ll get Core Contributor and Developer all in one shot. Nobody really asks for this role so we just apply it to people we know have contributed code to the core software as we notice them. No clue why. Also just a color role.

These are the music makers

Service Operator is a role given to people who operate public nodes, pools, web-wallets, tipbot, exchange, and any other application that integrates with our daemon and has an interest in knowing when things are screwy on the network. This role came out of a need of a way to address all of our service providers when we had patch fixes, network advisories, or critical consensus updates. This role gives you access to a private water-cooler type room that gets used about once a month when a large service optimizes their wallets and fills the TX pool with 1000 fusion transactions.

This role is cursed

PR Guerilla originally was a role we gave to people who made heroic acts of recruitment. The first person to get this role, GT3000, recruited over 500 people in a single week. These were active users that flooded the chat due to his efforts, many of them stayed and became contributors. This role is cursed, however, because every person who’s ever achieved it has disappeared immediately after.

Guest Dev is the title for well known core developers of other well known networks. This role was created so TRTL Developers can easily identify core contributors from other well known networks and talk shop with them. If you’re from a TRTL sized network and you’re reasonably active in our chat, you probably already have this role.

Educators have written classes or course materials for the TurtleEDU platform. What’s TurtleEDU you ask? It’s an e-learning platform we made to turn crypto-newbies into knowledgeable users, and take curious knowledgeable users and turn them into contributing developers. If you’d like to be an educator, we’d currently love to have someone write a course on interacting with REST API’s via a class on interacting with Wallet-API. (hint hint, aspiring educators!)

PSSST! Hey kid, you wanna buy a Nintendo? *opens coat*

These guys are basically moderators of the #Merchandise channel in Discord, where anybody can list an item when the bot is working that describes an item and a price in TRTL to sell it for. We’ve got a weekly column for this in the weekly roundup. Technically one could gain this role, but with the new merchandise bot it may be useless as the bot handles most of this stuff. This role came from an era when the merchandise channel was just for posting a single listing per line and not using it as a conversational channel. As things go, nobody, and I mean none of you fuckers can follow a single damn rule and it quickly devolved into conversations so we just opened it up and told people to pin their listings instead. When it works, the merchandise bot is a great thing to have.

Crash Test Turtles

This is a fearless brigade of self-appointed masochists who test all of our software before it is released. To give yourself this role, and a spiffy yellow name, type *tester in the chat and you’ll receive pings when we need testers for new software releases. This is what the report that testers fill out looks like [link]

To gain access to the EDU chat channels, type *student in the chat. This is for people who are in the TurtleEDU program that wish to receive updates about it. The TurtleEDU program is an e-learning platform we created to help people who are new to cryptoasset networks get more acquainted with their surroundings.

Datacenter nerds are the most socially disjointed kind of nerd you’ll ever meet.

These are people who can add and approve and delete or revoke records to the TRTL DNS system. If you’ve ever seen someone with a .trtl domain name, someone with the DNS role approved it. If you want to know more about .trtl domains, check this article out.

Stay away from these people.

We have a disciplinary area called Exile, and if you’ve seen someone with this role, they’re probably in Exile, with a jumpsuit on as evidenced by their name probably being something like Inmate #558929. These are people who you will have to walk down to #exile in the chat to speak to, because although they can read, they cannot reply anywhere else. You can shout at the inmates through the intercom by typing @exiled and whatever your message is. This role has so few privileges, you’re basically in timeout and only people who love you can come see you.


We use a bot some of you know that applies levels and points when people are active in chat. We use it to help identify new or inactive people to get you involved in the community. When you first enter the chat, you’re an Egg. When you’ve said hello or anything really, you become a hatchling. If you stick around even longer after that your name will turn green and you become a Turtle. After that, sky’s the limit, some say there are level upgrades all the way to 100…

These people want to know everything as it happens.

News is a self applied role you can get by typing *news in the chat. This will give you an alert every Tuesday when we post the weekly roundup. This role was Farhod’s idea, who wanted a better way to know when we’ve posted the weekly update.

You shouldn’t want this role.

We label a certain type of user as ‘spoonfed’, and though it could happen for various reasons, functionally it means you cannot post in dev-general, and it flags you as someone who’s likely to pester helpful devs. If you have this role, you should feel shame. People who get this role typically pop in our chats asking a seemingly basic question, then when someone helpful assists them, they latch onto your leg and won’t leave you the fuck alone because they don’t have any interest in learning anything, they just want someone to do it for them. Helping these types doesn’t help them, and it doesn’t help you, and it aids in all of our own abuse. If these people annoy you, stop hitting yourself. You’ll quickly notice every person with this role has a half-broken TRTL-forked shitcoin network that they’re eagerly waiting to dump on unsuspecting miners as soon as it hits market.

This is a role that we just added recently, it has something to do with basically being a moderator for our karaoke bot, Grandmaster Riddim Bot. Not sure what it does exactly as a role, but the bot required it to acknowledge admin commands or something.

Feature Story

The Teacup Files

There’s a person named Teacup on Discord who makes these delightful TurtleCoin pics we like to use in the chat and in the roundup. A day or two ago Teacup gave us this collection of pics amassed from an illustrious tenure as resident meme artist, so I figured it’d be best to put it somewhere that gets the respect it deserves, right here on our blog!

Also, were being some busters about hosting this collection, so we’re hosting it right here. Please don’t melt this server downloading them all, and don’t forget to tip Teacup.

Thanks Teacup 😀 We hope to do a part 2 some day -Rock