Is there a way to build a viable fungible distribution scheme on top of this PIN protocol?

[Solarizable]

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.

[riverrun46]

Sounds dope! Any suggestions?

[Solarizable]

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

Deploy

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"
  }
}

[Solarizable]

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

[Solarizable]

Difficulty (Minting Qualification)

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).

[Solarizable]

Minting

Pin Path: /ft/mrc20/mint

When minting, a PIN must be provided as input

{
	"id": "479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0",
	"pin": "b7b249446b6e0ac3e872bf2f16925a2f1a35f8401badf609c31217446e936862i0"
}

• I think it's worth noting that the minted amount goes to the first satoshi of the first output of the transaction.
  The validity of the minting is determined by the indexer service, which verifies the minting transaction according to the pop rules.
• During minting, a valid PIN must be provided to complete the PoP mechanism verification
• Only one type of tick can be minted at a time.

[Solarizable]

Transfer

This could have 2 types of transfer rules.

Native Transfer (Direct Transfer)

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.

[Solarizable]

Data Transfer (MRC20 Allocation)

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.

• If the allocation in the OP_RETURN exceeds the total amount in the input, the allocation is considered invalid, and the default direct transfer principle is used, where all MRC balances are transferred to the first non-OP_RETURN output.
• Balances in inputs that are not allocated will be automatically assigned to the first non-OP_RETURN output.
• If there are no OP_RETURN outputs, then all MRC20 balances are automatically assigned to the first output.
• Other unrecognized OP_RETURN formats are considered invalid, and the MRC20 balances in this transaction will be transferred to the first output.
• MRC20 tokens are identified by a unique ID, where different token IDs represent different tokens.

[Solarizable]

Teleport (Cross-Chain Transfer)

[
  {
    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.

[Solarizable]

So here are all the thoughts. What do you guys think?