From b741e49ed24d3737a986e7709f2263084aa6ed28 Mon Sep 17 00:00:00 2001 From: womensrights Date: Wed, 20 Mar 2024 13:47:37 +0100 Subject: [PATCH] fix linter and remove commented guide --- ...path-unwinding-forwarding -requirements.md | 31 +++---------------- 1 file changed, 4 insertions(+), 27 deletions(-) diff --git a/docs/requirements/path-unwinding-forwarding -requirements.md b/docs/requirements/path-unwinding-forwarding -requirements.md index 92bd291d740..1e931058a02 100644 --- a/docs/requirements/path-unwinding-forwarding -requirements.md +++ b/docs/requirements/path-unwinding-forwarding -requirements.md @@ -8,33 +8,22 @@ Path Unwinding reduces the complexity of token transfer for the end user; a user In addition to unwinding, when a user recieves their token on a destination chain, they then want to use the token in some way. By enabling token forwarding, a user can recieve a token, perform some action with that token, for example a swap, and then send the token onto another chain. We observe that the complexity of IBC is increasingly being abstracted away from end users and automating workflows such as transfer, swap and forward with a single signed transaction significantly enhances usability. - ## Problem - - A fungible token A transferred from chain A to chain B is an ibc denomination at chain B, where the ibc denom trace records the path the token has travelled to reach its destination chain. - - A user now wants to send this ibc denomination of token A, originating from chain A, onto another chain, chain C. If a user transfers token A on chain B directly to chain C, it will not be fungible with token A sent directly from chain A to chain B. This is because the ibc denomination of token A on chain C is different in both cases due to token A travelling along different paths to reach the same destination. This is the most simple case of the problem involving only 3 chains. However, this problem is prevalent within the ecosystem and there are cases of ibc denominations on chains with >2 hops in the path. Regarding forwarding, if a user wants to transfer tokens between chains, then perform an action with those tokens, without forwarding, a user would have to sign each transactions on every chain and wait for the tokens to arrive at the destination before performing the next action. This is time consuming and a provides a poor user experience, a user also cannot just specify the desired outcome of their workflow in a trivial way. - - ## Objectives To enable end users to automatically and atomically unwind fungible tokens when they specify a destination chain, so that tokens arrive at the destination chain with only 1 hop in the path and to be able to forward the token to another destination after it has been unwound. - - ## Scope - - | Features | Release | | --------- | ------- | | Automatic and atomic path unwinding for fungible tokens suitable for end users initiating a transfer | v9.0.0 | @@ -66,11 +55,8 @@ For example, ETH from Ethereum flows into Osmosis via Axelar, where the final st A user on one chain, for example the Cosmos Hub holds an asset, e.g. ATOM and wants to instead have AKT on Akash. The user must transfer to ATOM to a DEX chain, swap the ATOM for AKT and then send the AKT onwards to Akash. - # Functional requirements - - ## Assumptions and dependencies 1. A functional relayer implementation is required for this feature @@ -80,9 +66,6 @@ A user on one chain, for example the Cosmos Hub holds an asset, e.g. ATOM and wa 5. The functionality to enable a specific action before forwarding is not in scope of these requirements 6. If a transfer contains multiple unique tokens, the unwinding functionality only needs to support a single denom, i.e. if there is a transfer containing a native token and 1 hop denom being sent from source to destination, unwinding should support unwinding the 1 hop denom and sending the native token directly to the destination. Support for transfer and unwind for native token and 2+ 1 hop denoms is not required. - - - ## Features | ID | Description | Verification | Status | @@ -95,14 +78,11 @@ A user on one chain, for example the Cosmos Hub holds an asset, e.g. ATOM and wa | 1.06 | The forwarding mechanism shall allow tokens to have some action performed on them before being sent onto a new destination | ------------ | draft | | 1.07 | The routing information for forwarding or to go from unwound token to destination must be input with the initial transfer | ------------ | draft | | 1.08 | If an intermediate chain does not have the unwinding or forwarding functionality, the tokens must be recoverable on the sending chain | ------------ | draft | - 1.09 | If unwinding or forwarding fails, then the reason for the failure should be returned in an error | ------------ | draft | - | 1.10| When unwinding, it should be possible for the unwind route to the tokens origin to be introspected from the denomination trace | ------------ | draft | - + | 1.09 | If unwinding or forwarding fails, then the reason for the failure should be returned in an error | ------------ | draft | + | 1.10| When unwinding, it should be possible for the unwind route to the tokens origin to be introspected from the denomination trace | ------------ | draft | # External interface requirements - - | ID | Description | Verification | Status | | -- | ----------- | ------------ | ------ | | 2.01 | There must be a CLI interface to initiate a transfer using path unwinding | ------------ | draft | @@ -111,11 +91,8 @@ A user on one chain, for example the Cosmos Hub holds an asset, e.g. ATOM and wa # Non-functional requirements -### Security +## Security | ID | Description | Verification | Status | | -- | ----------- | ------------ | ------ | -| 3.01 | It must not be possible for a users tokens to be intercepted by another actor during path-unwinding or token forwarding | ------------ | draft | - - - \ No newline at end of file +| 3.01 | It must not be possible for a users tokens to be intercepted by another actor during path-unwinding or token forwarding | ------------ | draft | \ No newline at end of file