Skip to content

Commit 6be520c

Browse files
committed
Add README docs (NOTICE) for LinkTokenChild contract
1 parent 6a1c917 commit 6be520c

2 files changed

Lines changed: 34 additions & 12 deletions

File tree

contracts/v0.7/bridge/README.md

Lines changed: 23 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,25 @@
11
# LINK Token Bridge v0.7
22

3-
- `./token/LinkTokenChild.sol`: A mintable & burnable child LinkToken contract to be used on child networks.
3+
- `./token/LinkTokenChild.sol`: A generalized mintable & burnable child LinkToken contract to be used on child networks.
4+
5+
NOTICE: Current implementation of LinkTokenChild contract requires some additional consideration:
6+
7+
- Supporting more than one gateway (multiple bridges minting the same token) leaves room for accounting issues.
8+
If we have more than one gateway supported, an additional check needs to exist that limits withdrawals per
9+
gateway to an amount locked on L1, for the specific gateway. Otherwise one can accidentally "burn" tokens
10+
by withdrawing more than locked in L1 (tx will fail on L1). When there is a 1:1 relationship between the
11+
gateway and token, the token itself is an accounting mechanism. For a potential N:1 relationship, a more
12+
sophisticated type of accounting needs to exist.
13+
- Every bridge is unique in the amount of risk it bears, so tokens bridged by different bridges are not 1:1
14+
the same token, and shouldn't be forced as such.
15+
- Bridges often require an unique interface to be supported by the child network tokens
16+
(e.g. `mint` vs. `deposit`, `burn` vs. `withdraw/unwrap`, etc.).
17+
- Bridges often assume that the child contract they are bridging to is the ERC20 token itself, not a gateway
18+
(intermediate contract) that could help us map from the specific bridge interface to our standard
19+
LinkTokenChild interface.
20+
- Chainlink often needs to launch on a new network before the native bridge interface is defined.
21+
- To support early (before the bridge is defined) Chainlink network launch, we could make an upgradeable
22+
LinkTokenChild contract which would enable us to slightly update the contract interface after the bridge
23+
gets defined, and once online transfer the ownership (bridge gateway role) to the new bridge.
24+
25+
TODO: Potentially create an upgradeable `LinkTokenChild.sol` and limit gateway support to only one (owner)!

contracts/v0.7/bridge/token/LinkTokenChild.sol

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -11,17 +11,8 @@ import { ERC20Burnable } from "../../../../vendor/OpenZeppelin/openzeppelin-cont
1111
import { SimpleWriteAccessController } from "../../../../vendor/smartcontractkit/chainlink/evm-contracts/src/v0.6/SimpleWriteAccessController.sol";
1212
import { LinkToken } from "../../../v0.6/LinkToken.sol";
1313

14-
/// @dev Access controlled mintable & burnable LinkToken, for use on sidechains and L2 networks.
14+
/// @dev A generalized mintable & burnable child LinkToken contract to be used on child networks.
1515
contract LinkTokenChild is ITypeAndVersion, IERC20Child, SimpleWriteAccessController, ERC20Burnable, LinkToken {
16-
/**
17-
* @dev Overrides parent contract so no tokens are minted on deployment.
18-
* @inheritdoc LinkToken
19-
*/
20-
function _onCreate()
21-
internal
22-
override
23-
{}
24-
2516
/**
2617
* @notice versions:
2718
*
@@ -86,6 +77,15 @@ contract LinkTokenChild is ITypeAndVersion, IERC20Child, SimpleWriteAccessContro
8677
super.burnFrom(account, amount);
8778
}
8879

80+
/**
81+
* @dev Overrides parent contract so no tokens are minted on deployment.
82+
* @inheritdoc LinkToken
83+
*/
84+
function _onCreate()
85+
internal
86+
override
87+
{}
88+
8989
/// @inheritdoc LinkToken
9090
function _transfer(
9191
address sender,
@@ -111,4 +111,4 @@ contract LinkTokenChild is ITypeAndVersion, IERC20Child, SimpleWriteAccessContro
111111
{
112112
super._approve(owner, spender, amount);
113113
}
114-
}
114+
}

0 commit comments

Comments
 (0)