[SNIP] SNSC-20 Starknet Inscription Standard Protocol

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.


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.


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


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


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/

Hi. Great achievement, thank you!

How to see the balance of snsc-20 stark ticker token?

The inscription also involves the issue of fairness, as many people use scripts to mint very quickly. I suggest adding a limit to the protocol, such as a limit on the number of addresses and mints, in order to allow more people to participate in mints

Yes, your suggestion is good. In addition to the block limit, add a total limit, such tlimit may be better

U can see u balance in snsc-20.com, U can also using u own Indexer to check the balance.
BTW, Our Indexer may open source on github tomorrow.

stark ticker showing 21,000,000,000, but it’s 21,000,000 in reality:

tick num is 21,000,000, 1000 token per one tick, so the total supply is 21,000,000,000

Where can we see the results?
Such as: starkscan.co ?

If you mean onchain data, you can see on starknet scan, if you mean balance, you need a indexer, or go to the snsc-20.com to check

So basically it needs 21kk txs to mint ‘stark’ fully?