Add EIP: Fungible Key Bound Token #6808

KBTStandardAdmin · 2023-03-31T10:45:38Z

A standard interface for Fungible Key Bound Tokens, also known as a Fungible KBT

The Key Bound Token Standard is a new standard focused on self-custodial security. The users of the fungible version can benefit from its integrated decentralized anti-theft mechanism. By binding two additional wallets, this standard prevents attackers and scammers alike to use your asset, even if they gain control of your seed phrase or private key.

eth-bot · 2023-03-31T10:46:08Z

✅ All reviewers have approved.

SamWilsn

Couple broad comments:

You'll have to remove all external references, except as permitted in EIP-1: Linking to External Resources. This includes URLs without the scheme (eg. https://), document references like BIP 39, and so on.
If possible, can you provide an SVG version of your diagram?
Remove build system files (especially package-lock.json)
This document has an unusually large number of footnotes. This isn't exactly a problem, but it does break style with other EIPs, and I'd like to see them reduced in number.

SamWilsn · 2023-04-04T15:05:10Z

EIPS/eip-6808.md

+---
+eip: 6808
+title: Fungible Key Bound Token
+description: An interface for Fungible Key Bound Tokens, also known as a Fungible **KBT**[^1].


Unfortunately you can't put markdown in the preamble fields.

Suggested change

description: An interface for Fungible Key Bound Tokens, also known as a Fungible **KBT**[^1].

description: An interface for Fungible Key Bound Tokens, also known as a Fungible KBT.

SamWilsn · 2023-04-04T19:19:01Z

EIPS/eip-6808.md

+A standard interface for Fungible Key Bound Tokens, also known as a Fungible **KBT**[^1].
+
+## Abstract


Suggested change

A standard interface for Fungible Key Bound Tokens, also known as a Fungible **KBT**[^1].

## Abstract

## Abstract

A standard interface for Fungible Key Bound Tokens, also known as a Fungible **KBT**[^1].

SamWilsn · 2023-04-04T19:22:26Z

EIPS/eip-6808.md

+
+## Abstract
+
+The following standard allows for the implementation of a standard API for tokens within smart contracts and provides basic functionality to the `addBinding`[^2] function. This function creates **Key Wallets**[^3], which are used to `allowTransfer`[^4] or `allowApproval`[^5] in order to conduct a **Safe Transfer**[^6] of fungible tokens. In the process, the tokens are also safely approved so they can be spent by the user or another on-chain third-party entity.


Don't repeat "standard" so much. Perhaps:

The following standardizes an API for tokens [...]

SamWilsn · 2023-04-04T19:25:03Z

EIPS/eip-6808.md

+requires: 20
+---
+
+A standard interface for Fungible Key Bound Tokens, also known as a Fungible **KBT**[^1].


Instead of using a footnote for the expanded form of KBT, you can use parentheses:

Suggested change

A standard interface for Fungible Key Bound Tokens, also known as a Fungible **KBT**[^1].

A standard interface for Fungible Key Bound Tokens (FKBT), a subset of of the more general Key Bound Tokens (KBT).

After the first expansion in the document, you're free to use the abbreviation alone.

SamWilsn · 2023-04-04T19:41:39Z

EIPS/eip-6808.md

+The following standard allows for the implementation of a standard API for tokens within smart contracts and provides basic functionality to the `addBinding`[^2] function. This function creates **Key Wallets**[^3], which are used to `allowTransfer`[^4] or `allowApproval`[^5] in order to conduct a **Safe Transfer**[^6] of fungible tokens. In the process, the tokens are also safely approved so they can be spent by the user or another on-chain third-party entity.
+
+This functionality is fully optional and security features malleable to suit one's needs. To activate it, the holder must add 2 different wallets when emitting the `addBinding`[^2] function. These will be known as `_keyWallet1`[^7] and `_keyWallet2`[^8]. If the user does not activate the assets security feature, **KBTs**[^1] **Default Behavior**[^22] is the same as a traditional fungible [_ERC-20_](../EIPS/eip-20.md) token. However, even when the security feature is activated, the standard has **Default Values**[^23] which the user can input to achieve the same result.


Your abstract, so far, goes too deep into the technical details without giving a high enough level overview of the topic. What is a Key Bound Token? You don't really define the concept of "allow" (as in allowTransfer and allowApproval.)

SamWilsn · 2023-04-04T20:17:22Z

EIPS/eip-6808.md

+) internal view returns (bool) {
+    TransferConditions memory conditions = _transferConditions[_account];
+
+    if (conditions.allFunds) {
+        return true;
+    }
+
+    if (
+        (conditions.amount == 0 &&
+            conditions.time == 0 &&
+            conditions.to == address(0) &&
+            !conditions.allFunds) ||
+        (conditions.amount > 0 && conditions.amount < _amount) ||
+        (conditions.time > 0 && conditions.time < block.timestamp) ||
+        (conditions.to != address(0) && conditions.to != _to)
+    ) {
+        return false;
+    }
+
+    return true;
+}
+```
+
+#### `_getAccountHolder` function
+
+This function identifies and returns the `_holder` account starting from the `sender` address.
+
+If the `sender` is not a `keyWallet` zero address is returned (`0x0`).
+
+```solidity
+function _getAccountHolder() internal view returns (address) {
+    address sender = _msgSender();
+    return
+        _firstAccounts[sender].accountHolderWallet != address(0)
+            ? _firstAccounts[sender].accountHolderWallet
+            : (
+                _secondAccounts[sender].accountHolderWallet != address(0)
+                    ? _secondAccounts[sender].accountHolderWallet
+                    : address(0)
+            );
+}
+```
+
+#### `_getOtherSecureWallet` function
+
+This function identifies and returns the other `keyWallet` starting from the `sender` address.
+
+If the `sender` is not a `keyWallet` zero address is returned (`0x0`).
+
+```solidity
+function _getOtherSecureWallet() internal view returns (address) {
+    address sender = _msgSender();
+    address accountHolder = _getAccountHolder();
+
+    return
+        _holderAccounts[accountHolder].firstWallet == sender
+            ? _holderAccounts[accountHolder].secondWallet
+            : _holderAccounts[accountHolder].firstWallet;
+}
+```
+
+#### `_isApprovalAllowed` function
+
+This function returns `true` if the `_time`, set in `allowApproval` function, has not elapsed yet.
+
+```solidity
+function _isApprovalAllowed(address account) internal view returns (bool) {
+    return _approvalConditions[account].time >= block.timestamp;
+}
+```
+
+#### `_afterTokenTransfer` function
+
+This function is called after a successful `transfer`, `transferFrom`, `mint` and `burn`.
+
+This function fires `Egress` event when loosing a holder and `Ingress` event when gaining a holder.
+
+```solidity
+function _afterTokenTransfer(
+    address from,
+    address to,
+    uint256 amount
+) internal virtual {
+    // region update secureAccounts
+    if (isSecureWallet(from) && balanceOf(from) == 0) {
+        delete _firstAccounts[_holderAccounts[from].firstWallet];
+        delete _secondAccounts[_holderAccounts[from].secondWallet];
+        delete _holderAccounts[from];
+    }
+    // endregion
+
+    if (balanceOf(from) == 0) {
+        emit Egress(from, amount);
+    }
+
+    if (balanceOf(to) == amount) {
+        emit Ingress(to, amount);
+    }
+}
+```


Suggested change

### **Internal functions**

#### `_hasAllowedTransfer` function

The function returns `true` if:

- the `_account` has allowed for transfer all funds through `_allFunds` parameter

- or the `_account` has allowed for transfer an `_amount` of funds, for `_to` address and if the `time` has not elapsed

In all other cases the function will return `false`.

```solidity

function _hasAllowedTransfer(

address _account,

uint256 _amount,

address _to

) internal view returns (bool) {

TransferConditions memory conditions = _transferConditions[_account];

if (conditions.allFunds) {

return true;

}

if (

(conditions.amount == 0 &&

conditions.time == 0 &&

conditions.to == address(0) &&

!conditions.allFunds) ||

(conditions.amount > 0 && conditions.amount < _amount) ||

(conditions.time > 0 && conditions.time < block.timestamp) ||

(conditions.to != address(0) && conditions.to != _to)

) {

return false;

}

return true;

}

```

#### `_getAccountHolder` function

This function identifies and returns the `_holder` account starting from the `sender` address.

If the `sender` is not a `keyWallet` zero address is returned (`0x0`).

```solidity

function _getAccountHolder() internal view returns (address) {

address sender = _msgSender();

return

_firstAccounts[sender].accountHolderWallet != address(0)

? _firstAccounts[sender].accountHolderWallet

: (

_secondAccounts[sender].accountHolderWallet != address(0)

? _secondAccounts[sender].accountHolderWallet

: address(0)

);

}

```

#### `_getOtherSecureWallet` function

This function identifies and returns the other `keyWallet` starting from the `sender` address.

If the `sender` is not a `keyWallet` zero address is returned (`0x0`).

```solidity

function _getOtherSecureWallet() internal view returns (address) {

address sender = _msgSender();

address accountHolder = _getAccountHolder();

return

_holderAccounts[accountHolder].firstWallet == sender

? _holderAccounts[accountHolder].secondWallet

: _holderAccounts[accountHolder].firstWallet;

}

```

#### `_isApprovalAllowed` function

This function returns `true` if the `_time`, set in `allowApproval` function, has not elapsed yet.

```solidity

function _isApprovalAllowed(address account) internal view returns (bool) {

return _approvalConditions[account].time >= block.timestamp;

}

```

#### `_afterTokenTransfer` function

This function is called after a successful `transfer`, `transferFrom`, `mint` and `burn`.

This function fires `Egress` event when loosing a holder and `Ingress` event when gaining a holder.

```solidity

function _afterTokenTransfer(

address from,

address to,

uint256 amount

) internal virtual {

// region update secureAccounts

if (isSecureWallet(from) && balanceOf(from) == 0) {

delete _firstAccounts[_holderAccounts[from].firstWallet];

delete _secondAccounts[_holderAccounts[from].secondWallet];

delete _holderAccounts[from];

}

// endregion

if (balanceOf(from) == 0) {

emit Egress(from, amount);

}

if (balanceOf(to) == amount) {

emit Ingress(to, amount);

}

}

```

Generally you should only standardize functions that are externally visible in the interface itself. The standard should provide enough information that multiple implementations can interoperate correctly, without specifying how the implementations should work. These kind of choices should be left up to the implementers.

SamWilsn · 2023-04-04T20:18:25Z

EIPS/eip-6808.md

+[^6]: A **Safe Transfer** is when 1 of the **Key Wallets** safely approved the use of the fungible token.
+[^7]: The `keyWallet1` is 1 of the 2 **Key Wallets** set when calling the `addBinding` function.
+[^8]: The `keyWallet2` is 1 of the 2 **Key Wallets** set when calling the `addBinding` function.
+[^9]: The [_ERC-20_](../EIPS/eip-20.md) is the token standard for creating smart contract-enabled fungible tokens to be used in the Ethereum ecosystem. Source - investopedia.com/news/what-erc20-and-what-does-it-mean-ethereum/#:~:text=What's%20the%20Difference%20Be website.


Suggested change

[^9]: The [_ERC-20_](../EIPS/eip-20.md) is the token standard for creating smart contract-enabled fungible tokens to be used in the Ethereum ecosystem. Source - investopedia.com/news/what-erc20-and-what-does-it-mean-ethereum/#:~:text=What's%20the%20Difference%20Be website.

[^9]: The [ERC-20](./eip-20.md) is the token standard for creating smart contract-enabled fungible tokens to be used in the Ethereum ecosystem

SamWilsn · 2023-04-04T20:19:06Z

EIPS/eip-6808.md

+[^7]: The `keyWallet1` is 1 of the 2 **Key Wallets** set when calling the `addBinding` function.
+[^8]: The `keyWallet2` is 1 of the 2 **Key Wallets** set when calling the `addBinding` function.
+[^9]: The [_ERC-20_](../EIPS/eip-20.md) is the token standard for creating smart contract-enabled fungible tokens to be used in the Ethereum ecosystem. Source - investopedia.com/news/what-erc20-and-what-does-it-mean-ethereum/#:~:text=What's%20the%20Difference%20Be website.
+[^10]: Security known as _BIP-39_, defines how wallets create seed phrases and generate encryption keys. Source - vault12.com/securemycrypto/crypto-security-basics/what-is-bip39/ website.


External links, like to BIP-39 or to vault12 are not permitted.

Suggested change

[^10]: Security known as _BIP-39_, defines how wallets create seed phrases and generate encryption keys. Source - vault12.com/securemycrypto/crypto-security-basics/what-is-bip39/ website.

SamWilsn · 2023-04-04T20:21:15Z

EIPS/eip-6808.md

+[^14]: The `_amount` represents the amount of the asset intended to be spent.
+[^15]: The `_time` in `allowTransfer` represents the number of blocks a `transfer` can take place in.
+[^16]: The `_address` represents tha address that the asset will be sent too.
+[^17]: The denomination of the cryptocurrency ether (ETH), used on the Ethereum network to buy and sell goods and services is known as _GWEI_. Source - investopedia.com/terms/g/gwei-ethereum.asp#:~:text=Key%20Takeaways-,Gwei%20is%20a%20denomination%20of%20the%20cryptocurrency%20ether%20(ETH)%2C,to%20specify%20Ethereum%20gas%20prices website.


Suggested change

[^17]: The denomination of the cryptocurrency ether (ETH), used on the Ethereum network to buy and sell goods and services is known as _GWEI_. Source - investopedia.com/terms/g/gwei-ethereum.asp#:~:text=Key%20Takeaways-,Gwei%20is%20a%20denomination%20of%20the%20cryptocurrency%20ether%20(ETH)%2C,to%20specify%20Ethereum%20gas%20prices website.

gwei is a well known term to the audience of this repository.

SamWilsn · 2023-04-04T20:23:46Z

assets/eip-6808/contracts/KBT20.sol

@@ -0,0 +1,391 @@
+// SPDX-License-Identifier: CCO


Suggested change

// SPDX-License-Identifier: CCO

// SPDX-License-Identifier: CC0-1.0

* Updated the Specification section and replaced the png with and svg file * Fixed the assets issue with package-lock * Fixed the licence in the KBT contract * Description + Abstract + Motivation Description bullet points and bolding options * description bolding fix * DApp = dApp funds = FKBT security considerations * Footnotes Updated * Rationale Removal * rationale change * footnote rationale * Funcationality Correction * Backwards Compatibility Section * Footnotes Updated * Applying markdown preferred style --------- Co-authored-by: KBT Admin <[email protected]> Co-authored-by: NickZCZ <[email protected]> Co-authored-by: MihaiORO <[email protected]>

SamWilsn · 2023-04-18T15:10:45Z

EIPS/eip-6808.md

+
+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, **FKBTs** are safely approved so they can be spent by the user or an on-chain third-party entity.
+
+The premise of **FKBTs** is to provide fully optional security features built directly into the 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**[^9] to either call the already familier `transfer` and `approve` function found in the [_ERC-20_](./eip-20.md). Responsibility for the **FKBT** is therefore split. The **Holding Wallet**[^9] contains the asset and **Key Wallets**[^2] have authority over how the assets can be spent or approved. **Default Behaviors**[^17] of a traditional fungible _ERC-20_ can be achieved by simply never using the `addBinding`[^1] function.


Tiny style complaints: don't italicize ERC/EIP references, and don't use "the" before them. You can use backticks (`) for code references (like interface names) though.

Small spelling correction as well.

Suggested change

The premise of **FKBTs** is to provide fully optional security features built directly into the 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**[^9] to either call the already familier `transfer` and `approve` function found in the [_ERC-20_](./eip-20.md). Responsibility for the **FKBT** is therefore split. The **Holding Wallet**[^9] contains the asset and **Key Wallets**[^2] have authority over how the assets can be spent or approved. **Default Behaviors**[^17] of a traditional fungible _ERC-20_ can be achieved by simply never using the `addBinding`[^1] function.

The premise of **FKBTs** is to provide fully optional security features built directly into the 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**[^9] to either call the already familiar `transfer` and `approve` function found in [ERC-20](./eip-20.md). Responsibility for the **FKBT** is therefore split. The **Holding Wallet**[^9] contains the asset and **Key Wallets**[^2] have authority over how the assets can be spent or approved. **Default Behaviors**[^17] of a traditional fungible ERC-20 can be achieved by simply never using the `addBinding`[^1] function.

SamWilsn · 2023-04-18T15:12:53Z

EIPS/eip-6808.md

+
+## Specification
+
+### ERC-N (Token Contract)


Is this heading a placeholder?

SamWilsn · 2023-04-18T15:15:36Z

EIPS/eip-6808.md

+
+A standard interface for Fungible Key Bound Tokens (**FKBT/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, **FKBTs** are safely approved so they can be spent by the user or an on-chain third-party entity.


Suggested change

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, **FKBTs** 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`[^1] function. This function designates **Key Wallets**[^2], which are responsible for conducting a **Safe Transfer**[^5]. During this process, **FKBTs** are safely approved so they can be spent by the user or an on-chain third-party entity.

SamWilsn · 2023-04-18T15:17:12Z

EIPS/eip-6808.md

+
+## Reference Implementation
+
+The GitHub repository [KBTstandard repository](../assets/eip-6808/README.md) contains the implementation. There's also a [diagram](../assets/eip-6808/Contract%20Interactions%20diagram.svg) with the contract interactions.


Since this lives in the assets directory now, it's odd to mention the "KBTstandard repository".

* Rephrased the Reference Implementation. * Changed the heading in Specifications section * Linked the functions to the headings instead of the footnotes + removed unused footnotes * Security Considerations redirect - rationale section * Spelling Check #1 + BIP / SLIP removal + the ERC check + Footnote removal & # Update * motivation topic bolding change * Motivation FTC sentence * FKBT footnotes and corrections update * Key Wallet Reduction --------- Co-authored-by: KBT Admin <[email protected]> Co-authored-by: NickZCZ <[email protected]> Co-authored-by: MihaiORO <[email protected]>

github-actions · 2023-04-25T11:43:52Z

The commit 8f7bd23 (as a parent of efbbc8a) contains errors.
Please inspect the Run Summary for details.

NarcisCRO

Hi @SamWilsn
We fixed the last comments and we're ready for merge.

EIPS/eip-6808.md

assets/eip-6808/README.md

Co-authored-by: Sam Wilson <[email protected]>

eth-bot

All Reviewers Have Approved; Performing Automatic Merge...

Added a draft EIP for fungible tokens.

ab8e00f

KBTStandardAdmin requested a review from eth-bot as a code owner March 31, 2023 10:45

github-actions bot added c-new Creates a brand new proposal s-draft This EIP is a Draft t-erc labels Mar 31, 2023

eth-bot changed the title ~~Added a draft EIP for fungible tokens.~~ Add EIP: Fungible Key Bound Token Standard Mar 31, 2023

eth-bot added e-consensus Waiting on editor consensus e-review Waiting on editor to review labels Mar 31, 2023

github-actions bot added the w-ci Waiting on CI to pass label Mar 31, 2023

KBTStandardAdmin added 5 commits March 31, 2023 16:07

Fix for repository, test cases and wesite URLs

7e6d5dc

Fix ERC-20 link

a93ac0b

Fixing EIP Walidator errors

343e104

Fixing EIP Walidator errors

eef85f5

Fixing EIP Walidator errors

5970bd1

eth-bot changed the title ~~Add EIP: Fungible Key Bound Token Standard~~ Add EIP: Fungible Key Bound Token Mar 31, 2023

github-actions bot added w-ci Waiting on CI to pass and removed w-ci Waiting on CI to pass labels Mar 31, 2023

KBTStandardAdmin added 2 commits March 31, 2023 23:02

Renamed the file according to EIP Walidator

c31d6ed

Fixing Markdown linter errors

a21b137

github-actions bot removed the w-ci Waiting on CI to pass label Mar 31, 2023

Fixing Markdown linter errors

012ab02

github-actions bot added the w-ci Waiting on CI to pass label Mar 31, 2023

KBTStandardAdmin added 3 commits April 1, 2023 22:52

Adde the contract with tests in the assets folder

b5716f5

Updated the EIP with the proper relative repo links

99df089

Added diagram and mention it the reference implementation.

eea4c71

poojaranjan mentioned this pull request Apr 4, 2023

EIP Editing Office Hour Meeting 14 ethcatherders/EIPIP#222

Closed

16 tasks

eth-bot added a-review Waiting on author to review and removed e-review Waiting on editor to review labels Apr 4, 2023

Fixing EIP Walidator errors

48e4be9

Fixing EIP Walidator errors

64fa009

SamWilsn reviewed Apr 4, 2023

View reviewed changes

KBTStandardAdmin and others added 4 commits April 8, 2023 09:00

Merge branch 'ethereum:master' into master

e65b0d6

Merge branch 'ethereum:master' into master

a7e3a19

Fixed the licence in the KBT contract

174475d

poojaranjan mentioned this pull request Apr 18, 2023

EIP Editing Office Hour Meeting 15 ethcatherders/EIPIP#225

Closed

23 tasks

NarcisCRO added 3 commits April 18, 2023 16:30

Small fix related to diagram extension and corrected a footnote.

38ea9f2

Fixing makdown linter errors

c808abd

Renumbered the footnotes and removed the unused ones

c75a202

github-actions bot removed the w-ci Waiting on CI to pass label Apr 18, 2023

Fixed small Typo

355e4c4

SamWilsn reviewed Apr 18, 2023

View reviewed changes

xinbenlv mentioned this pull request Apr 18, 2023

Allow BIPs as external source. #6897

Closed

github-actions bot added the w-ci Waiting on CI to pass label Apr 25, 2023

FIxing html markdowns and linter issues

26663e1

github-actions bot removed the w-ci Waiting on CI to pass label Apr 25, 2023

Fixing html markdowns and linter issues

a52c839

NarcisCRO previously approved these changes Apr 25, 2023

View reviewed changes

poojaranjan mentioned this pull request May 2, 2023

EIP Editing Office Hour Meeting 16 ethcatherders/EIPIP#228

Closed

20 tasks

SamWilsn reviewed May 2, 2023

View reviewed changes

EIPS/eip-6808.md Outdated Show resolved Hide resolved

EIPS/eip-6808.md Outdated Show resolved Hide resolved

EIPS/eip-6808.md Outdated Show resolved Hide resolved

EIPS/eip-6808.md Outdated Show resolved Hide resolved

assets/eip-6808/README.md Outdated Show resolved Hide resolved

Apply suggestions from code review

567b1e4

Co-authored-by: Sam Wilson <[email protected]>

NarcisCRO dismissed their stale review via 567b1e4 May 2, 2023 15:48

SamWilsn approved these changes May 2, 2023

View reviewed changes

NarcisCRO approved these changes May 2, 2023

View reviewed changes

eth-bot enabled auto-merge (squash) May 2, 2023 18:35

eth-bot approved these changes May 2, 2023

View reviewed changes

eth-bot merged commit 82db98a into ethereum:master May 2, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add EIP: Fungible Key Bound Token #6808

Add EIP: Fungible Key Bound Token #6808

KBTStandardAdmin commented Mar 31, 2023

eth-bot commented Mar 31, 2023 •

edited

Loading

SamWilsn left a comment •

edited

Loading

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 4, 2023

SamWilsn Apr 18, 2023

SamWilsn Apr 18, 2023

SamWilsn Apr 18, 2023

SamWilsn Apr 18, 2023

github-actions bot commented Apr 25, 2023

NarcisCRO left a comment

eth-bot left a comment

	description: An interface for Fungible Key Bound Tokens, also known as a Fungible KBT[^1].
	description: An interface for Fungible Key Bound Tokens, also known as a Fungible KBT.

		A standard interface for Fungible Key Bound Tokens, also known as a Fungible KBT[^1].

		## Abstract


		## Abstract

		The following standard allows for the implementation of a standard API for tokens within smart contracts and provides basic functionality to the `addBinding`[^2] function. This function creates Key Wallets[^3], which are used to `allowTransfer`[^4] or `allowApproval`[^5] in order to conduct a Safe Transfer[^6] of fungible tokens. In the process, the tokens are also safely approved so they can be spent by the user or another on-chain third-party entity.

		The following standard allows for the implementation of a standard API for tokens within smart contracts and provides basic functionality to the `addBinding`[^2] function. This function creates Key Wallets[^3], which are used to `allowTransfer`[^4] or `allowApproval`[^5] in order to conduct a Safe Transfer[^6] of fungible tokens. In the process, the tokens are also safely approved so they can be spent by the user or another on-chain third-party entity.

		This functionality is fully optional and security features malleable to suit one's needs. To activate it, the holder must add 2 different wallets when emitting the `addBinding`[^2] function. These will be known as `_keyWallet1`[^7] and `_keyWallet2`[^8]. If the user does not activate the assets security feature, KBTs[^1] Default Behavior[^22] is the same as a traditional fungible [_ERC-20_](../EIPS/eip-20.md) token. However, even when the security feature is activated, the standard has Default Values[^23] which the user can input to achieve the same result.

	[^9]: The [_ERC-20_](../EIPS/eip-20.md) is the token standard for creating smart contract-enabled fungible tokens to be used in the Ethereum ecosystem. Source - investopedia.com/news/what-erc20-and-what-does-it-mean-ethereum/#:~:text=What's%20the%20Difference%20Be website.
	[^9]: The [ERC-20](./eip-20.md) is the token standard for creating smart contract-enabled fungible tokens to be used in the Ethereum ecosystem

	// SPDX-License-Identifier: CCO
	// SPDX-License-Identifier: CC0-1.0


		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, FKBTs are safely approved so they can be spent by the user or an on-chain third-party entity.

		The premise of FKBTs is to provide fully optional security features built directly into the 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[^9] to either call the already familier `transfer` and `approve` function found in the [_ERC-20_](./eip-20.md). Responsibility for the FKBT is therefore split. The Holding Wallet[^9] contains the asset and Key Wallets[^2] have authority over how the assets can be spent or approved. Default Behaviors[^17] of a traditional fungible _ERC-20_ can be achieved by simply never using the `addBinding`[^1] function.


		## Reference Implementation

		The GitHub repository [KBTstandard repository](../assets/eip-6808/README.md) contains the implementation. There's also a [diagram](../assets/eip-6808/Contract%20Interactions%20diagram.svg) with the contract interactions.

Add EIP: Fungible Key Bound Token #6808

Add EIP: Fungible Key Bound Token #6808

Conversation

KBTStandardAdmin commented Mar 31, 2023

eth-bot commented Mar 31, 2023 • edited Loading

SamWilsn left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Apr 25, 2023

NarcisCRO left a comment

Choose a reason for hiding this comment

eth-bot left a comment

Choose a reason for hiding this comment

eth-bot commented Mar 31, 2023 •

edited

Loading

SamWilsn left a comment •

edited

Loading