Add co-author

Co-authored-by: pedrouid <pedrouid@users.noreply.github.com>

ERCS/erc-7281.md

@@ -28,7 +28,7 @@ However, even if bridges were all allowed to mint the same representation tokens
 - Suppose Alice pays Bob her 100 USDT on L2. Bob now has 200 USDT.
 - Bob attempts to bridge the 200 USDT from L2→L1 through Bridge 2. This transaction fails because Bridge 2 only has 100 USDT custodied that it can give to Bob.
 
-The core property that this example illustrates is that locking tokens across multiple bridges on the token’s home domain makes it impossible to have fungibility without impeding user experience on remote domains. Minting or burning the token can solve this problem, but not all `ERC20` tokens implement a configurable mint/burn interface. 
+The core property that this example illustrates is that locking tokens across multiple bridges on the token’s home domain makes it impossible to have fungibility without impeding user experience on remote domains. Minting or burning the token can solve this problem, but not all [ERC-20](./eip-20.md) tokens implement a configurable mint/burn interface. 
 
 This, coupled with the need for projects to transfer tokens between chains faster than rollup exit windows, means that token issuers must choose from one of two options to bridge their tokens:
 
@@ -65,7 +65,7 @@ All `XERC20` tokens MUST implement the standard `ERC20` interface. Note that whi
 
 All `XERC20` tokens MUST implement the following interface.
 
-```ts
+```solidity
 interface IXERC20 {
   /**
    * @notice Emits when a lockbox is set
@@ -178,15 +178,15 @@ interface IXERC20 {
 Implementations MUST additionally satisfy the following requirements:
 
 - `mint` MUST check that the caller's current available `limit` is greater than or equal to `_amount`
-- `mint` MUST increase the supply of the underlying `ERC20` by `_amount` and reduce the current available `limit`
+- `mint` MUST increase the supply of the underlying ERC-20 token by `_amount` and reduce the current available `limit`
 - `burn` MUST check that the caller's current available `limit` is greater than or equal to `_amount`
-- `burn` MUST decrease the supply of the underlying `ERC20` by `_amount` and reduce the current available `limit`
+- `burn` MUST decrease the supply of the underlying ERC-20 token by `_amount` and reduce the current available `limit`
 
 ### Lockbox
 
 The lockbox tries to emulate the WETH contract interface as much as possible. Lockboxes MUST implement the following interface:
 
-```ts
+```solidity
 interface IXERC20Lockbox {
   /**
    * @notice Emitted when tokens are deposited into the lockbox
@@ -236,9 +236,9 @@ interface IXERC20Lockbox {
 }
 ```
 
-Lockboxes SHOULD additionally implement the following alternative `deposit` function for native (non-`ERC20`) assets.
+Lockboxes SHOULD additionally implement the following alternative `deposit` function for native (non-ERC-20 token) assets.
 
-```ts
+```solidity
 /**
    * @notice Deposit native assets (e.g. ETH) into the lockbox
    */
@@ -267,7 +267,7 @@ This proposal specifically solves for the above problem in cases where tokens do
 3. On the target domain, the bridge then similarly `mint`s the token.
 4. When transferring back to the home chain, the `XERC20` can be unwrapped back into the original `ERC20` token.
 
-Using this mechanism, the underlying `ERC20` token is consolidated to the Lockbox contract, and shared across all supported bridges.
+Using this mechanism, the underlying ERC-20 token is consolidated to the Lockbox contract, and shared across all supported bridges.
 
 ### Rate Limits
 
@@ -305,7 +305,7 @@ With `XERC20`, the above problems are solved elegantly:
 
 ## Backwards Compatibility
 
-This proposal is fully backwards compatible with `ERC20`.
+This proposal is fully backwards compatible with ERC-20.
 
 Aside from the above, the following compatibility vectors were considered when designing this proposal:
 
@@ -349,7 +349,27 @@ Note: In most of the above cases, a custom bridge integration also means integra
 
 ## Security Considerations
 
-Please see the associated discussion in the **Rationale** section.
+In addition to the granular risk controls outlined in the [Rate Limits](#rate-limits) section, token issuers should be aware of the following security considerations.
+
+### Access Control
+
+Implementations should clearly define roles that manage critical functions such as setting the Lockbox and updating rate limits. Role-based access control (RBAC) can be implemented using battle-tested libraries like OpenZeppelin's AccessControl. For token projects managed by DAOs, it is imperative that ownership and parameter-adjusting functions are guarded in accordance with rules set by the DAO.
+
+### Upgradeability
+
+If the issuer decides to deploy upgradeable contracts, they must consider security measures to ensure upgrades can only be performed by authorized roles. The upgrade process should be transparent and auditable. Similarly to implementing RBAC, upgradeability can be included via battle-tested libraries.
+
+### Lockbox Asset Custody
+
+The Lockbox essentially emulates the behavior of Wrapped Ether (WETH) and vanilla implementations should not need to be owned nor upgradeable. However, if a token issuer requires some custom functionality on the Lockbox then they must ensure that the Lockbox securely custodies the original ERC-20 tokens.
+
+### Mint/Burn Checks
+
+To reiterate security points from the [Token Interface](#token-interface) section:
+- `mint` MUST check that the caller's current available `limit` is greater than or equal to `_amount`
+- `mint` MUST increase the supply of the underlying ERC-20 token by `_amount` and reduce the current available `limit`
+- `burn` MUST check that the caller's current available `limit` is greater than or equal to `_amount`
+- `burn` MUST decrease the supply of the underlying ERC-20 token by `_amount` and reduce the current available `limit`
 
 ## Copyright