Proposal: simple tokens through “contract” accounts and token field

If there’s ever any interest in having tokens directly on the main network, I think it makes the most sense to have it be as unobtrusive as possible and have it work as closely to nano as possible.

My idea is simple: every account gets a single contract address field and a token balance, which means that any nano account can hold both nano and ONE other token. Send and receive blocks for tokens would work exactly the same as for nano (and in fact you could send both nano and the token in the same block) Accounts would only be able to receive tokens if the corresponding send block had the same token contract address. The only exception to this is if the account has no token balance whatsoever, in which case it could receive tokens from any contract address and that would allow the contract address to change.

How are token contracts created? New accounts, in their open block, can designate that the receipt of the open amount in nano be instead delegated to being a token with the very same account being the contract address. That account then holds the tokens for their contract and may distribute it at their discretion.

How would this work in practice?

Say you want to create an asset-backed wrapped Bitcoin, and you want the supply to be 10,000 (10^4) BTC. Since 1BTC=10^8 sats, 10,000 BTC is 10^4*10^8=10^12 sats.

To create this, all you need to do is make a new account, send it 10^12 raw (which is a mere 1/10^18 nano), and on the open block designate it as a token account. That account now has 10^12 token-raw (taw? Name can be workshopped) that it can distribute as needed.

What are the benefits of this implementation?

Low increase of storage requirement for nodes: the use of just two fields doesn’t massively change the size of a block. By permitting only one token contract per account, you don’t have to worry about keeping track of a million different tokens.

Pruning-resistant: the fact that sending is purely based on the token balance of the frontier (just like nano) means you don’t have to worry about whether or not you can trace to a genesis.

Prevents permanent loss of tokens: although an account can only hold one token at a time, the fact that the contract address the account uses can change if it holds no tokens means that sending the wrong type of token doesn’t make them lost forever. Say your nano account has a wrapped Bitcoin as its token, but you accidentally sent wrapped ethereum to it. To recover the wrapped ethereum, you can make a new account with wrapped Bitcoin as its token, send all your wrapped Bitcoin to it, and now that your token balance is zero, you can change your first account’s token contract and receive the pending wrapped ethereum.

Adds additional value to nano: even though the Bitcoin example only costs 10^12 raw, making lower value tokens with many digits of precision will cost more nano to create it. With this implementation, not only do you need to own nano to create contracts, the total supply of nano will go down over time as more contracts are created; both of these add value to nano.

Can be atomically swapped without trust: this implementation works with my Trustless Swap procedure.

Does not require a massive change to the current state of nano: all existing accounts can be considered to have a token balance of zero with a null contract address, which would allow a seamless transition to the new block format.

I would love to hear any thoughts/criticisms about this possible implementation!

Edit: another benefit is that the inability to set your contract address to anything random is that it prevents the ledger from being used to store unrelated data, a concern raised by NF about implementations that allow for that.


I read this and your other recent proposal on tokens and NFT possibilities with Nano and wanted to thank you. I'm not an expert in this field, but just wanted to add that sometimes the push back from people on reddit is that Nano shouldn't complicate with tokens, nfts, smart contracts, etc. That these can slow the network, diverts resources, and the focus should just be on one thing and doing it well. I understand those arguments and even generally agreed with those premises; however, I am starting to realize more the significant downsides of that thinking when considering that a use case for Nano frequently discussed is micro-transactions.
We can see how this lack of support for tokens is affecting Nano adoption with a concrete example, the fun Nano Royale game. For any that don't know, this recent game provided Nano to win in a free faucet or in a low stakes games. However, the game migrated recently to its own token on the Harmony blockchain. I don't blame the game developers for wanting their own branded token and the ability to possibly offer NFT's in the future. However, as a Nano supporter I also see adoption we had lost.

As discussed on Discord:

If the open block of a contract address is the only time a "token" is minted, then this forces wrapped assets to be minted from many different contract addresses. This means you and I trading the same wrapped asset, but with different contract addresses, will have to create new accounts (because each account can only reference one contract address). Trading between many users would lead to an explosion of accounts.

To get around this, let's allow that contract address to continue minting new wrapped assets. I would recommend focusing on the wrapped asset use case, as that seems far more useful to me than arbitrary tokens.


I think that makes sense. Tokens could be built on networks like ethereum where it can have far more functionality, but fast, green, and feeless trading of the coins could happen on nano.

Not to mention the possibilities for fiat-backed stablecoins! Let’s say any account with their own account as their contract can publish a “mint/unmint” block, which can be used to convert raw to tokens and vice versa. Do you think that would largely solve the account bloat issue?

Also if needed, I suppose you could have multiple contract balances. You probably would want to set a hard limit on tokens per account though. Not sure what the balance between bloat from new accounts and bloat from larger blocks would be though. I suppose it depends on both data size and median number of tokens desired per account.

Are you talking about a "colored coins" method?

This is interesting. I don't see why you couldn't create 10^12 raw and call it a token. I know something came up like this with "wrapped Nano", but I think the issue there was the centralization of Nano that it would lead to? Not sure. Here, everything stays in the ecosystem. That's cool.

Not too sure about the Trustless Swap Procedure. Doesn't that change of fork lead to uncertainty of hash conditions being met in the right order? Is that a chance of fork or not?

Well, I don't like it. Main issue is Nano's security model and/or its main goal gets compromised. Here, we use some low amounts of Nano to mint ("color") tokens. They will most likely bear some kind of monetary value if this system becomes popular. Now, Nano's security model requires that value in the system is used in the vote. However, you can not vote with these tokens, meaning it is entirely possible that most of the value is in entirely different hands than most of the Nanos. Say, next step we publish some "wrapped Nano" token, pegged 1:1 with Nano but can be (interoperable, fed into some smart contract, etc). Everybody gets wrapped Nanos, because why they ever wouldn't. And boom, ORV consensus suddenly compromised.

You can, indeed, market Nano as "governance" token of this new system, but it is a complete derail of the initial goal.

I love the idea, but the implementation needs to be different. Most likely L2.

I mean why exactly WOULD everyone want nano wrapped on another chain? You can't transfer it instantly for free on other chains.

Anyways, say I make some super-duper-private-Nano on this chain and it becomes really popular. Or say I make wrapped Bitcoin on this chain (and in an unlikely turn of events everybody decides that Lightning sucks and moves to this new solution).

Then, most of the monetary value of the chain is not contained in Nano, and it ends up as this weird governance token which secures the system instead of being the medium of exchange...

If this ever gets implemented, I'm forking out