-
Notifications
You must be signed in to change notification settings - Fork 13
Address Tracker Tokens
Address-Tracker Tokens is a PeerAssets extension allowing tokens (working title: "AT Tokens") which track a specific address. It allows the issuance of AT tokens to all addresses which have spent coins to that address. It can be used in a decentralized way as a Proof of Burn token, or as a simple, centralized Proof of Donation or Proof of Investment token.
WARNING: Address-Tracker Tokens is still alpha-quality software. Do not use for productive purposes, as the rules of the tokens can still change. It is recommended to use it only on Testnet until beta launch.
Note: For the trustless proof-of-donation concept which involves voting look at the Trustless Donation Tracker Token (also called Proof of Donation token) draft.
(Note: This document has been updated in March 2023 to reflect the latest state of this software.)
- Simple Proof of Donation tokens (with centralized funds management, but trustless distribution)
- Proof of Burn tokens: the tracked address can be unspendable, so "destroying" coins becomes rewarded by a token
- ICOs, where the tokens are automatically assigned after buying them (without intervention of the ICO issuer)
In PeerAssets terminology, a deck is a token or asset currency, i.e. not an individual token but the ecosystem comprising the rules of this token. (To compare, an ERC20 token like the Chainlink Token would be called a "deck").
Individual transactions involving tokens are called cards.
To create an AT token, an user has to first create an AT deck. This creates a transaction on the blockchain specifying the rules of the token. There are currently two things that can be defined when creating a deck:
- the tracked address
- a multiplier. This allows to create tokens where you receive a multiple of the coins for your donation. For example, a coin with a multiplier of 1000 allows a person which donated 0.1 coins to issue 100 tokens.
AT decks allow users that send coins to the tracked address (described here as donation transactions) to issue units of the token (cards) via a card issue transaction. The units can be freely used for payments like coins. Card transactions are on-chain transactions.
In a card issue transacion, the user has to reference the txid and the vout (output) which spends the coins to the tracked address. The vout is automatically added by the client.
Double spends are prevented by PeerAsset's Proof of Timeline system. This method uses a strict first come first serve approach: always the first transaction in the blockchain spending certain cards (first block, in the case of the same block, first transaction in block tx list) becomes valid and all others are invalid (bogus in PeerAssets terminology). (To give an example of a conflict situation: If an user owns 100 cards and creates 3 transactions of 40 cards in the same block, the last one is completely invalid even if it would spend 20 "valid" tokens, but the 20 tokens above the balance invalidate it).
The same mechanism is used to prevent an user is trying to create a double card issue transaction - i.e. he is trying to issue cards multiple times using the same donation transaction. In this case, again, always only the first issue transaction is valid, while all others, and all cards transactions that are based on it, become bogus.
AT tokens have some characteristics that makes them different to many competitors (e.g. ERC20 tokens):
- They are trustless and do not really have an "owner". Once they are created, the rules are basically set in stone. The deck issuers (persons who launch the token) have no special rights. They cannot create additional units, add other addresses, or change the multiplier.
- They are not "distributed" by the creators of the token in the form of a smart contract with a loop "reacting" to transactions. Instead, the system allows the donors/PoB minters/investors to create an amount of tokens proportional to the transaction amount. There are two advantages with this approach:
- There is no smart contract language with loops involved.
- The token creator cannot run "out of gas", because the creation of the tokens is done by the donors/PoB minters/investors themselves. They pay transacion fees for the card issue transaction, but they can use this transaction to make a payment, even multiple payments to multiple addresses, so the fees are not wasted.
The disadvantage is that the check necessary to see that a person is entitled to use a token, has to be performed each time a token is received. In tokens with less than hundreds of thousands of transactions this does not compromise resource usage very much. But a simple system to store and query valid transactions (without a complex database, in contrast to systems like Counterparty), together with checkpoints (block hashes) of the chain tip where they're valid, is planned to be able to decrease the resource load.
(Note: The original idea included plans for a second mode, where donors would compete for block rewards. This mode would have used a system which resembles the Follow the Satoshi concept. At this moment (2023) this system has not been developed.)
The software stack needs the following extensions:
- PACLI extensions. To use the command-line client comfortably with AT tokens, the functionality has been extended by some methods allowing uncomplicated issuance of AT assets, but also dealing with different addresses (the original PACLI only allows one address by account).
- PeerAsset extensions:
- Custom parser, which controls the validity of AT token issuances. (at_parser.py)
- Methods to identify AT tokens. (at_identify.py)
- Tests (at_tests.py)
See the Manual for installation and usage instructions.