Nhảy đến nội dung chính

Avoiding Token Loss

warning

Careful! Losing tokens means losing money!

Token loss có thể xảy ra trong nhiều trường hợp. Các trường hợp này có thể được nhóm thành một vài cấp có liên quan như:

  1. Loại 1: Key Management
  2. Loại 2: Refunds
  3. Loại 3: Function Calls

Improper key management

Improper key management may lead to token loss. Mitigating such scenarios may be done by issuing backup keys allowing for recovery of accounts whose keys have been lost or deleted.

Loss of FullAccess key

A user may lose their private key of a FullAccess key pair for an account with no other keys. Không ai có thể lấy lại số tiền. Tiền sẽ vẫn bị khóa trong tài khoản mãi mãi.

Loss of FunctionCall access key

Một account có thể xoá một và chỉ một FunctionCall access key. Không ai có thể lấy lại số tiền. Tiền sẽ vẫn bị khóa trong tài khoản mãi mãi.


Refunding deleted accounts

When a refund receipt is issued for an account, if that account no longer exists, the funds will be dispersed among validators proportional to their stake in the current epoch.

Deleting account with non-existent beneficiary

When you delete an account, you must assign a beneficiary. Sau khi xóa, biên lai chuyển khoản sẽ được tạo và gửi đến tài khoản người thụ hưởng. Nếu tài khoản người thụ hưởng không tồn tại, biên lai hoàn tiền sẽ được tạo và gửi trở lại tài khoản ban đầu. Vì tài khoản ban đầu đã bị xóa, tiền sẽ được phân chia giữa các validator.

Account with zero balance is garbage-collected, just before it receives refund

If an account A transfers all of its funds to another account B and account B does not exist, a refund receipt will be generated for account A. During the period of this round trip, account A is vulnerable to deletion by garbage collection activities on the network. If account A is deleted before the refund receipt arrives, the funds will be dispersed among validators.


Failed function calls in batches

warning

When designing a smart contract, you should always consider the asynchronous nature of NEAR Protocol.

If a contract function f1 calls two (or more) other functions f2 and f3, and at least one of these functions, f2 and f3 fails, then tokens will be refunded from the function that failed, but tokens will be appropriately credited to the function(s) which succeed.

The successful call's tokens may be considered lost depending on your use case if a single failure in the batch means the whole batch failed.

Was this page helpful?