Fix Typo in Multiple Files (l2beat#6224)

packages/config/src/projects/bridges/skaleIMA.ts

@@ -78,7 +78,7 @@ export const skaleIMA: Bridge = {
     validation: {
       name: 'Validation',
       description:
-        'SKALE IMA Bridge operates on SKALE Network nodes for connected SKALE chain. Messages are signed by BLS secret key with a 11 out of 16 threshold, then sent and validated on Ethereum. The validator set signing the message is the same one that is used for the consensus of the SKALE chain, making the bridge as secure as the chain itself. Since the state root is not sent to L1, the bridge and the chain state can diverge.',
+        'SKALE IMA Bridge operates on SKALE Network nodes for connected SKALE chain. Messages are signed by BLS secret key with an 11 out of 16 threshold, then sent and validated on Ethereum. The validator set signing the message is the same one that is used for the consensus of the SKALE chain, making the bridge as secure as the chain itself. Since the state root is not sent to L1, the bridge and the chain state can diverge.',
       references: [
         {
           text: 'SKALE IMA Bridge - Overview',

packages/config/src/projects/layer3s/superposition.ts

@@ -10,7 +10,7 @@ export const superposition: Layer3 = upcomingL3({
     name: 'Superposition',
     slug: 'superposition',
     description:
-      'Superposition is an upcoming Layer 3 powered by Arbitrum Orbit. It is the ultimate yield centric blockchain that pays users and developers to use it. Superposition offers novel incentive mechanisms such as Utility Mining and Super Assets and an native onchain order book built using Stylus that provides shared liquidity for the ecosystem.',
+      'Superposition is an upcoming Layer 3 powered by Arbitrum Orbit. It is the ultimate yield centric blockchain that pays users and developers to use it. Superposition offers novel incentive mechanisms such as Utility Mining and Super Assets and a native onchain order book built using Stylus that provides shared liquidity for the ecosystem.',
     purposes: ['Universal'],
     category: 'Optimium',
     provider: 'Arbitrum',

packages/config/src/projects/other/da-beat/blockchain/celestia/bridges/blobstream/BlobstreamX/arbitrum.ts

@@ -43,7 +43,7 @@ export const blobstreamArbitrum = CELESTIA_BLOBSTREAM({
       The BlobstreamX bridge is composed of three main components: the **BlobstreamX** contract, the **Succinct Gateway** contract and the **Verifier** contracts.
       By default, BlobstreamX operates asynchronously, handling requests in a fulfillment-based manner. First, zero-knowledge proofs of Celestia block ranges are requested for proving. Requests can be submitted either off-chain through the Succinct API, or onchain through the requestDataHeader() method of the blobstreamX smart contract.
       Once a proving request is received, the off-chain prover generates the proof and submits it to the Succinct Gateway contract. The Succinct Gateway contract verifies the proof with the corresponding verifier contract and, if successful, calls the blobstreamX contract to store the data commitment.
-      Alternatively, it is possible to run an Blobstream X operator with local proving, allowing for self-generation of the proofs.
+      Alternatively, it is possible to run a Blobstream X operator with local proving, allowing for self-generation of the proofs.
 
       Verifying a header range includes verifying Tendermint consensus (header signatures are 2/3 of stake) and verifying the data commitment root. This is achieved through a combined circuit. This combined circuit is made up of two parts:
       1) **TendermintX** circuit is used to verify tendermint consensus,

packages/config/src/projects/other/da-beat/blockchain/celestia/bridges/blobstream/BlobstreamX/base.ts

@@ -43,7 +43,7 @@ export const blobstreamBase = CELESTIA_BLOBSTREAM({
       The BlobstreamX bridge is composed of three main components: the **BlobstreamX** contract, the **Succinct Gateway** contract and the **Verifier** contracts.
       By default, BlobstreamX operates asynchronously, handling requests in a fulfillment-based manner. First, zero-knowledge proofs of Celestia block ranges are requested for proving. Requests can be submitted either off-chain through the Succinct API, or onchain through the requestDataHeader() method of the blobstreamX smart contract.
       Once a proving request is received, the off-chain prover generates the proof and submits it to the Succinct Gateway contract. The Succinct Gateway contract verifies the proof with the corresponding verifier contract and, if successful, calls the blobstreamX contract to store the data commitment.
-      Alternatively, it is possible to run an Blobstream X operator with local proving, allowing for self-generating the proofs.
+      Alternatively, it is possible to run a Blobstream X operator with local proving, allowing for self-generating the proofs.
 
       Verifying a header range includes verifying tendermint consensus (header signatures are 2/3 of stake) and verifying the data commitment root. This is achieved through a combined circuit. This combined circuit is made up of two parts:
       1) **TendermintX** circuit is used to verify tendermint consensus,

packages/config/src/tvl/amounts/aggLayerNativeEtherPreminted.ts

@@ -17,7 +17,7 @@ export function getAggLayerNativeEtherPremintedEntry(
   assert(escrow.sharedEscrow?.type === 'AggLayer')
   assert(chain.minTimestampForTvl, 'Chain should have minTimestampForTvl')
 
-  // We are hardcoding assetId because aggLayerNativeEtherPreminted is an canonical token
+  // We are hardcoding assetId because aggLayerNativeEtherPreminted is a canonical token
   const assetId = AssetId.create(ethereum.name, 'native')
   const type = 'aggLayerNativeEtherPreminted'
   const dataSource = `${chain.name}_agglayer`

packages/config/src/tvl/amounts/elasticChainEther.ts

@@ -34,7 +34,7 @@ export function getElasticChainEtherEntry(
     : (escrow.includeInTotal ?? true)
   const isAssociated = !!project.associatedTokens?.includes(token.symbol)
 
-  // We are hardcoding assetId because elasticChainEther is an canonical token
+  // We are hardcoding assetId because elasticChainEther is a canonical token
   const assetId = AssetId.create(ethereum.name, 'native')
   const type = 'elasticChainEther'
   const dataSource = `${project.projectId}_elastic_chain`