We know that BTC’s inscription carries data through utxo, and EVM’s inscription carries data through calldata in ETH transfer, and then uses an offline indexer to identify user operations and balance information. But these don’t seem to work in Starknet. Because Starknet is the layer 2 of ETH, and ETH is a contract on Starknet, transfers require operating the contract and cannot carry data. As a result, many people use smart contracts to store json data and try to use hot spots to charge fees. The transaction fee is high and you have to pay additional fees, which loses the meaning of the inscription.
If we want to implement the inscription protocol on Starknet, how should we do it? First of all, only smart contracts can be used because there are no EOA accounts on Starknet; Secondly, the smart contract must be extremely simple and cannot perform too many calculations or storage, so as to minimize on-chain operation fees and put complex calculations and storage off-chain.
Therefore, we designed the following contract model:
#[derive(Drop, starknet::Event)]
struct Ins {
ins: Array<felt252>,
from: starknet::ContractAddress,
to: starknet::ContractAddress }
fn inscription(ref self: ContractState, ins: Array<felt252>, to: starknet::ContractAddress){
self.emit(Ins { ins: ins, from: starknet::get_caller_address(), to: to });
}
Yes, it has only one event (the cost of throwing an event is extremely low, which is convenient for large-scale adoption), which is used to throw out the user’s inscription information, operation address, and to address for offline indexers to retrieve and calculate.
Contract on starknet mainnet: 0x0600386e4cd85d7bb925892b61b14ff019d3dd8e31432f4b97c8ee2462e0375d
About the inscription protocol, we can called SNSC-20.
SNSC is mean Starknet Inscription. SNSC-20 is a novel standard, designed to integrate the equitable distribution principles of inscriptions with the Starknet ecosystem.
Key Functions
1.Deploy: Initialize SNSC-20 tokens with specific parameters.
2.Mint : Generate SNSC-20 tokens to be distributed to users.
3.Transfer : Facilitate the movement of SNSC-20 tokens between wallets.
State Management
1.Deployments : Serve as the initialization step for SNSC-20 tokens but do not alter the state.
2.Mints: Assign SNSC-20 tokens to the initial owner of the mint function, marking the beginning of its state.
3.Transfers : Adjust balances by deducting from the sender and crediting the receiver.
Notes
1.Ticker Uniqueness : Initial deployment of a ticker secures its exclusivity within the SNSC-20 ecosystem, preventing any duplications.
2.Event Prioritization : For concurrent events, the order of processing is determined by their confirmation sequence in a block, ensuring a systematic and fair transaction sequence.
3.Fair Distribution Approach : The ‘first come, first served’ policy, particularly in public minting, upholds equitable access and distribution.
4.State Changes : Balances are adjusted solely through the mint and transfer functions, ensuring controlled and transparent token movements.
5.Minting Oversubscription Protocol : If a mint request exceeds the maximum supply, only a proportionate amount is minted. Example: A request to mint 1,000 tokens with a total supply nearing the 21,000,000 cap will result in only 678 tokens being minted.
6.Decimal Consistency : All SNSC-20 tokens adhere to a uniform decimal precision of 18 for standardization.
7.Data Type Restrictions : Transactions and balances within SNSC-20 conform to a uint128 limitation for efficiency and range balance.
8.Maximum Supply Limit: The upper limit for any token’s supply is governed by the uint64_max , preventing overgeneration of tokens.
9.Lower-case Formatting : All elements, including tickers and operational codes, are to be in lower-case to avoid inconsistencies.
10.Exclusion of Multi-Calls : In a block, duplicate mint of an address is only counted once.
11.Transfer Function Mechanics : During a transfer, the sender’s balance is decreased, and the receiver’s balance is correspondingly increased. This ensures a clear transfer of token ownership and balance adjustment, maintaining the integrity of the transaction process.
Operations
Deploy SNSC-20
{“p”:“snsc-20”,“op”:“deploy”,“tick”:“stark”,“max”:“210000000”,“limit”:“1000”,“dec”:“18”,“blimit”:“5”, “tlimit”:“10000”}
| Key | Required? | Description |
|---|---|---|
| p | Yes | Protocol: Helps other systems identify and process SNSC-20 events |
| op | Yes | Operation: Type of event |
| tick | Yes | Ticker: letters identifier of the SNSC-20 |
| max | Yes | Max supply: set max supply of the SNSC-20 |
| limit | Yes | Mint limit: If letting users mint to themselves, limit per transaction |
| dec | no | Decimals: set decimal precision.default to 18 |
| blimit | no | Mint limit: one user limit per block, default to 0 means no limit |
| tlimit | no | Mint limit: one user total limit, default to 0 means no limit |
Mint SNSC-20
{“p”:“snsc-20”,“op”:“mint”,“tick”:“stark”,“amt”:“1000”}
| Key | Required? | Description |
|---|---|---|
| p | Yes | Protocol: Helps other systems identify and process SNSC-20 events |
| op | Yes | Operation: Type of event |
| tick | Yes | Ticker: letters identifier of the SNSC-20 |
| amt | Yes | Amount to mint: States the amount of the SNSC-20 to mint. Mint no more than “limit” above if stated |
Transfer SNSC-20
{“p”:“snsc-20”,“op”:“transfer”,“tick”:“stark”,“amt”:“100”}
| Key | Required? | Description |
|---|---|---|
| p | Yes | Protocol: Helps other systems identify and process SNSC-20 events |
| op | Yes | Operation: Type of event |
| tick | Yes | Ticker: letters identifier of the SNSC-20 |
| amt | Yes | Amount to transfer: States the amount of the SNSC-20 to transfer. |
ps: tlimit is the latest addition, suggested by mini_cat
See detail on https://snsc-20.gitbook.io/snsc-20-standard/
