fixed docs

docs/common/bridging/001-bridging.md

@@ -7,5 +7,5 @@ title: Bridging
 
 Bridging documentation describes current existing implementations over our cross-chain messaging protocol.
 
-* [Bridging identity from Polygon](./002-identity.md) 
+* [Bridging identity from Polygon](./002-identity.md)
 * [Bridging identity from Rarimo](./003-rarimo-identity.md) 

docs/common/bridging/002-identity.md

@@ -35,14 +35,20 @@ TBD
 In the current implementation the identity saver subscribes to the certain EVM chain state smart contract and tracks the `StateLibStateUpdated` events.
 
 Event definition:
+
 ```go
+package main
+
+import "math/big"
+
 type StateLibStateUpdated struct {
-	Id        *big.Int
-	BlockN    *big.Int
-	Timestamp *big.Int
-	State     *big.Int
-	Raw       types.Log // Blockchain specific contextual infos
+  Id        *big.Int
+  BlockN    *big.Int
+  Timestamp *big.Int
+  State     *big.Int
+  Raw       types.Log // Blockchain specific contextual infos
 }
+
 ```
 
 The following configuration .yaml file should be provided to launch your oracle:

docs/common/bridging/003-rarimo-identity.md

@@ -10,7 +10,9 @@ that allows to skip transferring from Polygon to Rarimo in default flow. Also, a
 aggregated into one Merkle hash that allows us to update all states by single transaction.
 
 Generally, common flow looks like this:
-- There is an operation type `IDENTITY_AGGREGATED_TRANSFER` that is used to transfer aggregated identity state overall issuers.
+
+- There is an operation type `IDENTITY_AGGREGATED_TRANSFER` that is used to transfer aggregated identity state overall
+  issuers.
 
 - Issuer publishes state transition into Rarimo EVM identity state contract.
   That state contract is fully compatible with original Iden3 state smartcontract.
@@ -19,27 +21,36 @@ Generally, common flow looks like this:
 
 - In the `identiy` module `EndBlock` method the corresponding operation will be created.
 
-- After some time, the threshold signature producers provides the ECDSA signature for aggregated state update information hash.
+- After some time, the threshold signature producers provides the ECDSA signature for aggregated state update
+  information hash.
 
-- There is a [modified state smart contracts](https://gitlab.com/rarimo/rarimoid/state-contracts) that accepts aggregated state updates with ECDSA signature instead of ZK proof of state update validity.
+- There is a [modified state smart contracts](https://gitlab.com/rarimo/rarimoid/state-contracts) that accepts
+  aggregated state updates with ECDSA signature instead of ZK proof of state update validity.
 
 - Such smart contract should be deployed into every chain that we have to support.
 
-- The information about state update with its witness (ECDSA signature) can be delivered into modified state smart contracts on the target chain by everyone.
-  After such signed update execution, all state updates on Rarimo chain becomes delivered on target chain by single transaction.
+- The information about state update with its witness (ECDSA signature) can be delivered into modified state smart
+  contracts on the target chain by everyone.
+  After such signed update execution, all state updates on Rarimo chain becomes delivered on target chain by single
+  transaction.
 
 ----
 
 ## DApp flow:
 
 On the DApp side the following flow should be executed to use our aggregated state:
 
-1. Get state information from Rarimo: `/rarimo/rarimo-core/identity/state/{id}`. Also get path from `/rarimo/rarimo-core/identity/state/{id}/proof`.
+1. Get state information from Rarimo: `/rarimo/rarimo-core/identity/state/{id}`. Also get path
+   from `/rarimo/rarimo-core/identity/state/{id}/proof`.
 
 2. If the last state update timestamp is equal (or less) to the timestamp on target chain - go to (5).
 
-3. Using `lastUpdateOperationIndex` call: `/rarimo/rarimo-core/rarimocore/operation/{index}`. It provides the information about GISTRoot and StatesRoot hash. Use it in state transition.
+3. Using `lastUpdateOperationIndex` call: `/rarimo/rarimo-core/rarimocore/operation/{index}`. It provides the
+   information about GISTRoot and StatesRoot hash. Use it in state transition.
 
-4. Using `lastUpdateOperationIndex` call: `/rarimo/rarimo-core/rarimocore/operation/{index}/proof`. Using signature, path and information from previous request execute `signedStateTransition` on target chain state smart contract.
+4. Using `lastUpdateOperationIndex` call: `/rarimo/rarimo-core/rarimocore/operation/{index}/proof`. Using signature,
+   path and information from previous request execute `signedStateTransition` on target chain state smart contract.
 
-5. Generate ZKP using state information from (1) request. Execute ZKP verification on [modified Verificator contract](https://gitlab.com/rarimo/rarimoid/state-contracts) using generated proof information, information and path from (1).
+5. Generate ZKP using state information from (1) request. Execute ZKP verification
+   on [modified Verificator contract](https://gitlab.com/rarimo/rarimoid/state-contracts) using generated proof
+   information, information and path from (1).

docs/common/contracts/001-contracts.md

@@ -6,7 +6,8 @@ title: Smart-contracts overview
 # Smart-contracts overview
 
 Rarimo smart-contracts are the primary way to interact with our multi-chain protocol.
-Developers can send data, assets, or liquidity; build cross-chain integrations; or retrieve protocol information using these contracts.
+Developers can send data, assets, or liquidity; build cross-chain integrations; or retrieve protocol information using
+these contracts.
 Whenever possible, we made sure to maintain similar interface and signatures to make integrating cross-chain easy.
 
 ----
@@ -18,5 +19,6 @@ Whenever possible, we made sure to maintain similar interface and signatures to
 - Repo: [EVM Bridge](https://github.com/rarimo/contracts/evm-bridge)
 
 Documentation:
+
 * [Bridge architecture](./002-bridge.md)
 * [Bridge comission architecture](./003-commission.md)

docs/common/contracts/002-bridge.md

@@ -5,19 +5,23 @@ title: Bridge overview
 
 # Bridge overview
 
-Rarimo decentralized bridge contract is responsible for managing deposits and withdrawals for Native, fungible and non-fungible tokens. All withdrawal operations are protected by ECDSA secp256k1 threshold (t-n) signature.
+Rarimo decentralized bridge contract is responsible for managing deposits and withdrawals for Native, fungible and
+non-fungible tokens. All withdrawal operations are protected by ECDSA secp256k1 threshold (t-n) signature.
 This signature is produced by core multi-sig services depending on the validated core state.
 
-The core service stores information to be signed in `operation` entries. `Operation` data structure consist of the following fields:
+The core service stores information to be signed in `operation` entries. `Operation` data structure consist of the
+following fields:
+
 - index
 - operation type
 - details
 - is signed
 - creator address
 - timestamp
 
+For token transfer there is an operation type `Type_TRANSFER` and the details field contain the following proto-encoded
+information:
 
-For token transfer there is an operation type `Type_TRANSFER` and the details field contain the following proto-encoded information:
 - origin hash (hash of tx, id and current network)
 - tx
 - event id (or operation id)
@@ -28,7 +32,11 @@ For token transfer there is an operation type `Type_TRANSFER` and the details fi
 - bundle info (data and salt)
 - token information
 
-For signing operations, the signature producer turns the operation content into special Merkle leaf content, creates a Merkle tree, signs its hash and submits the confirmation operation to the core. After, operation will be marked as signed and users can pool signature and operation information to submit into the bridge contract on the target chain. Smart-contract on the target chain should accept all information, perform validation, withdraw the corresponding token, and store information about the completed withdrawals to prevent double-spending.
+For signing operations, the signature producer turns the operation content into special Merkle leaf content, creates a
+Merkle tree, signs its hash and submits the confirmation operation to the core. After, operation will be marked as
+signed and users can pool signature and operation information to submit into the bridge contract on the target chain.
+Smart-contract on the target chain should accept all information, perform validation, withdraw the corresponding token,
+and store information about the completed withdrawals to prevent double-spending.
 
 ----
 
@@ -40,7 +48,8 @@ Common transfer hash can be derived from the following sequence:
 OriginHash is a hash of `tx | eventId | current network`.
 Some parameters can be empty.
 
-On our bridge currently supports the following token types: Native / ERC20 / ERC721 / ERC1155 / MetaplexFT / MetaplexNFT / NearFT / NearNFT
+On our bridge currently supports the following token types: Native / ERC20 / ERC721 / ERC1155 / MetaplexFT /
+MetaplexNFT / NearFT / NearNFT
 
 ----
 
@@ -55,12 +64,17 @@ On our bridge currently supports the following token types: Native / ERC20 / ERC
 
 ## Bridging flow
 
-1. User wants to transfer the token from the current chain to the target one. For this, user submits a deposit transaction to the current chain bridge smart-contract.
-2. Any other external services (or users by themselves) submit deposit information into the core service. Core service performs transaction validation before adding them to the ledger.
+1. User wants to transfer the token from the current chain to the target one. For this, user submits a deposit
+   transaction to the current chain bridge smart-contract.
+2. Any other external services (or users by themselves) submit deposit information into the core service. Core service
+   performs transaction validation before adding them to the ledger.
 3. External services (signature producers) observe new operations in the core state and add them to the local pool.
-4. Signature producers combine deposits into the Merkle tree, produce the threshold signature, and submit that info to the core. Core service performs the Merkle tree data and signature validation before adding it to the ledger.
-5. After signed deposit information appears in the core state it becomes possible to call the withdrawal operation on the target network.
-6. Smart-contract on the target network validates information about the deposit, Merkle path, and signature for the Merkle root, and performs a token withdrawal.
+4. Signature producers combine deposits into the Merkle tree, produce the threshold signature, and submit that info to
+   the core. Core service performs the Merkle tree data and signature validation before adding it to the ledger.
+5. After signed deposit information appears in the core state it becomes possible to call the withdrawal operation on
+   the target network.
+6. Smart-contract on the target network validates information about the deposit, Merkle path, and signature for the
+   Merkle root, and performs a token withdrawal.
 
 
 

docs/common/contracts/003-commission.md

@@ -10,6 +10,7 @@ To maintain successful work and reward validators and other people that support
 should charge protocol usage fee.
 
 Protocol fee in Rarimo will be charged for every type of cross-chain token transfer:
+
 - Native
 - FT
 - and NFT transfers.
@@ -21,8 +22,10 @@ For every transfer we will charge a constant amount on start and prepare ground
 ## Architecture
 
 In parameters, fee smart contract should contain the acceptable token addresses list,
-amount for every token to be charged and bridge contract address. Those parameters should be managed by threshold signature.
-To check the signature fee contract should execute a cross-contract call to the bridge contract to fetch the threshold public key.
+amount for every token to be charged and bridge contract address. Those parameters should be managed by threshold
+signature.
+To check the signature fee contract should execute a cross-contract call to the bridge contract to fetch the threshold
+public key.
 
 ----
 
@@ -33,11 +36,12 @@ address of selected fee token. Deposit method should check if the provided token
 If everything is well, deposit method performs charging of the corresponding fee amount and executes
 deposit method on the bridge contract.
 
-
 Lets described flow more accurately:
+
 1. User selects the fee token and calls the deposit method on the fee contract.
 2. Fee contract checks if the token is available to be charged fee in, and gets the fee amount.
-3. Fee contract charges a fee amount from the user. (If it is EVM or Near, the approval token method should be called before by the user).
+3. Fee contract charges a fee amount from the user. (If it is EVM or Near, the approval token method should be called
+   before by the user).
 4. If charging was successful, the fee contract calls a bridge contract with provided deposit arguments.
 
 Also bridge smart-contract should be extended to receive deposit calls only from corresponding fee smart-contract.
@@ -55,10 +59,12 @@ The public key should be taken from the bridge contract state.
 
 ## Management
 
-For managing fee tokens, fee smart-contract should implement the **AddFeeToken**, **UpdateFeeToken**, **RemoveFeeToken**,
+For managing fee tokens, fee smart-contract should implement the **AddFeeToken**, **UpdateFeeToken**, **RemoveFeeToken
+**,
 **Withdraw** methods that accept token information and signature for corresponding hash.
 
 Let’s define the operation type enum with the following fields:
+
 ```
 0 => AddFeeToken
 1 => RemoveFeeToken
@@ -69,36 +75,38 @@ Let’s define the operation type enum with the following fields:
 Let’s described flow more accurately:
 
 1. Core provides signature and data to be changed on the fee contract.
-  For the AddFeeToken, UpdateFeeToken and RemoveFeeToken operation it should be:
-  __HASH(
-  nonce 32 byte,
-  contract addr,
-  network name,
-  operation type,
-  token addr if non-native otherwise none (in evm 20 zero bytes for native),
-  amount
-  )__
+   For the AddFeeToken, UpdateFeeToken and RemoveFeeToken operation it should be:
+   __HASH(
+   nonce 32 byte,
+   contract addr,
+   network name,
+   operation type,
+   token addr if non-native otherwise none (in evm 20 zero bytes for native),
+   amount
+   )__
 
 2. For the withdrawal operation it should be:
-  __HASH(
-  nonce 32 byte,
-  receiver address,
-  contract addr,
-  network name,
-  operation type,
-  token addr if non-native otherwise none (in evm 20 zero bytes for native),
-  amount
-  )__
+   __HASH(
+   nonce 32 byte,
+   receiver address,
+   contract addr,
+   network name,
+   operation type,
+   token addr if non-native otherwise none (in evm 20 zero bytes for native),
+   amount
+   )__
 
 3. Someone submits that information to the fee smart-contract.
 
-4. Fee contract calculates hash of provided data and checks that signature public key corresponds to the key on bridge smart contract.
+4. Fee contract calculates hash of provided data and checks that signature public key corresponds to the key on bridge
+   smart contract.
 
 5. If all checks were correct, fee smart-contract updates state according to the provided information.
 
 ----
 
 ## Conclusion
 
-On different networks the smart contracts architecture can be may differ from what is described cause of chain smart contracts peculiarities.
+On different networks the smart contracts architecture can be may differ from what is described cause of chain smart
+contracts peculiarities.
 Explore every contract by yourself to gent better understanding.