Badge Introduction
Powered by the BSV (Bitcoin Satoshi Version) public blockchain, Badge is in-house developed by Dotwallet for issuing FT tokens, such as DotWallet’s DP, and BOEX, as well as NFT tokens, such as digital items in ForeverRealm app.
The BSV blockchain is a global public blockchain with low cost, large capacity and other characteristics. The tokens issued on it can be quickly circulated globally with large scale and low cost, and without being restricted to any central organization, which greatly increases the efficiency of value transmission.
Badge Introduction
Powered by the BSV (Bitcoin Satoshi Version) public blockchain, Badge is in-house developed by Dotwallet for issuing FT tokens, such as DotWallet’s DP, and BOEX, as well as NFT tokens, such as digital items in ForeverRealm app.
The BSV blockchain is a global public blockchain with low cost, large capacity and other characteristics. The tokens issued on it can be quickly circulated globally with large scale and low cost, and without being restricted to any central organization, which greatly increases the efficiency of value transmission.
Characteristics
Low cost
The BSV public blockchain has low transaction fees, which is less than RMB 0.01 for each Badge transfer.
High concurrency
UTXO model is adopted, under this model, all transactions can be concurrent.
Decentralized
The receiver can independently verify the validity of the transaction without trusting the results given by a third party.
Independent issuance
Any entity can issue Badge without the need for a centralized structure or alliance network license.
Easy to verify
PUSH_TX technology is adopted. You only need to trace back the transaction link to the first transaction to verify Badge security.
Destroyable
Use P2PKH to set Vout to destroy Badge.
Traceable
It can trace back the blockchain to restore the full ledger and obtain historical records.
Hard to be sent by mistake
Non P2PKH script. It will not be sent out as ordinary transactions by wallet operators.
NFT unique characteristics
Atomic swaps
In the same transaction, money and Badge will be transferred at the same time.
Group
It supports the creation of multiple Badges in the same transaction to form a group.
Characteristics
Low cost
The BSV public blockchain has low transaction fees, which is less than RMB 0.01 for each Badge transfer.
High concurrency
UTXO model is adopted, under this model, all transactions can be concurrent.
Decentralized
The receiver can independently verify the validity of the transaction without trusting the results given by a third party.
Independent issuance
Any entity can issue Badge without the need for a centralized structure or alliance network license.
Easy to verify
PUSH_TX technology is adopted. You only need to trace back the transaction link to the first transaction to verify Badge security.
Destroyable
Use P2PKH to set Vout to destroy Badge.
Traceable
It can trace back the blockchain to restore the full ledger and obtain historical records.
Hard to be sent by mistake
Non P2PKH script. It will not be sent out as ordinary transactions by wallet operators.
NFT unique characteristics
Atomic swaps
In the same transaction, money and Badge will be transferred at the same time.
Group
It supports the creation of multiple Badges in the same transaction to form a group.
How to implement FT version
Use sCrypt tool to develop. The contract code is as follows:
contract Badge{
Ripemd160 pubKeyHash;
constructor(Ripemd160 pubKeyHash){
this.pubKeyHash = pubKeyHash;
}
public function unlock(Sig sig,PubKey pubKey,bytes badgeFlag){
require(badgeFlag == b'6261646765');
require(hash160(pubKey) == this.pubKeyHash);
require(checkSig(sig,pubKey));
}
}Implementation constraints
1. It is not allowed to mix two or more types of token’s UTXO in one transaction, otherwise the Vin will be deemed to be destroyed.
2. Vout Amount cannot be greater than Vin Amount in one transaction, otherwise the Vin is deemed to be destroyed.
2. Vout Amount cannot be greater than Vin Amount in one transaction, otherwise the Vin is deemed to be destroyed.
Auxiliary tools
The open source Badge verification tool - TouchStone.
TouchStone service provides functions such as sending transactions, querying Badge transaction history and balance, and assembling transactions:
1. Anyone who initiates a Badge transaction can send the transaction to TouchStone service through Restful API, and TouchStone service will update the UTXO collection and synchronize the transaction with other Peer entities so that the status of all Peer entities are synchronized;
2. Anyone who receives a Badge transaction can send the transaction to TouchStone service through Restful API. TouchStone service will determine whether the transaction is legal or not and then execute step 1;
3. Anyone who initiates a badge token transaction can query the available UTXO collection through TouchStone service;
Each Badge receiver can run TouchStone service, and each TouchStone service can configure Peer IP to form an alliance.
TouchStone service provides functions such as sending transactions, querying Badge transaction history and balance, and assembling transactions:
1. Anyone who initiates a Badge transaction can send the transaction to TouchStone service through Restful API, and TouchStone service will update the UTXO collection and synchronize the transaction with other Peer entities so that the status of all Peer entities are synchronized;
2. Anyone who receives a Badge transaction can send the transaction to TouchStone service through Restful API. TouchStone service will determine whether the transaction is legal or not and then execute step 1;
3. Anyone who initiates a badge token transaction can query the available UTXO collection through TouchStone service;
Each Badge receiver can run TouchStone service, and each TouchStone service can configure Peer IP to form an alliance.
How to implement FT version
Use sCrypt tool to develop. The contract code is as follows:
contract Badge{
Ripemd160 pubKeyHash;
constructor(Ripemd160 pubKeyHash){
this.pubKeyHash = pubKeyHash;
}
public function unlock(Sig sig,PubKey pubKey,bytes badgeFlag){
require(badgeFlag == b'6261646765');
require(hash160(pubKey) == this.pubKeyHash);
require(checkSig(sig,pubKey));
}
}Implementation constraints
1. It is not allowed to mix two or more types of token’s UTXO in one transaction, otherwise the Vin will be deemed to be destroyed.
2. Vout Amount cannot be greater than Vin Amount in one transaction, otherwise the Vin is deemed to be destroyed.
2. Vout Amount cannot be greater than Vin Amount in one transaction, otherwise the Vin is deemed to be destroyed.
Auxiliary tools
The open source Badge verification tool - TouchStone.
TouchStone service provides functions such as sending transactions, querying Badge transaction history and balance, and assembling transactions:
1. Anyone who initiates a Badge transaction can send the transaction to TouchStone service through Restful API, and TouchStone service will update the UTXO collection and synchronize the transaction with other Peer entities so that the status of all Peer entities are synchronized;
2. Anyone who receives a Badge transaction can send the transaction to TouchStone service through Restful API. TouchStone service will determine whether the transaction is legal or not and then execute step 1;
3. Anyone who initiates a badge token transaction can query the available UTXO collection through TouchStone service;
Each Badge receiver can run TouchStone service, and each TouchStone service can configure Peer IP to form an alliance.
TouchStone service provides functions such as sending transactions, querying Badge transaction history and balance, and assembling transactions:
1. Anyone who initiates a Badge transaction can send the transaction to TouchStone service through Restful API, and TouchStone service will update the UTXO collection and synchronize the transaction with other Peer entities so that the status of all Peer entities are synchronized;
2. Anyone who receives a Badge transaction can send the transaction to TouchStone service through Restful API. TouchStone service will determine whether the transaction is legal or not and then execute step 1;
3. Anyone who initiates a badge token transaction can query the available UTXO collection through TouchStone service;
Each Badge receiver can run TouchStone service, and each TouchStone service can configure Peer IP to form an alliance.
How to implement NFT version
Use sCrypt tool to develop. The contract code is as follows:
import "util.scrypt";
contract Nft {
public function unlock(Sig sig, PubKey senderPubKey, SigHashPreimage txPreimage, Ripemd160 p2pkhReceiver1, int p2pkhAmount1, Ripemd160 nftReceiver, int nftAmount, Ripemd160 p2pkhReceiver2, int p2pkhAmount2, Ripemd160 p2pkhReceiver3, int p2pkhAmount3) {
bytes lockingScript = Util.scriptCode(txPreimage);
int scriptLen = len(lockingScript);
int pubkeyHashStart = scriptLen - Util.PubKeyHashLen;
Ripemd160 senderPubkeyHash = Ripemd160(lockingScript[pubkeyHashStart :]);
bytes codePart = lockingScript[: pubkeyHashStart];
bytes outputs = b'';
if (p2pkhAmount1 > 0) {
bytes outputScript = Util.buildPublicKeyHashScript(p2pkhReceiver1);
bytes output = Util.buildOutput(outputScript, p2pkhAmount1);
outputs += output;
}
if (nftAmount > 0) {
bytes outputScript = codePart + nftReceiver;
bytes output = Util.buildOutput(outputScript, nftAmount);
outputs += output;
}
if (p2pkhAmount2 > 0) {
bytes outputScript = Util.buildPublicKeyHashScript(p2pkhReceiver2);
bytes output = Util.buildOutput(outputScript, p2pkhAmount2);
outputs += output;
}
if (p2pkhAmount3 > 0) {
bytes outputScript = Util.buildPublicKeyHashScript(p2pkhReceiver3);
bytes output = Util.buildOutput(outputScript, p2pkhAmount3);
outputs += output;
}
Sha256 hashOutputs = hash256(outputs);
require(hashOutputs == Util.hashOutputs(txPreimage));
require(hash160(senderPubKey) == senderPubkeyHash);
require(checkSig(sig, senderPubKey));
require(Tx.checkPreimage(txPreimage));
}
}It restricts the transfer of Badge NFT. In addition to get the owner’s public key and signature, it must also ensure that the format of Vout is consistent with the locking script in the previous transaction, so as to ensure the continuity and unforgeability of Badge NFT contract. In the unlocking script, there are four inputs, namely P2PKH (denoted as P1), NFT (denoted as N1), P2PKH (denoted as P2), P2PKH (denoted as P3).
Corresponding to the following scenarios:
Corresponding to the following scenarios:
| No. | Activity | P1 | N1 | P2 | P3 |
| 1 | Transfer | No | Yes | Yes | No |
| 2 | Listing | Yes （sigtype_single） | Yes | No | Determined by whether it needs change or not |
| 3 | Listing （with platform commission） | Yes （sigtype_single） | Yes | Yes | Determined by whether it needs change or not |
| 4 | Destroy | Yes | No | No | Determined by whether it needs change or not |
Implementation constraints
1. When issuing Badge NFT, the same group of Badge NFT must follow after Vout0, no OP_RETURN operator can be inserted in the middle.
2. Two or more OP_RETURNs are not allowed at the time of issuance.
3. The OP_RETURN of the issuance transaction can be written into metadata describing the Badge NFT.
4. Badge NFT sent to P2PKH is deemed to destroy NFB.
5. When multiple Badge NFTs are sent to one Badge NFT at the same time, it is deemed to be destroyed.
6. After receiving Badge NFT, it is necessary to trace back from the current transaction to the genesis transaction to prove that the transaction has not been forged.
In the actual operation process, wallet operators can verify on behalf of users.
2. Two or more OP_RETURNs are not allowed at the time of issuance.
3. The OP_RETURN of the issuance transaction can be written into metadata describing the Badge NFT.
4. Badge NFT sent to P2PKH is deemed to destroy NFB.
5. When multiple Badge NFTs are sent to one Badge NFT at the same time, it is deemed to be destroyed.
6. After receiving Badge NFT, it is necessary to trace back from the current transaction to the genesis transaction to prove that the transaction has not been forged.
In the actual operation process, wallet operators can verify on behalf of users.
How to implement NFT version
Use sCrypt tool to develop. The contract code is as follows:
import "util.scrypt";
contract Nft {
public function unlock(Sig sig, PubKey senderPubKey, SigHashPreimage txPreimage, Ripemd160 p2pkhReceiver1, int p2pkhAmount1, Ripemd160 nftReceiver, int nftAmount, Ripemd160 p2pkhReceiver2, int p2pkhAmount2, Ripemd160 p2pkhReceiver3, int p2pkhAmount3) {
bytes lockingScript = Util.scriptCode(txPreimage);
int scriptLen = len(lockingScript);
int pubkeyHashStart = scriptLen - Util.PubKeyHashLen;
Ripemd160 senderPubkeyHash = Ripemd160(lockingScript[pubkeyHashStart :]);
bytes codePart = lockingScript[: pubkeyHashStart];
bytes outputs = b'';
if (p2pkhAmount1 > 0) {
bytes outputScript = Util.buildPublicKeyHashScript(p2pkhReceiver1);
bytes output = Util.buildOutput(outputScript, p2pkhAmount1);
outputs += output;
}
if (nftAmount > 0) {
bytes outputScript = codePart + nftReceiver;
bytes output = Util.buildOutput(outputScript, nftAmount);
outputs += output;
}
if (p2pkhAmount2 > 0) {
bytes outputScript = Util.buildPublicKeyHashScript(p2pkhReceiver2);
bytes output = Util.buildOutput(outputScript, p2pkhAmount2);
outputs += output;
}
if (p2pkhAmount3 > 0) {
bytes outputScript = Util.buildPublicKeyHashScript(p2pkhReceiver3);
bytes output = Util.buildOutput(outputScript, p2pkhAmount3);
outputs += output;
}
Sha256 hashOutputs = hash256(outputs);
require(hashOutputs == Util.hashOutputs(txPreimage));
require(hash160(senderPubKey) == senderPubkeyHash);
require(checkSig(sig, senderPubKey));
require(Tx.checkPreimage(txPreimage));
}
}It restricts the transfer of Badge NFT. In addition to get the owner’s public key and signature, it must also ensure that the format of Vout is consistent with the locking script in the previous transaction, so as to ensure the continuity and unforgeability of Badge NFT contract. In the unlocking script, there are four inputs, namely P2PKH (denoted as P1), NFT (denoted as N1), P2PKH (denoted as P2), P2PKH (denoted as P3).
Corresponding to the following scenarios:
Corresponding to the following scenarios:
| No. | Activity | P1 | N1 | P2 | P3 |
| 1 | Transfer | No | Yes | Yes | No |
| 2 | Listing | Yes （sigtype_single） | Yes | No | Determined by whether it needs change or not |
| 3 | Listing （with platform commission） | Yes （sigtype_single） | Yes | Yes | Determined by whether it needs change or not |
| 4 | Destroy | Yes | No | No | Determined by whether it needs change or not |
Implementation constraints
1. When issuing Badge NFT, the same group of Badge NFT must follow after Vout0, no OP_RETURN operator can be inserted in the middle.
2. Two or more OP_RETURNs are not allowed at the time of issuance.
3. The OP_RETURN of the issuance transaction can be written into metadata describing the Badge NFT.
4. Badge NFT sent to P2PKH is deemed to destroy NFB.
5. When multiple Badge NFTs are sent to one Badge NFT at the same time, it is deemed to be destroyed.
6. After receiving Badge NFT, it is necessary to trace back from the current transaction to the genesis transaction to prove that the transaction has not been forged.
In the actual operation process, wallet operators can verify on behalf of users.
2. Two or more OP_RETURNs are not allowed at the time of issuance.
3. The OP_RETURN of the issuance transaction can be written into metadata describing the Badge NFT.
4. Badge NFT sent to P2PKH is deemed to destroy NFB.
5. When multiple Badge NFTs are sent to one Badge NFT at the same time, it is deemed to be destroyed.
6. After receiving Badge NFT, it is necessary to trace back from the current transaction to the genesis transaction to prove that the transaction has not been forged.
In the actual operation process, wallet operators can verify on behalf of users.
Use cases
FT use cases
DP (DotPoint) is issued by DotWallet. It is only applicable to DotWallet system with no investment value. It is mainly used to motivate and give back to users, which can be accumulated. DotWallet team can increase or decrease the volume according to the real situation.
BOEX is a platform token issued by BOEX exchange to encourage users to use BOEX application. BOEX adopts a dual distribution mechanism of POS and POW, which represents the contribution of users to the BOEX application. Total issuance: 30 billion pieces, with smart contracts on the chain to ensure that there will never be additional issuance.
Use cases
FT use cases
DP (DotPoint) is issued by DotWallet. It is only applicable to DotWallet system with no investment value. It is mainly used to motivate and give back to users, which can be accumulated. DotWallet team can increase or decrease the volume according to the real situation.
BOEX is a platform token issued by BOEX exchange to encourage users to use BOEX application. BOEX adopts a dual distribution mechanism of POS and POW, which represents the contribution of users to the BOEX application. Total issuance: 30 billion pieces, with smart contracts on the chain to ensure that there will never be additional issuance.
NFT use cases
Foreverrealm
ForeverRealm is a trading platform for encrypted commodities of all categories where user can create and collect encrypted artworks. Powered by the blockchain technology, it carries out a revolution in the art world and is committed to creating an encrypted art ecosystem for everyone to participate.
Follow-up will continue to support multiple applications, welcome the masses of developers use this agreement
NFT use cases
Foreverrealm
ForeverRealm is a trading platform for encrypted commodities of all categories where user can create and collect encrypted artworks. Powered by the blockchain technology, it carries out a revolution in the art world and is committed to creating an encrypted art ecosystem for everyone to participate.
Follow-up will continue to support multiple applications, welcome the masses of developers use this agreement
Contact us
developers@dotwallet.com
Contact us
developers@dotwallet.com
