Finschia · egonspace · Jul 1, 2021 · Jun 30, 2021
@@ -31,8 +31,6 @@ acting as the "source zone". When the token is sent back to the chain it previou
 prefix is removed. This is a backwards movement in the token's timeline and the sender chain is
 acting as the "sink zone".
 
-It is strongly recommended to read the full details of [ADR 001: Coin Source Tracing](./../../../../../docs/architecture/adr-001-coin-source-tracing.md) to understand the implications and context of the IBC token representations.
-
 ### UX suggestions for clients
 
 For clients (wallets, exchanges, applications, block explorers, etc) that want to display the source of the token, it is recommended to use the following

@@ -4,7 +4,7 @@ order: 2
 
 # State
 
-The transfer IBC application module keeps state of the port to which the module is binded and the denomination trace information as outlined in [ADR 01](./../../../../../docs/architecture/adr-001-coin-source-tracing.md).
+The transfer IBC application module keeps state of the port to which the module is binded and the denomination trace information.
 
 - `Port`: `0x01 -> ProtocolBuffer(string)`
 - `DenomTrace`: `0x02 | []bytes(traceHash) -> ProtocolBuffer(DenomTrace)`
@@ -29,7 +29,7 @@ This message is expected to fail if:
 - `Sender` is empty
 - `Receiver` is empty
 - `TimeoutHeight` and `TimeoutTimestamp` are both zero
-- `Token.Denom` is not a valid IBC denomination as per [ADR 001 - Coin Source Tracing](./../../../../../docs/architecture/adr-001-coin-source-tracing.md).
+- `Token.Denom` is not a valid IBC denomination.
 
 This message will send a fungible token to the counterparty chain represented
 by the counterparty Channel End connected to the Channel End with the identifiers

@@ -4,7 +4,7 @@ order: 6
 
 # Metrics
 
-The transfer IBC application module exposes the following set of [metrics](./../../../../../docs/core/telemetry.md).
+The transfer IBC application module exposes the following set of metrics.
 
 | Metric                          | Description                                                                               | Unit            | Type    |
 |:--------------------------------|:------------------------------------------------------------------------------------------|:----------------|:--------|

@@ -11,7 +11,7 @@ parent:
 
 This paper defines the implementation of the ICS20 protocol on the Cosmos SDK.
 
-For the general specification please refer to the [ICS20 Specification](https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer).
+For the general specification please refer to the [ICS20 Specification](https://github.com/cosmos/ics/tree/master/spec/app/ics-020-fungible-token-transfer).
 
 ## Contents
 

@@ -4,9 +4,6 @@ order: 1
 
 # Concepts
 
-> NOTE: if you are not familiar with the IBC terminology and concepts, please read
-this [document](https://github.com/cosmos/ics/blob/master/ibc/1_IBC_TERMINOLOGY.md) as prerequisite reading.
-
 ## Client Creation, Updates, and Upgrades
 
 IBC clients are on chain light clients. The light client is responsible for verifying
@@ -128,7 +125,7 @@ The IBC interfaces expect an `ibcexported.Height` interface, however all clients
 
 ## Connection Handshake
 
-The connection handshake occurs in 4 steps as defined in [ICS 03](https://github.com/cosmos/ics/tree/master/spec/ics-003-connection-semantics).
+The connection handshake occurs in 4 steps as defined in [ICS 03](https://github.com/cosmos/ics/tree/master/spec/core/ics-003-connection-semantics).
 
 `ConnOpenInit` is the first attempt to initialize a connection on the executing chain. 
 The handshake is expected to succeed if the version selected is supported. The connection 
@@ -207,7 +204,7 @@ versions should have a unique version identifier.
 
 ## Channel Handshake
 
-The channel handshake occurs in 4 steps as defined in [ICS 04](https://github.com/cosmos/ics/tree/master/spec/ics-004-channel-and-packet-semantics).
+The channel handshake occurs in 4 steps as defined in [ICS 04](https://github.com/cosmos/ics/tree/master/spec/core/ics-004-channel-and-packet-semantics).
 
 `ChanOpenInit` is the first attempt to initialize a channel on top of an existing connection. 
 The handshake is expected to succeed if the version selected for the existing connection is a 
@@ -355,7 +352,7 @@ Each packet is required to have at least one valid timeout field.
 
 ## Closing Channels
 
-Closing a channel occurs in occurs in 2 handshake steps as defined in [ICS 04](https://github.com/cosmos/ics/tree/master/spec/ics-004-channel-and-packet-semantics).
+Closing a channel occurs in occurs in 2 handshake steps as defined in [ICS 04](https://github.com/cosmos/ics/tree/master/spec/core/ics-004-channel-and-packet-semantics).
 
 `ChanCloseInit` will close a channel on the executing chain if the channel exists, it is not 
 already closed and the connection it exists upon is OPEN. Channels can only be closed by a 
@@ -370,7 +367,7 @@ that the counterparty channel has been closed.
 
 ## Hostname Validation
 
-Hostname validation is implemented as defined in [ICS 24](https://github.com/cosmos/ics/tree/master/spec/ics-024-host-requirements).
+Hostname validation is implemented as defined in [ICS 24](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements).
 
 The 24-host sub-module parses and validates identifiers. It also builds 
 the key paths used to store IBC related information. 

@@ -4,7 +4,7 @@ order: 2
 
 # State
 
-The paths for the values stored in state is defined [here](https://github.com/cosmos/ics/blob/master/spec/ics-024-host-requirements/README.md#path-space).
+The paths for the values stored in state is defined [here](https://github.com/cosmos/ics/blob/master/spec/core/ics-024-host-requirements/README.md#path-space).
 Additionally, the SDK adds a prefix to the path to be able to aggregate the values for querying purposes.
 The client type is not stored since it can be obtained through the client state. 
 

@@ -9,7 +9,7 @@ parent:
 
 ## Abstract
 
-This specification defines the implementation of the IBC protocol on the Cosmos SDK, the
+This specification defines the implementation of the IBC protocol on the LFB SDK, the
 changes made to the specification and where to find each specific ICS spec within
 the module.
 
@@ -31,7 +31,7 @@ For the general specification please refer to the [Interchain Standards](https:/
 
 ## Implementation Details
 
-As stated above, the IBC implementation on the Cosmos SDK introduces some changes
+As stated above, the IBC implementation on the LFB SDK introduces some changes
 to the general specification, in order to avoid code duplication and to take
 advantage of the SDK architectural components such as the transaction routing
 through `Handlers`.
@@ -41,44 +41,26 @@ through `Handlers`.
 The following list is a mapping from each Interchain Standard to their implementation
 in the SDK's `x/ibc` module:
 
-* [ICS 002 - Client Semantics](https://github.com/cosmos/ics/tree/master/spec/ics-002-client-semantics): Implemented in [`x/ibc/core/02-client`](https://github.com/cosmos/tree/master/ibc/core/02-client)
-* [ICS 003 - Connection Semantics](https://github.com/cosmos/ics/blob/master/spec/ics-003-connection-semantics): Implemented in [`x/ibc/core/03-connection`](https://github.com/cosmos/tree/master/ibc/core/03-connection)
-* [ICS 004 - Channel and Packet Semantics](https://github.com/cosmos/ics/blob/master/spec/ics-004-channel-and-packet-semantics): Implemented in [`x/ibc/core/04-channel`](https://github.com/cosmos/tree/master/ibc/core/04-channel)
-* [ICS 005 - Port Allocation](https://github.com/cosmos/ics/blob/master/spec/ics-005-port-allocation): Implemented in [`x/ibc/core/05-port`](https://github.com/cosmos/tree/master/ibc/core/05-port)
-* [ICS 006 - Solo Machine Client](https://github.com/cosmos/ics/blob/master/spec/ics-006-solo-machine-client): Implemented in [`x/ibc/light-clients/06-solomachine`](https://github.com/cosmos/tree/master/ibc/solomachine)
-* [ICS 007 - Tendermint Client](https://github.com/cosmos/ics/blob/master/spec/ics-007-tendermint-client): Implemented in [`x/ibc/light-clients/07-tendermint`](https://github.com/cosmos/tree/master/ibc/light-clients/07-tendermint)
-* [ICS 009 - Loopback Client](https://github.com/cosmos/ics/blob/master/spec/ics-009-loopback-client):  Implemented in [`x/ibc/light-clients/09-localhost`](https://github.com/cosmos/tree/master/ibc/light-clients/09-localhost)
-* [ICS 018- Relayer Algorithms](https://github.com/cosmos/ics/tree/master/spec/ics-018-relayer-algorithms): Implemented in it's own [relayer repository](https://github.com/cosmos/relayer)
-* [ICS 020 - Fungible Token Transfer](https://github.com/cosmos/ics/tree/master/spec/ics-020-fungible-token-transfer): Implemented in [`x/ibc/applications/transfer`](https://github.com/cosmos/tree/master/ibc/applications/transfer)
-* [ICS 023 - Vector Commitments](https://github.com/cosmos/ics/tree/master/spec/ics-023-vector-commitments): Implemented in [`x/ibc/core/23-commitment`](https://github.com/cosmos/tree/master/ibc/core/23-commitment)
-* [ICS 024 - Host Requirements](https://github.com/cosmos/ics/tree/master/spec/ics-024-host-requirements): Implemented in [`x/ibc/core/24-host`](https://github.com/cosmos/tree/master/ibc/core/24-host)
-* [ICS 025 - Handler Interface](https://github.com/cosmos/ics/tree/master/spec/ics-025-handler-interface): `Handler` interfaces are implemented at the top level in `x/ibc/handler.go`,
+* [ICS 002 - Client Semantics](https://github.com/cosmos/ibc/tree/master/spec/core/ics-002-client-semantics): Implemented in [`x/ibc/core/02-client`](github.com/line/lfb-sdk/tree/main/x/ibc/core/02-client)
+* [ICS 003 - Connection Semantics](https://github.com/cosmos/ibc/tree/master/spec/core/ics-003-connection-semantics): Implemented in [`x/ibc/core/03-connection`](github.com/line/lfb-sdk/tree/main/x/ibc/core/03-connection)
+* [ICS 004 - Channel and Packet Semantics](https://github.com/cosmos/ibc/tree/master/spec/core/ics-004-channel-and-packet-semantics): Implemented in [`x/ibc/core/04-channel`](github.com/line/lfb-sdk/tree/main/x/ibc/core/04-channel)
+* [ICS 005 - Port Allocation](https://github.com/cosmos/ics/blob/master/spec/core/ics-005-port-allocation): Implemented in [`x/ibc/core/05-port`](github.com/line/lfb-sdk/tree/main/x/ibc/core/05-port)
+* [ICS 006 - Solo Machine Client](https://github.com/cosmos/ics/blob/master/spec/client/ics-006-solo-machine-client): Implemented in [`x/ibc/light-clients/06-solomachine`](https://github.com/line/lfb-sdk/tree/main/x/ibc/light-clients/06-solomachine)
+* [ICS 007 - Tendermint Client](https://github.com/cosmos/ics/blob/master/spec/client/ics-007-tendermint-client): Implemented in [`x/ibc/light-clients/07-tendermint`](https://github.com/line/lfb-sdk/tree/main/x/ibc/light-clients/07-tendermint)
+* [ICS 009 - Loopback Client](https://github.com/cosmos/ibc/tree/master/spec/client/ics-009-loopback-client):  Implemented in [`x/ibc/light-clients/09-localhost`](https://github.com/line/lfb-sdk/tree/main/x/ibc/light-clients/09-localhost)
+* [ICS 018- Relayer Algorithms](https://github.com/cosmos/ibc/tree/master/spec/relayer/ics-018-relayer-algorithms): Not implemented yet.
+* [ICS 020 - Fungible Token Transfer](https://github.com/cosmos/ibc/tree/master/spec/app/ics-020-fungible-token-transfer): Implemented in [`x/ibc/applications/transfer`](https://github.com/line/lfb-sdk/tree/main/x/ibc/applications/transfer)
+* [ICS 023 - Vector Commitments](https://github.com/cosmos/ibc/tree/master/spec/core/ics-023-vector-commitments): Implemented in [`x/ibc/core/23-commitment`](github.com/line/lfb-sdk/tree/main/x/ibc/core/23-commitment)
+* [ICS 024 - Host Requirements](https://github.com/cosmos/ics/tree/master/spec/core/ics-024-host-requirements): Implemented in [`x/ibc/core/24-host`](github.com/line/lfb-sdk/tree/main/x/ibc/core/24-host)
+* [ICS 025 - Handler Interface](https://github.com/cosmos/ics/tree/master/spec/core/ics-025-handler-interface): `Handler` interfaces are implemented at the top level in `x/ibc/handler.go`,
 which call each ICS submodule's handlers (i.e `x/ibc/*/{XX-ICS}/handler.go`).
-* [ICS 026 - Routing Module](https://github.com/cosmos/ics/blob/master/spec/ics-026-routing-module): Replaced by [ADR 15 - IBC Packet Receiver](../../../docs/architecture/adr-015-ibc-packet-receiver.md).
-
-### Architecture Decision Records (ADR)
-
-The following ADR provide the design and architecture decision of IBC-related components.
-
-* [ADR 001 - Coin Source Tracing](../../../docs/architecture/adr-001-coin-source-tracing.md): standard to hash the ICS20's fungible token
-denomination trace path in order to support special characters and limit the maximum denomination length.
-* [ADR 17 - Historical Header Module](../../../docs/architecture/adr-017-historical-header-module.md): Introduces the ability to introspect past
-consensus states in order to verify their membership in the counterparty clients.
-* [ADR 19 - Protobuf State Encoding](../../../docs/architecture/adr-019-protobuf-state-encoding.md): Migration from Amino to Protobuf for state encoding.
-* [ADR 020 - Protocol Buffer Transaction Encoding](./../../docs/architecture/adr-020-protobuf-transaction-encoding.md): Client side migration to Protobuf.
-* [ADR 021 - Protocol Buffer Query Encoding](../../../docs/architecture/adr-020-protobuf-query-encoding.md): Queries migration to Protobuf.
-* [ADR 026 - IBC Client Recovery Mechanisms](../../../docs/architecture/adr-026-ibc-client-recovery-mechanisms.md): Allows IBC Clients to be recovered after freezing or expiry.
 
 ### SDK Modules
 
-* [`x/capability`](https://github.com/cosmos/tree/master/x/capability): The capability module provides object-capability keys support through scoped keepers in order to authenticate usage of ports or channels. Check [ADR 3 - Dynamic Capability Store](../../../docs/architecture/adr-003-dynamic-capability-store.md) for more details.
+* [`x/capability`](https://github.com/line/lfb-sdk/tree/main/x/capability): The capability module provides object-capability keys support through scoped keepers in order to authenticate usage of ports or channels. Check [ADR 3 - Dynamic Capability Store](../../../docs/architecture/adr-003-dynamic-capability-store.md) for more details.
 
 ## IBC module architecture
 
-> **NOTE for auditors**: If you're not familiar with the overall module structure from
-the SDK modules, please check this [document](../../../docs/building-modules/structure.md) as
-prerequisite reading.
-
 For ease of auditing, every Interchain Standard has been developed in its own
 package. The development team separated the IBC TAO (Transport, Authentication, Ordering) ICS specifications from the IBC application level
 specification. The following tree describes the architecture of the directories that

@@ -17,7 +17,7 @@ and defines overall functioning of the staking module.
 
 - Params: `Paramsspace("staking") -> legacy_amino(params)`
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.1/proto/cosmos/staking/v1beta1/staking.proto#L230-L241
++++ https://github.com/line/lfb-sdk/blob/main/proto/lfb/staking/v1beta1/staking.proto#L269-L284
 
 ## Validator
 
@@ -70,9 +70,7 @@ is updated during the validator set update process which takes place in [`EndBlo
 
 Each validator's state is stored in a `Validator` struct:
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L65-L99
-
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L24-L63
++++ https://github.com/line/lfb-sdk/blob/main/proto/lfb/staking/v1beta1/staking.proto#L83-L120
 
 ## Delegation
 
@@ -86,7 +84,7 @@ funds are held in a `Delegation` data structure. It is owned by one
 delegator, and is associated with the shares for one validator. The sender of
 the transaction is the owner of the bond.
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L159-L170
++++ https://github.com/line/lfb-sdk/blob/main/proto/lfb/staking/v1beta1/staking.proto#L183-L194
 
 ### Delegator Shares
 
@@ -125,7 +123,7 @@ slashed.
 
 A UnbondingDelegation object is created every time an unbonding is initiated.
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L172-L198
++++ https://github.com/line/lfb-sdk/blob/main/proto/lfb/staking/v1beta1/staking.proto#L198-L209
 
 ## Redelegation
 
@@ -153,7 +151,7 @@ A redelegation object is created every time a redelegation occurs. To prevent
 - and, the (re)delegator is attempting to create a _new_ redelegation
   where the source validator for this new redelegation is `Validator-X`.
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L200-L228
++++ https://github.com/line/lfb-sdk/blob/main/proto/lfb/staking/v1beta1/staking.proto#L253-L266
 
 ## Queues
 
@@ -168,14 +166,14 @@ used is a slight modification of the RFC3339Nano and uses the the format string
 In all cases, the stored timestamp represents the maturation time of the queue
 element.
 
-### UnbondingDelegationQueue
+### UnbondingDelegationEntry
 
 For the purpose of tracking progress of unbonding delegations the unbonding
 delegations queue is kept.
 
 - UnbondingDelegation: `0x41 | format(time) -> []DVPair`
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L123-L133
++++ https://github.com/line/lfb-sdk/blob/main/proto/lfb/staking/v1beta1/staking.proto#L212-L229
 
 ### RedelegationQueue
 
@@ -184,7 +182,7 @@ kept.
 
 - UnbondingDelegation: `0x42 | format(time) -> []DVVTriplet`
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L140-L152
++++ https://github.com/line/lfb-sdk/blob/main/proto/lfb/staking/v1beta1/staking.proto#L232-L249
 
 ### ValidatorQueue
 
@@ -203,7 +201,7 @@ that multiple validators exist in the queue at the same location.
 HistoricalInfo objects are stored and pruned at each block such that the staking keeper persists
 the `n` most recent historical info defined by staking module parameter: `HistoricalEntries`.
 
-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.40.0/proto/cosmos/staking/v1beta1/staking.proto#L15-L22
++++ https://github.com/line/lfb-sdk/blob/main/proto/lfb/staking/v1beta1/staking.proto#L19-L22
 
 At each BeginBlock, the staking keeper will persist the current Header and the Validators that committed
 the current block in a `HistoricalInfo` object. The Validators are sorted on their address to ensure that