Jetton Non-Shard
A new type of Jetton that follows some ERC-20 standard, account balances are stored in hash-map but with limitations
Why Propose
Add additional feature to request account balance in contracts
Add additional feature to add spender for each account
Best For
Safe balance and spender request
Implementing contracts doesn't have to identify the wallet address which causes an additional wallet discovery request to the minter to verify authenticity of the wallet for additional fees
Managing only one contract for mint, transfer and burn
Instantly determine balance of all accounts
No need to get wallet address of each holder
Jetton transactions are track in one contract
Safe Balance & Spender Discovery
Contract sends op::get_balance to Jetton
Jetton forwards op::jetton_balance to Contract
Contract verifies Jetton as sender and process balance value
Limitations
Contract size grows due to balance hash-map
Maximum hash-map balance holder (approx 4k)
1 approved spender per account
Contract
Operations
transfer ->
mint ->
burn ->
approve ->
get_balance -> operation to request the current balance of an account, forwards a balance_of operation to the requestor
jetton_balance -> internal operation forwarded to requesting contract
get_spender -> requests spender address and balance of an account, contract as spender can send transfer operation to minter to move jettons
jetton_spender -> internal operation forwarded to requesting contract
Methods
get_jetton_data
get_balance(account)
get_spender(account)
get_accounts
Last updated