Deposits
Depositing fungible tokens (NEP-141), including wrapped NEAR
The Verifier contract implements the FungibleTokenReceiver interface, part of the NEP-141 standard.
To deposit tokens into the Verifier contract, users must call the function ft_transfer_call
(see the function signature here) on the token, with an msg
parameter specifying information about the user, whose account will be assigned as the owner of the tokens.
Format of msg
parameter to assign ownership of tokens inside the Verifier contract
msg
parameter to assign ownership of tokens inside the Verifier contractThe msg
parameter must follow a specific format to ensure proper token deposit within the contract. The msg
parameter supports three formats:
It can be empty, with size 0 bytes, which will assign ownership to the sender of the transaction (i.e., the predecessor in NEAR terminology)
A simple string that contains an account id, for example
alice.near
A JSON object, referred to as
DepositMessage
, with the following fields:receiver_id
, a string with an account id taking ownershipexecute_intents
, a list of intents to be executed, right after the deposit is complete.refund_if_fails
, a boolean, whenfalse
(the default), will execute the intents as a detached promise, decoupling any failure during the execution of the intents from the deposit operation.
Examples of ft_transfer_call
parametrization in JSON:
With empty
msg
or non-existingmsg
, granting the tokens to the sender/creator of that transaction
{
receiver_id: "alice.near",
amount: "1000",
}
{
receiver_id: "alice.near",
amount: "1000",
msg: "",
}
With an
msg
that explicitly assigns ownership to another account:
{
receiver_id: "alice.near",
amount: "1000",
msg: "bob.near",
}
With an
msg
that is aDepositMessage
object
{
receiver_id: "alice.near",
amount: "1000",
msg: "{"\"receiver_id\": \"charlie.near\", \"execute_intents\": [...], \"refund_if_fails\": false}\"",
}
or
{
receiver_id: "alice.near",
amount: "1000",
msg: "{"\"receiver_id\": \"charlie.near\", \"execute_intents\": [...]\"",
}
Note: msg is always a string—even when it contains a JSON-encoded object. Proper character escaping is required.
Depositing non-fungible tokens (NEP-171)
The Verifier contract implements the NonFungibleTokenReceiver interface. This is NEP-171 standard.
To transfer NFTs to the Verifier
, use nft_transfer_call
, following the same msg
format rules as for fungible tokens. The msg
parameter dictates how ownership of the transferred tokens will be assigned.
Last updated