pub struct FungibleToken {
pub accounts: LookupMap<AccountId, Balance>,
pub total_supply: Balance,
pub account_storage_usage: StorageUsage,
}
Expand description
Implementation of a FungibleToken standard. Allows to include NEP-141 compatible token to any contract. There are next traits that any contract may implement: - FungibleTokenCore – interface with ft_transfer methods. FungibleToken provides methods for it. - FungibleTokenMetaData – return metadata for the token in NEP-148, up to contract to implement. - StorageManager – interface for NEP-145 for allocating storage per account. FungibleToken provides methods for it. - AccountRegistrar – interface for an account to register and unregister
For example usage, see examples/fungible-token/src/lib.rs.
Fields§
§accounts: LookupMap<AccountId, Balance>
AccountID -> Account balance.
total_supply: Balance
Total supply of the all token.
account_storage_usage: StorageUsage
The storage size in bytes for one account.
Implementations§
Source§impl FungibleToken
impl FungibleToken
pub fn new<S>(prefix: S) -> Selfwhere
S: IntoStorageKey,
pub fn internal_unwrap_balance_of(&self, account_id: &AccountId) -> Balance
pub fn internal_deposit(&mut self, account_id: &AccountId, amount: Balance)
pub fn internal_withdraw(&mut self, account_id: &AccountId, amount: Balance)
pub fn internal_transfer( &mut self, sender_id: &AccountId, receiver_id: &AccountId, amount: Balance, memo: Option<String>, )
pub fn internal_register_account(&mut self, account_id: &AccountId)
Source§impl FungibleToken
impl FungibleToken
Sourcepub fn internal_ft_resolve_transfer(
&mut self,
sender_id: &AccountId,
receiver_id: AccountId,
amount: U128,
) -> (u128, u128)
pub fn internal_ft_resolve_transfer( &mut self, sender_id: &AccountId, receiver_id: AccountId, amount: U128, ) -> (u128, u128)
Internal method that returns the amount of burned tokens in a corner case when the sender
has deleted (unregistered) their account while the ft_transfer_call
was still in flight.
Returns (Used token amount, Burned token amount)
Source§impl FungibleToken
impl FungibleToken
Trait Implementations§
Source§impl BorshDeserialize for FungibleToken
impl BorshDeserialize for FungibleToken
fn deserialize_reader<__R: Read>(reader: &mut __R) -> Result<Self, Error>
Source§fn deserialize(buf: &mut &[u8]) -> Result<Self, Error>
fn deserialize(buf: &mut &[u8]) -> Result<Self, Error>
Source§fn try_from_slice(v: &[u8]) -> Result<Self, Error>
fn try_from_slice(v: &[u8]) -> Result<Self, Error>
fn try_from_reader<R>(reader: &mut R) -> Result<Self, Error>where
R: Read,
Source§impl BorshSchema for FungibleToken
impl BorshSchema for FungibleToken
Source§fn declaration() -> Declaration
fn declaration() -> Declaration
Source§fn add_definitions_recursively(
definitions: &mut BTreeMap<Declaration, Definition>,
)
fn add_definitions_recursively( definitions: &mut BTreeMap<Declaration, Definition>, )
Source§impl BorshSerialize for FungibleToken
impl BorshSerialize for FungibleToken
Source§impl FungibleTokenCore for FungibleToken
impl FungibleTokenCore for FungibleToken
Source§fn ft_transfer(
&mut self,
receiver_id: AccountId,
amount: U128,
memo: Option<String>,
)
fn ft_transfer( &mut self, receiver_id: AccountId, amount: U128, memo: Option<String>, )
amount
of tokens from the env::predecessor_account_id
to receiver_id
.
Both accounts must be registered with the contract for transfer to succeed. (See NEP-145)
This method must to be able to accept attached deposits, and must not panic on attached deposit.
Exactly 1 yoctoNEAR must be attached.
See the Security section of the standard. Read moreSource§fn ft_transfer_call(
&mut self,
receiver_id: AccountId,
amount: U128,
memo: Option<String>,
msg: String,
) -> PromiseOrValue<U128>
fn ft_transfer_call( &mut self, receiver_id: AccountId, amount: U128, memo: Option<String>, msg: String, ) -> PromiseOrValue<U128>
amount
of tokens from the env::predecessor_account_id
to receiver_id
account. Then
calls ft_on_transfer
method on receiver_id
contract and attaches a callback to resolve this transfer.
ft_on_transfer
method must return the amount of tokens unused by the receiver contract, the remaining tokens
must be refunded to the predecessor_account_id
at the resolve transfer callback. Read moreSource§fn ft_total_supply(&self) -> U128
fn ft_total_supply(&self) -> U128
Source§fn ft_balance_of(&self, account_id: AccountId) -> U128
fn ft_balance_of(&self, account_id: AccountId) -> U128
"0"
.Source§impl StorageManagement for FungibleToken
impl StorageManagement for FungibleToken
Source§fn storage_withdraw(&mut self, amount: Option<NearToken>) -> StorageBalance
fn storage_withdraw(&mut self, amount: Option<NearToken>) -> StorageBalance
While storage_withdraw normally allows the caller to retrieve available
balance, the basic
Fungible Token implementation sets storage_balance_bounds.min == storage_balance_bounds.max,
which means available balance will always be 0. So this implementation:
- panics if
amount > 0
- never transfers Ⓝ to caller
- returns a
storage_balance
struct ifamount
is 0