chore(protocol): use american english (#15899)

Co-authored-by: Daniel Wang <[email protected]>
Co-authored-by: d1onys1us <[email protected]>

CONTRIBUTING.md

@@ -224,6 +224,8 @@ This section describes our documentation standards at Taiko.
 
 Use the [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/) as a base point of reference for writing style. Generally, don't worry too much about things like typos. What's more important is following the basic [philosophies](#philosophies) outlined above and following structural standards for highly readable and minimal documentation.
 
+For consistency throughout the project, please use **American English**.
+
 ### Creating content
 
 If you are interested in creating some content (video, blog post, tweet thread, visuals, etc.), you are absolutely free to do so. It's useful to get a peer review on these, if you need a peer review please reach out to the community / team on the [Taiko Discord](https://discord.gg/taikoxyz).

packages/protocol/contracts/tokenvault/adaptors/USDCAdaptor.sol → packages/protocol/contracts/tokenvault/adapters/USDCAdapter.sol

@@ -22,8 +22,8 @@ interface IUSDC {
     function transferFrom(address from, address to, uint256 value) external returns (bool);
 }
 
-/// @title USDCAdaptor
-contract USDCAdaptor is BridgedERC20Base {
+/// @title USDCAdapter
+contract USDCAdapter is BridgedERC20Base {
     IUSDC public usdc; // slot 1
     uint256[49] private __gap;
 

packages/protocol/docs/native_token_support.md

@@ -4,7 +4,7 @@
 
 Taiko's briding concept is a lock-and-mint type. It simply means (the red path above) on the canonical chain we take custody of the assets and on the destination chain we mint the wrapped counterpart. When someone wants to bridge back (from destination to canonical) it will first burn the tokens, then release the funds on the canonical chain.
 
-But there might be some incentives (e.g.: adoption, liquidity fragmentation, etc.) when deploying a native token on the destination chain is beneficial. For this reason Taiko introduced the possibilty of deploying the canonical assets (together with all their sub/parent/proxy contracts) and plug it into our ERC20Vault via adaptors (green path).
+But there might be some incentives (e.g.: adoption, liquidity fragmentation, etc.) when deploying a native token on the destination chain is beneficial. For this reason Taiko introduced the possibilty of deploying the canonical assets (together with all their sub/parent/proxy contracts) and plug it into our ERC20Vault via adapters (green path).
 
 Important to note that while wrapped asset briding is 'automatical', the native one requires the willingness and efforts from Taiko side (and maybe also original token issuer green light to recognise officially as "native"), to support that type of asset-transfer.
 
@@ -13,8 +13,8 @@ Important to note that while wrapped asset briding is 'automatical', the native
 There are some steps to do in order to facilitate native token bridging. In the next steps, here is a TLDR breakdown how we do it with USDC.
 
 1. Deploy the same (bytecode equivalent) ERC-20 token on L2. An example of the contracts + deployments can be found in our [USDC repo](https://github.com/taikoxyz/USDC).
-2. Deploy adaptor (e.g.: [USDC adaptor](../contracts/tokenvault/adaptors/USDCAdaptor.sol)). As this will serve as the plug-in to our `ERC20Vault` for custom (native) tokens. This adaptor serves multiple purposes. It is also a wrapper around the native token in a way - that it matches our conform `ERC20Vault` interfaces so that we can be sure any kind of native ERC-20 can be supported on L2. Also can handle custom logic required by the native asset (roles handling, specific logic, etc.).
+2. Deploy adapter (e.g.: [USDC adapter](../contracts/tokenvault/adapters/USDCAdapter.sol)). As this will serve as the plug-in to our `ERC20Vault` for custom (native) tokens. This adapter serves multiple purposes. It is also a wrapper around the native token in a way - that it matches our conform `ERC20Vault` interfaces so that we can be sure any kind of native ERC-20 can be supported on L2. Also can handle custom logic required by the native asset (roles handling, specific logic, etc.).
 3. Transfer the ownership (if not already owned by) to `ERC20Vault` owner since those 2 have to be owned by the same address. (!IMPORTANT! Not the token owned by the same owner, but the token adpter! USDC owner will still be Circle on L2.)
 4. Since our bridge is permissionless, there might have been some USDC bridge operations in the past. It would mean, there is already an existing `BridgedUSDC` on our L2. To overcome liquidity fragmentation, we (Taiko) need to call `ERC20Vault` `changeBridgedToken()` function with the appropriate parameters. This way the "old" `BridgedUSDC` can be migrated to this new native token and the bridging operation will mint into the new token frm that point on.
 
-The above steps (2. - 4.) is incorporated into the script [DeployUSDCAdaptor.s.sol](../script/DeployUSDCAdaptor.s.sol).
+The above steps (2. - 4.) is incorporated into the script [DeployUSDCAdapter.s.sol](../script/DeployUSDCAdapter.s.sol).

packages/protocol/script/DeployUSDCAdaptor.s.sol → packages/protocol/script/DeployUSDCAdapter.s.sol

@@ -14,13 +14,13 @@
 
 pragma solidity 0.8.24;
 
-import "../contracts/tokenvault/adaptors/USDCAdaptor.sol";
+import "../contracts/tokenvault/adapters/USDCAdapter.sol";
 import "../contracts/tokenvault/ERC20Vault.sol";
 import "../test/DeployCapability.sol";
 
-/// @title DeployUSDCAdaptor
-/// @notice This script deploys the adaptor contract for USDC.
-contract DeployUSDCAdaptor is DeployCapability {
+/// @title DeployUSDCAdapter
+/// @notice This script deploys the adapter contract for USDC.
+contract DeployUSDCAdapter is DeployCapability {
     address public usdcProxyL2 = vm.envAddress("NATIVE_USDC_PROXY_ON_L2");
     address public usdcProxyL1 = vm.envAddress("NATIVE_USDC_PROXY_ON_L1");
     address public l2SharedAddressManager = vm.envAddress("L2_SHARED_ADDRESS_MANAGER");
@@ -46,20 +46,20 @@ contract DeployUSDCAdaptor is DeployCapability {
         require(masterMinterPrivKey != 0, "invalid master minter priv key");
         vm.startBroadcast(deployerPrivKey);
         // Verify this contract after deployment (!)
-        address adaptorProxy = deployProxy({
-            name: "usdc_adaptor",
-            impl: address(new USDCAdaptor()),
-            data: abi.encodeCall(USDCAdaptor.init, (l2SharedAddressManager, IUSDC(usdcProxyL2)))
+        address adapterProxy = deployProxy({
+            name: "usdc_adapter",
+            impl: address(new USDCAdapter()),
+            data: abi.encodeCall(USDCAdapter.init, (l2SharedAddressManager, IUSDC(usdcProxyL2)))
         });
 
-        USDCAdaptor(adaptorProxy).transferOwnership(erc20VaultOwner);
+        USDCAdapter(adapterProxy).transferOwnership(erc20VaultOwner);
 
         vm.stopBroadcast();
 
-        // Grant the adaptor the minter role by master minter
+        // Grant the adapter the minter role by master minter
         vm.startBroadcast(masterMinterPrivKey);
         (bool success, bytes memory retVal) = address(usdcProxyL2).call(
-            abi.encodeWithSelector(configureMinterSelector, adaptorProxy, type(uint256).max)
+            abi.encodeWithSelector(configureMinterSelector, adapterProxy, type(uint256).max)
         );
 
         if (!success) {
@@ -80,7 +80,7 @@ contract DeployUSDCAdaptor is DeployCapability {
         });
 
         (success, retVal) = erc20Vault.call(
-            abi.encodeCall(ERC20Vault.changeBridgedToken, (canonicalToken, adaptorProxy))
+            abi.encodeCall(ERC20Vault.changeBridgedToken, (canonicalToken, adapterProxy))
         );
 
         if (!success) {