diff --git a/EIPS/eip-6809.md b/EIPS/eip-6809.md index 875717e3dbeb0f..fd4743515b84c9 100644 --- a/EIPS/eip-6809.md +++ b/EIPS/eip-6809.md @@ -1,7 +1,7 @@ --- eip: 6809 title: Non-Fungible Key Bound Token -description: An interface for Non-Fungible Key Bound Tokens, also known as a NFKBT. +description: An interface for Non-Fungible Key Bound Tokens, also known as an NFKBT. author: Mihai Onila (@MihaiORO), Nick Zeman (@NickZCZ), Narcis Cotaie (@NarcisCRO) discussions-to: https://ethereum-magicians.org/t/non-fungible-key-bound-token-kbt/13625 status: Draft @@ -15,43 +15,43 @@ requires: 721 A standard interface for Non-Fungible Key Bound Tokens (**NFKBT/s**), a subset of the more general Key Bound Tokens (**KBT/s**). -The following standardizes an API for tokens within smart contracts and provides basic functionality to the `addBinding`[^1] function. This function designates **Key Wallets**[^2], which are responsible for conducting a **Safe Transfer**[^5]. During this process, **NFKBTs** are safely approved so they can be spent by the user or an on-chain third-party entity. +The following standardizes an API for tokens within smart contracts and provides basic functionality to the [addBindings](#addbindings-function) function. This function designates **Key Wallets**[^1], which are responsible for conducting a **Safe Transfer**[^2]. During this process, **NFKBTs** are safely approved so they can be spent by the user or an on-chain third-party entity. -The premise of **NFKBTs** is to provide fully optional security features built directly into the non-fungible asset, via the concept of _allow_ found in the `allowTransfer`[^3] and `allowApproval`[^4] functions. These functions are called by one of the **Key Wallets**[^2] and _allow_ the **Holding Wallet** to either call the already familier `transfer` and `approve` function found in the [_ERC-721_](./eip-721.md). Responsibility for the **NFKBT** is therefore split. The **Holding Wallet** contains the asset and **Key Wallets** have authority over how the assets can be spent or approved. **Default Behaviors**[^17] of a traditional non-fungible _ERC-721_ can be achieved by simply never using the `addBinding`[^1] function. +The premise of **NFKBTs** is to provide fully optional security features built directly into the non-fungible asset, via the concept of _allow_ found in the [allowTransfer](#allowtransfer-function) and [allowApproval](#allowapproval-function) functions. These functions are called by one of the **Key Wallets**[^1] and _allow_ the **Holding Wallet**[^3] to either call the already familiar `transferFrom` and `approve` function found in [ERC-721](./eip-721.md). Responsibility for the **NFKBT** is therefore split. The **Holding Wallet** contains the asset and **Key Wallets** have authority over how the assets can be spent or approved. **Default Behaviors**[^4] of a traditional non-fungible ERC-721 can be achieved by simply never using the [addBindings](#addbindings-function) function. We considered **NFKBTs** being used by every individual who wishes to add additional security to their non-fungible assets, as well as consignment to third-party wallets/brokers/banks/insurers/museums. **NFKBTs** allow tokens to be more resilient to attacks/thefts, by providing additional protection to the asset itself on a self-custodial level. ## Motivation -TIn this fast-paced technologically advancing world, people learn and mature at different speeds. The goal of global adoption must take into consideration the target demographic is of all ages and backgrounds. Unfortunately for self-custodial assets, one of the greatest pros is also one of its greatest cons. The individual is solely responsible for their actions and adequately securing their assets. If a mistake is made leading to a loss of funds, no one is able to guarantee their return. +In this fast-paced technologically advancing world, people learn and mature at different speeds. The goal of global adoption must take into consideration the target demographic is of all ages and backgrounds. Unfortunately for self-custodial assets, one of the greatest pros is also one of its greatest cons. The individual is solely responsible for their actions and adequately securing their assets. If a mistake is made leading to a loss of funds, no one is able to guarantee their return. -In 2021, the United States Federal Trade Commission received more than 46,000 filed reports of crypto theft valued at over $1 Billion[^16]. Theft and malicious scams are an issue in any financial sector and oftentimes lead to stricter regulation. However, government-imposed regulation goes against one of this space’s core values. Efforts have been made to increase security within the space through centralized and decentralized means. Up until now, no one has offered a solution that holds onto the advantages of both whilst eliminating their disadvantages. +From January 2021 through March 2022, the United States Federal Trade Commission received more than 46,000[^5] crypto scam reports. This directly impacted crypto users and resulted in a net consumer loss exceeding $1 Billion[^6]. Theft and malicious scams are an issue in any financial sector and oftentimes lead to stricter regulation. However, government-imposed regulation goes against one of this space’s core values. Efforts have been made to increase security within the space through centralized and decentralized means. Up until now, no one has offered a solution that holds onto the advantages of both whilst eliminating their disadvantages. We asked ourselves the same question as many have in the past, “How does one protect the wallet?”. After a while, realizing the question that should be asked is “How does one protect the asset?”. Creating the wallet is free, the asset is what has value and is worth protecting. This question led to the development of **KBTs**. A solution that is fully optional and can be tailored so far as the user is concerned. Individual assets remain protected even if the seed phrase or private key is publicly released, as long as the security feature was activated. -**NFKBTs** saw the need to improve on the widely used non-fungible _ERC-721_ token standard. The security of non-fungible assets is a topic that concerns every entity in the crypto space, as their current and future use cases continue to be explored. **NFKBTs** provide a scalable decentralized security solution that takes security one step beyond wallet security e.g. _BIP-39_[^8], focusing on the token's ability to remain secure. The security is on the blockchain itself, which allows every demographic that has access to the internet to secure their assets without the need for current hardware or centralized solutions. Made to be a promising alternative, **NFKBTs** inherit all the characteristics of an _ERC-721_. This was done so **NFKBTs** could be used on every dApp that is configured to use traditional non-fungible tokens. +**NFKBTs** saw the need to improve on the widely used non-fungible ERC-721 token standard. The security of non-fungible assets is a topic that concerns every entity in the crypto space, as their current and future use cases continue to be explored. **NFKBTs** provide a scalable decentralized security solution that takes security one step beyond wallet security, focusing on the token's ability to remain secure. The security is on the blockchain itself, which allows every demographic that has access to the internet to secure their assets without the need for current hardware or centralized solutions. Made to be a promising alternative, **NFKBTs** inherit all the characteristics of an ERC-721. This was done so **NFKBTs** could be used on every dApp that is configured to use traditional non-fungible tokens. During the development process, the potential advantages **KBTs** explored were the main motivation factors leading to their creation; -1. Completely Decentralized: The security features are fully decentralized meaning no third-party will have access to user funds when activated. This was done in order to truly stay in line with the premise of self-custodial assets, responsibility and values. +1. **Completely Decentralized:** The security features are fully decentralized meaning no third-party will have access to user funds when activated. This was done to truly stay in line with the premise of self-custodial assets, responsibility and values. -2. Limitless Scalability: Centralized solutions require the creation of an account and their availability may be restricted based on location. **NFKBTs** do not face regional restrictions or account creation. Decentralized security solutions such as hardware options face scalability issues requiring transport logistics, secure shipping, and vendor. **NFKBTs** can be used anywhere around the world by anyone who so wishes, provided they have access to the internet. +2. **Limitless Scalability:** Centralized solutions require the creation of an account and their availability may be restricted based on location. **NFKBTs** do not face regional restrictions or account creation. Decentralized security solutions such as hardware options face scalability issues requiring transport logistics, secure shipping and vendor. **NFKBTs** can be used anywhere around the world by anyone who so wishes, provided they have access to the internet. -3. Fully Optional Security: Security features are optional, customizable and removable. It’s completely up to the user to decide the level of security they would like when using **NFKBTs**. +3. **Fully Optional Security:** Security features are optional, customizable and removable. It’s completely up to the user to decide the level of security they would like when using **NFKBTs**. -4. Default Functionality: If the user would like to use **NFKBTs** as a traditional _ERC-721_, the security features do not have to be activated. As the token inherits all of the same characteristics, it results in the token acting with traditional non-fungible **Default Behaviours**[^17]. However, even when the security features are activated, the user will still have the ability to customize the functionality of the various features based on their desired outcome. The user can pass a set of custom and or **Default Values**[^18] manually or through a dApp. +4. **Default Functionality:** If the user would like to use **NFKBTs** as a traditional ERC-721, the security features do not have to be activated. As the token inherits all of the same characteristics, it results in the token acting with traditional non-fungible **Default Behaviors**[^4]. However, even when the security features are activated, the user will still have the ability to customize the functionality of the various features based on their desired outcome. The user can pass a set of custom and or **Default Values**[^7] manually or through a dApp. -5. Unmatched Security: By calling the `addBinding`[^1] function a **Key Wallet**[^2] is now required for the `allowTransfer`[^3] or `allowApproval`[^4] function. The `allowTransfer`[^3] function requires 4 parameters, `_tokenId`[^12], `_time`[^13], `_address`[^14], and `_allFunds`[^20], where as the `allowApproval`[^4] function has 2 parameters, `_time`[^21] and `_numberOfTransfers`[^22]. In addition to this, **NFKBTs** have a `safeFallback`[^10] and `resetBindings`[^11] function. The combination of all these prevent and virtually cover every single point of failure that is present with a traditional _ERC-721_, when properly used. +5. **Unmatched Security:** By calling the [addBindings](#addbindings-function) function a **Key Wallet**[^1] is now required for the [allowTransfer](#allowtransfer-function) or [allowApproval](#allowapproval-function) function. The [allowTransfer](#allowtransfer-function) function requires 4 parameters, `_tokenId`[^8], `_time`[^9], `_address`[^10], and `_anyToken`[^11], where as the [allowApproval](#allowapproval-function) function has 2 parameters, `_time`[^12] and `_numberOfTransfers`[^13]. In addition to this, **NFKBTs** have a [safeFallback](#safefallback-function) and [resetBindings](#resetbindings-function) function. The combination of all these prevent and virtually cover every single point of failure that is present with a traditional ERC-721, when properly used. -6. Security Fail-Safes: With **NFKBTs**, users can be confident that their tokens are safe and secure, even if the **Holding Wallet**[^9] or one of the **Key Wallets**[^2] has been compromised. If the owner suspects that the **Holding Wallet**[^9] has been compromised or lost access, they can call the `safeFallback`[^10] function from one of the **Key Wallets**[^2]. This moves the assets to the other **Key Wallet**[^2] preventing a single point of failure. If the owner suspects that one of the **Key Wallets**[^2] has been comprised or lost access, the owner can call the `resetBindings`[^11] function from `_keyWallet1`[^6] or `_keyWallet2`[^7]. This resets the **NFKBTs** security feature and allows the **Holding Wallet**[^9] to call the `addBinding`[^1] function again. New **Key Wallets**[^2] can therefore be added and a single point of failure can be prevented. +6. **Security Fail-Safes:** With **NFKBTs**, users can be confident that their tokens are safe and secure, even if the **Holding Wallet**[^3] or one of the **Key Wallets**[^1] has been compromised. If the owner suspects that the **Holding Wallet** has been compromised or lost access, they can call the [safeFallback](#safefallback-function) function from one of the **Key Wallets**. This moves the assets to the other **Key Wallet** preventing a single point of failure. If the owner suspects that one of the **Key Wallets** has been comprised or lost access, the owner can call the [resetBindings](#resetbindings-function) function from `_keyWallet1`[^15] or `_keyWallet2`[^16]. This resets the **NFKBTs** security feature and allows the **Holding Wallet** to call the [addBindings](#addbindings-function) function again. New **Key Wallets** can therefore be added and a single point of failure can be prevented. -7. Anonymous Security: Frequently, centralized solutions ask for personal information that is stored and subject to prying eyes. Purchasing decentralized hardware solutions are susceptible to the same issues e.g. a shipping address, payment information or a camera recording during a physical cash pick-up. This may be considered by some as infringing on their privacy and asset anonymity. **NFKBTs** ensures user confidentially as everything can be done remotely under a pseudonym on the blockchain. +7. **Anonymous Security:** Frequently, centralized solutions ask for personal information that is stored and subject to prying eyes. Purchasing decentralized hardware solutions are susceptible to the same issues e.g. a shipping address, payment information, or a camera recording during a physical cash pick-up. This may be considered by some as infringing on their privacy and asset anonymity. **NFKBTs** ensure user confidentially as everything can be done remotely under a pseudonym on the blockchain. -8. Low-Cost Security: The cost of using **NFKBTs** security features correlate to on-chain fees, the current _GWEI_ at the given time. As a standalone solution, they are a viable cost-effective security measure feasible to the majority of the population. +8. **Low-Cost Security:** The cost of using **NFKBTs** security features correlate to on-chain fees, the current _GWEI_ at the given time. As a standalone solution, they are a viable cost-effective security measure feasible to the majority of the population. -9. Environmentally Friendly: Since the security features are coded into the **NFKBT**, there is no need for centralized servers, shipping, or the production of physical object/s. Thus leading to a minimal carbon footprint by the use of **NFKBTs**, working hand in hand with Ethereum’s change to a _PoS_[^19] network. +9. **Environmentally Friendly:** Since the security features are coded into the **NFKBT**, there is no need for centralized servers, shipping, or the production of physical object/s. Thus leading to a minimal carbon footprint by the use of **NFKBTs**, working hand in hand with Ethereum’s change to a _PoS_[^14] network. -10. User Experience: The security feature can be activated by a simple call to the `addBinding`[^1] function. The user will only need two other wallets, which will act as `_keyWallet1`[^6] and `_keyWallet2`[^7], to gain access to all of the benefits **NFKBTs** offer. The optional security features improve the overall user experience and Ethereum ecosystem by ensuring a safety net for those who decide to use it. Those that do not use the security features are not hindered in any way. This safety net can increase global adoption as people can remain confident in the security of their assets, even in the scenario of a compromised wallet. +10. **User Experience:** The security feature can be activated by a simple call to the [addBindings](#addbindings-function) function. The user will only need two other wallets, which will act as `_keyWallet1`[^15] and `_keyWallet2`[^16], to gain access to all of the benefits **NFKBTs** offer. The optional security features improve the overall user experience and Ethereum ecosystem by ensuring a safety net for those who decide to use it. Those that do not use the security features are not hindered in any way. This safety net can increase global adoption as people can remain confident in the security of their assets, even in the scenario of a compromised wallet. ## Specification @@ -186,7 +186,7 @@ event SafeFallbackActivated(address _account) #### `AccountEnabledTransfer` event Emitted when the `_account` has allowed for transfer `_amount` of tokens for the `_time` amount of `block` seconds for `_to` address (or if -the `_account` has allowed for transfer all funds though `_allFunds` set to `true`) by calling the `allowTransfer` function. +the `_account` has allowed for transfer all funds though `_anyToken` set to `true`) by calling the `allowTransfer` function. ```solidity event AccountEnabledTransfer(address _account, uint256 _amount, uint256 _time, address _to, bool _allFunds) @@ -428,9 +428,9 @@ function setApprovalForAll(address _operator, bool _approved) public virtual ove ## Rationale -The intent from individual technical decisions made during the development of **NFKBTs** focused on maintaining consistency and backward compatibility with _ERC-721s_, all the while offering self-custodial security features to the user. It was important that **NFKBTs** inherited all of the _ERC-721s_ characteristics to comply with requirements found in dApps which use non-fungible tokens on their platform. In doing so, it allowed for flawless backward compatibility to take place and gave the user the choice to decide if they want their **NFKBTs** to act with **Default Behaviours**[^17]. We wanted to ensure that wide-scale implementation and adoption of **NFKBTs** could take place immediately, without the greater collective needing to adapt and make changes to the already flourishing decentralized ecosystem. +The intent from individual technical decisions made during the development of **NFKBTs** focused on maintaining consistency and backward compatibility with ERC-721s, all the while offering self-custodial security features to the user. It was important that **NFKBTs** inherited all of ERC-721s characteristics to comply with requirements found in dApps which use non-fungible tokens on their platform. In doing so, it allowed for flawless backward compatibility to take place and gave the user the choice to decide if they want their **NFKBTs** to act with **Default Behaviors**[^4]. We wanted to ensure that wide-scale implementation and adoption of **NFKBTs** could take place immediately, without the greater collective needing to adapt and make changes to the already flourishing decentralized ecosystem. -For developers and users alike, the `allowTransfer`[^3] and `allowApproval`[^4] functions both return bools rather than reverting on failure. This decision was done purposefully, to keep consistency with the already familiar _ERC-721_. Additional technical decisions related to self-custodial security features are broken down and located within the security considerations section. +For developers and users alike, the [allowTransfer](#allowtransfer-function) and [allowApproval](#allowapproval-function) functions both return bools on success and revert on failures. This decision was done purposefully, to keep consistency with the already familiar ERC-721. Additional technical decisions related to self-custodial security features are broken down and located within the [Security Considerations](#security-considerations) section. ## Backwards Compatibility @@ -450,53 +450,53 @@ Average Gas used (_GWEI_): ## Reference Implementation -The GitHub repository [KBTstandard repository](../assets/eip-6809/README.md) contains the implementation. There's also a [diagram](../assets/eip-6809/Contract%20Interactions%20diagram.svg) with the contract interactions. +The implementation is located in the [eip-6809 assets](../assets/eip-6809/README.md) directory. There's also a [diagram](../assets/eip-6809/Contract%20Interactions%20diagram.svg) with the contract interactions. ## Security Considerations **NFKBTs** were designed with security in mind every step of the way. Below are some design decisions that were rigorously discussed and thought through during the development process. -**Key Wallets**[^2]: These have been limited to two, in order to prevent a pitfall scenario of a user adding multiple wallets. For this reason, we have stuck to _BIP-39_[^8] split across three wallets as opposed to creating a _SLIP-39_[^15] security solution. Thus we can prevent a disastrous `safeFallback`[^10] scenario. +**Key Wallets**[^1]: When calling the [addBindings](#addbinings-function) function for an **NFKBT**, the user must input 2 wallets that will then act as `_keyWallet1`[^15] and `_keyWallet2`[^16]. They are added simultaneously to reduce user fees, minimize the chance of human error and prevent a pitfall scenario. If the user had the ability to add multiple wallets it would not only result in additional fees and avoidable confusion but would enable a potentially disastrous [safeFallback](#safefallback-function) situation to occur. For this reason, all **KBTs** work under a 3-wallet system when security features are activated. -Typically if a wallet is compromised, the non-fungible assets within are at risk. With **NFKBTs** there are two different functions that can be called from a **Key Wallet**[^2] depending on which wallet has been compromised. +Typically if a wallet is compromised, the non-fungible assets within are at risk. With **NFKBTs** there are two different functions that can be called from a **Key Wallet**[^1] depending on which wallet has been compromised. -Scenario: **Holding Wallet**[^9] has been compromised, call `safeFallback`[^10]. +Scenario: **Holding Wallet**[^3] has been compromised, call [safeFallback](#safefallback-function). -`safeFallback`[^10]: This function was created in the event that the owner believes the **Holding Wallet**[^9] has been compromised. It can also be used if the owner losses access to the **Holding Wallet**[^9]. In this scenario, the user has the ability to call `safeFallback`[^10] from one of the **Key Wallets**[^2]. **NFKBTs** are then redirected from the **Holding Wallet**[^9] to the other **Key Wallet**[^2]. +[safeFallback](#safefallback-function): This function was created in the event that the owner believes the **Holding Wallet**[^3] has been compromised. It can also be used if the owner losses access to the **Holding Wallet**. In this scenario, the user has the ability to call [safeFallback](#safefallback-function) from one of the **Key Wallets**[^1]. **NFKBTs** are then redirected from the **Holding Wallet** to the other **Key Wallet**. -By redirecting the **NFKBTs** it prevents a single point of failure. If an attacker were to call `safeFallback`[^10] and the **NFKBTs** redirected to the **Key Wallet**[^2] that called the function, they would gain access to all the **NFKBTs**. +By redirecting the **NFKBTs** it prevents a single point of failure. If an attacker were to call [safeFallback](#safefallback-function) and the **NFKBTs** redirected to the **Key Wallet**[^1] that called the function, they would gain access to all the **NFKBTs**. -Scenario: **Key Wallet**[^2] has been compromised, call `resetBindings`[^11]. +Scenario: **Key Wallet**[^1] has been compromised, call [resetBindings](#resetbindings-function). -`resetBindings`[^11]: This function was created in the event that the owner believes `keyWallet1`[^6] or `keyWallet2`[^7] has been compromised. It can also be used if the owner losses access to one of the **Key Wallets**[^2]. In this instance, the user has the ability to call `resetBindings`[^11], removing the bound **Key Wallets**[^2] and resetting the security features. The **NFKBTs** will now function as a traditional _ERC-721_ until `addBindings`[^1] is called again and a new set of **Key Wallets**[^2] are added. +[resetBindings](#resetbindings-function): This function was created in the event that the owner believes `_keyWallet1`[^15] or `_keyWallet2`[^16] has been compromised. It can also be used if the owner losses access to one of the **Key Wallets**[^1]. In this instance, the user has the ability to call [resetBindings](#resetbindings-function), removing the bound **Key Wallets** and resetting the security features. The **NFKBTs** will now function as a traditional ERC-721 until [addBindings](#addbindings-function) is called again and a new set of **Key Wallets** are added. -The reason why `keyWallet1`[^6] or `keyWallet2`[^7] are required to call the `resetBindings`[^11] function is because a **Holding Wallet**[^9] having the ability to call `resetBindings`[^11] could result in an immediate loss of **NFKBTs**. The attacker would only need to gain access to the **Holding Wallet**[^9] and call `resetBindings`[^11]. +The reason why `_keyWallet1`[^15] or `_keyWallet2`[^16] are required to call the [resetBindings](#resetbindings-function) function is because a **Holding Wallet**[^3] having the ability to call [resetBindings](#resetbindings-function) could result in an immediate loss of **NFKBTs**. The attacker would only need to gain access to the **Holding Wallet** and call [resetBindings](#resetbindings-function). In the scenario that 2 of the 3 wallets have been compromised, there is nothing the owner of the **NFKBTs** can do if the attack is malicious. However, by allowing 1 wallet to be compromised, holders of non-fungible tokens built using the **NFKBT** standard are given a second chance, unlike other current standards. -The `allowTransfer`[^3] function is in place to guarantee a **Safe Transfer**[^5], but can also have **Default Values**[^18] set by a dApp to emulate **Default Bahviours**[^17] of a traditional _ERC-721_. It enables the user to highly specify the type of transfer they are about to conduct, whilst simultaneously allowing the user to unlock all the **NFKBTs** to anyone for an unlimited amount of time. The desired security is completely up to the user. +The [allowTransfer](#allowtransfer-function) function is in place to guarantee a **Safe Transfer**[^2], but can also have **Default Values**[^7] set by a dApp to emulate **Default Behaviors**[^3] of a traditional ERC-721. It enables the user to highly specify the type of transfer they are about to conduct, whilst simultaneously allowing the user to unlock all the **NFKBTs** to anyone for an unlimited amount of time. The desired security is completely up to the user. This function requires 4 parameters to be filled and different combinations of these result in different levels of security; -Parameter 1 `_tokenId`[^12]: This is the ID of the **NFKBT** that will be spent on a transfer. +Parameter 1 `_tokenId`[^8]: This is the ID of the **NFKBT** that will be spent on a transfer. -Parameter 2 `_time`[^13]: The number of blocks the **NFKBT** can be transferred starting from the current block timestamp. +Parameter 2 `_time`[^9]: The number of blocks the **NFKBT** can be transferred starting from the current block timestamp. -Parameter 3 `_address`[^14]: The destination the **NFKBT** will be sent to. +Parameter 3 `_address`[^10]: The destination the **NFKBT** will be sent to. -Parameter 4 `_allFunds`[^20]: This is a boolean value. When false, the `transfer` function takes into consideration Parameters 1, 2 and 3. If the value is true, the `transfer` function will revert to a **Default Behaviour**[^17], the same as a traditional _ERC-721_. +Parameter 4 `_anyToken`[^11]: This is a boolean value. When false, the `transferFrom` function takes into consideration Parameters 1, 2 and 3. If the value is true, the `transferFrom` function will revert to a **Default Behavior**[^4], the same as a traditional ERC-721. -The `allowTransfer`[^3] function requires a **Key Wallet**[^2] and enables the **Holding Wallet**[^9] to conduct the transaction within the previously specified parameters. These parameters were added in order to provide additional security by limiting the **Holding Wallet**[^9] in the case it was compromised without the user's knowledge. +The [allowTransfer](#allowtransfer-function) function requires `_keyWallet1`[^15] or `_keyWallet2`[^16] and enables the **Holding Wallet**[^3] to conduct a `transferFrom` within the previously specified parameters. These parameters were added in order to provide additional security by limiting the **Holding Wallet** in case it was compromised without the user's knowledge. -The `allowApproval`[^4] function provides extra security when allowing on-chain third parties to use your **NFKBTs** on your behalf. This is especially useful when a user is met with common malicious attacks e.g. draining dApp. +The [allowApproval](#allowapproval-function) function provides extra security when allowing on-chain third parties to use your **NFKBTs** on your behalf. This is especially useful when a user is met with common malicious attacks e.g. draining dApp. This function requires 2 parameters to be filled and different combinations of these result in different levels of security; -Parameter 1 `_time`[^21]: The number of blocks that the approval of a third-party service can take place, starting from the current block timestamp. +Parameter 1 `_time`[^12]: The number of blocks that the approval of a third-party service can take place, starting from the current block timestamp. -Parameter 2 `_numberOfTransfers_`[^22]: The number of transactions a third-party service can conduct on the user's behalf. +Parameter 2 `_numberOfTransfers_`[^13]: The number of transactions a third-party service can conduct on the user's behalf. -The `allowApproval`[^4] function requires a **Key Wallet**[^2] which enables the **Holding Wallet**[^9] to allow a third-party service by using the `approve` function. These parameters were added to provide extra security when granting permission to a third-party that uses assets on the user's behalf. Parameter 1, `_time`[^21], is a limitation to when the **Holding Wallet**[^9] can `approve` a third-party service. Parameter 2 ,`_numberOfTranfers`[^22], is a limitation to the number of transactions the approved third-party service can conduct on the user's behalf before revoking approval. +The [allowApproval](#allowapproval-function) function requires `_keyWallet1`[^15] or `_keyWallet2`[^16] and enables the **Holding Wallet**[^3] to allow a third-party service by using the `approve` function. These parameters were added to provide extra security when granting permission to a third-party that uses assets on the user's behalf. Parameter 1, `_time`[^12], is a limitation to when the **Holding Wallet** can `approve` a third-party service. Parameter 2, `_numberOfTransfers`[^13], is a limitation to the number of transactions the approved third-party service can conduct on the user's behalf before revoking approval. ## Copyright @@ -504,25 +504,19 @@ Copyright and related rights waived via [CC0](../LICENSE.md). --- -[^1]: The `addBinding` function is used to add **Key Wallets**. -[^2]: The **Key Wallet/s** refer to `_keyWallet1` or `_keyWallet2` which can call the `safeFallback`, `resetBindings`, `allowTransfer` and `allowApproval` functions. -[^3]: The `allowTransfer` function allows requires a set of 4 parameters to be conducted. A specific `_tokenId`, `_time`, `_address`, and `_allFunds`. -[^4]: The `allowApproval` function requires a set of 2 parameters to be conducted. A specific amount of `_time` the **Holding Wallet** can `approve` and `_numberOfTransfers` a third-party can conduct on the user's behalf. -[^5]: A **Safe Transfer** is when 1 of the **Key Wallets** safely approved the use of the **NFKBTs**. -[^6]: The `keyWallet1` is 1 of the 2 **Key Wallets** set when calling the `addBinding` function. -[^7]: The `keyWallet2` is 1 of the 2 **Key Wallets** set when calling the `addBinding` function. -[^8]: Security known as _BIP-39_, defines how wallets create seed phrases and generate encryption keys. -[^9]: The **Holding Wallet** refers to the wallet containing the **NFKBTs**. -[^10]: The `safeFallback` function moves **NFKBTs** from the **Holding Wallet** to the **Key Wallet** that didn't call the `safeFallback` function. -[^11]: The `resetBindings` function resets the **Key Wallets** allowing the **Holding Wallet** to add new ones. -[^12]: The `_tokenId` represents the ID of the **NFKBT** intended to be spent. -[^13]: The `_time` in `allowTransfer` represents the number of blocks a `transferFrom` can take place in. -[^14]: The `_address` represents tha address that the **NFKBT** will be sent too. -[^15]: Security known as _Slip-39_, describes a way to securely back up a secret value using Shamir's Secret Sharing scheme. The secret value, called a Master Secret (MS) in SLIP-39 terminology, is first encrypted by a passphrase, producing an Encrypted Master Secret (EMS). -[^16]: The amount stolen in the USA provided by FTC reports. -[^17]: A **Default Behaviour/s** refers to bahaviour/s present in the preexisting non-fungible _ERC-721_ standard. -[^18]: A **Default Value/s** refer to a value/s that emulates the non-fungible _ERC-721_ **Default Behaviour/s**. -[^19]: A _PoS_ protocol, Proof-of-Stake protocol, is a cryptocurrency consensus mechanism for processing transactions and creating new blocks in a blockchain. Source - investopedia.com/terms/p/proof-stake-pos.asp website. -[^20]: The `_allFunds` is a bool that can be set to true or false. -[^21]: The `_time` in `allowApproval` represents the number of blocks an `approve` can take place in. -[^22]: The `_numberOfTransfers` is the number of transfers a third-party entity can conduct via `transferFrom` on the user's behalf. +[^1]: The **Key Wallet/s** refers to `_keyWallet1` or `_keyWallet2` which can call the `safeFallback`, `resetBindings`, `allowTransfer` and `allowApproval` functions. +[^2]: A **Safe Transfer** is when 1 of the **Key Wallets** safely approved the use of the **NFKBTs**. +[^3]: The **Holding Wallet** refers to the wallet containing the **NFKBTs**. +[^4]: A **Default Behavior/s** refers to behavior/s present in the preexisting non-fungible ERC-721 standard. +[^5]: The number of crypto scam reports the United States Federal Trade Commission received, from January 2021 through March 2022. +[^6]: The amount stolen via crypto scams according to the United States Federal Trade Commission, from January 2021 through March 2022. +[^7]: A **Default Value/s** refer to a value/s that emulates the non-fungible ERC-721 **Default Behavior/s**. +[^8]: The `_tokenId` represents the ID of the **NFKBT** intended to be spent. +[^9]: The `_time` in `allowTransfer` represents the number of blocks a `transferFrom` can take place in. +[^10]: The `_address` represents the address that the **NFKBT** will be sent to. +[^11]: The `_anyToken` is a bool that can be set to true or false. +[^12]: The `_time` in `allowApproval` represents the number of blocks an `approve` can take place in. +[^13]: The `_numberOfTransfers` is the number of transfers a third-party entity can conduct via `transferFrom` on the user's behalf. +[^14]: A _PoS_ protocol, Proof-of-Stake protocol, is a cryptocurrency consensus mechanism for processing transactions and creating new blocks in a blockchain. +[^15]: The `_keyWallet1` is 1 of the 2 **Key Wallets** set when calling the `addBindings` function. +[^16]: The `_keyWallet2` is 1 of the 2 **Key Wallets** set when calling the `addBindings` function. \ No newline at end of file