Open Solarizable opened 4 months ago
Sounds dope! Any suggestions?
OK, here's my thought.
First of, we can call such solution MRC-20 proposal, similar to ERC20. The deploy & mint part could be similar to the data structure of a normal MetaID PIN. Like so
Pin Path: /ft/mrc20/deploy
{
"tick": "satoshi", // no less than 4 characters
"tokenName": "SatoshiTheLegend", // token full name
"decimals": "8",
"amtPerMint": "1000",
"mintCount": "100",
"blockheight": "123456", // begin block height
"metadata"?: "" // optional; can provides more information about the token like name, links, image, etc
"qual": { // qualifier
paths: ["/follow"],
lvl: "4", // 0~n
}
}
{
"tick": "mrctest",
"tokenName": "mrctest",
"decimals": "8",
"amtPerMint": "1000",
"mintCount": "100",
"blockheight": "123456",
"metadata":"",
"type": "pop",
"qual": {
"lvl": "1"
}
}
After a valid initial transaction, this tick will be assigned a unique ID that is used to identify the MRC20 token. We can use pinId as mrc20id here.
As for tick
, it should not be unique universally.
totalSupply = amtPerMint * mintCount
I have an idea about minting qualification. We can use the PIN as a difficulty criteria. For example, use a concept called Proof-of-Pin (PoP), which combines the user's PIN with the block in which it is included to generate a hash representing the current random hash. During minting, based on the difficulty level (qual.lvl) set during deployment, it is determined how many leading zeros the PoP value must have to be considered valid. If you include the qual.paths parameter, then the provided PIN needs to be verified to check if it belongs to the specified path (or a part of the path array).
Pin Path: /ft/mrc20/mint
When minting, a PIN must be provided as input
{
"id": "479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0",
"pin": "b7b249446b6e0ac3e872bf2f16925a2f1a35f8401badf609c31217446e936862i0"
}
This could have 2 types of transfer rules.
When the input contains MRC-Utxo and the transaction does not specify transfer data (OPRETURN or taproot data), all MRC balances are transferred to the first non-OPRETURN output.
Data transfer writes an OP_RETURN
output or a Taproot script as its data carrier.
[
{
amount: '100',
vout: 0,
id: '479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0', // 'token1'
type?: 'transfer' // optional, defaults to transfer;
},
{
amount: '256',
vout: 3,
id: 'bcccd98a7a1250f26b57d47cfdd36a95866d4bee59c32c9d4e71a6cc1f3429a5i0', // 'token2'
},
{
amount: '300',
vout: 3,
id: '479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0', // 'token1'
},
]
In the above transfer transaction, 100 token1 are allocated to index:0 output; 256 token2 are allocated to index:3 output; 300 token1 are allocated to index:3 output.
OP_RETURN
output.OP_RETURN
outputs, then all MRC20 balances are automatically assigned to the first output.[
{
amount: '100',
id: '479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0', // 'token1'
coord: 'bcccd98a7a1250f26b57d47cfdd36a95866d4bee59c32c9d4e71a6cc1f3429a5i2' // Teleportation coordinates, using pinId structure to locate utxo
type: 'teleport',
},
]
We can use a mechanism to transfer across different networks. Teleport
would be a cool name.
Teleport implements the cross-chain functionality of MRC20; it can be considered as an extension of transfer. While transfer allocates MRC20 balances to outputs within the same chain, teleportation allocates balances to outputs in other chains.
The coord (coordinates) use the ${txid}i${vout} format from the target chain to locate the destination utxo.
A teleport can coexist with transfer within the same transaction, with a higher allocation priority than transfer.
So here are all the thoughts. What do you guys think?
Hello fellows, I read through the MetaID documentation and I think the PIN idea is awesome. I'm wondering is it possible to build a fungible distribution solution on top of this protocol? It could largely expand the use cases & possibilities of the protocol.