From f29e32899206e90c57156cec7df9a8995fcf1fd3 Mon Sep 17 00:00:00 2001
From: Blas Rodriguez Irizar <rodrigblas@gmail.com>
Date: Mon, 13 Feb 2023 17:48:11 +0100
Subject: [PATCH] add content

---
 docs/requirements/ics10-requirements.md    | 38 ++++++++++++++--
 docs/requirements/requirements-template.md | 53 ++++++++++++++++++++++
 2 files changed, 87 insertions(+), 4 deletions(-)
 create mode 100644 docs/requirements/requirements-template.md

diff --git a/docs/requirements/ics10-requirements.md b/docs/requirements/ics10-requirements.md
index 6afd9961bf87..98b2baee8b23 100644
--- a/docs/requirements/ics10-requirements.md
+++ b/docs/requirements/ics10-requirements.md
@@ -6,22 +6,47 @@
 
 <!-- Provide a high-level, short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to ecosystem goals or strategies. -->
 
+Using IBC as a mean of commuincating between chains and ecosystems has proven to be useful within Cosmos. There is then value in extending
+this feature into other ecosystems, bringing a battle tested protocol of trusted commuincation as an option to send assets and data.
+
+This is especially useful to protocols and companies whose business model is to improve cross-chain user interface, or to enable it when
+it's not. The main use case for this is bridging assets between chains. There are multiple protocols and companies currently performing such
+a service but none has yet been able to do it using IBC outside of the Cosmos ecosystem.
+
+A core piece for this to happen is to have a light client implementation of each ecosystem that has to be integrated, and uses a **new** consensus
+algorithm. 
+
+
 ## Problem
 
 <!-- This section describes the problem that needs to be solved or the process that needs to be improved, as well as the environment in which the system will be used. This section could include a comparative evaluation of existing products, indicating why the proposed product is attractive and the advantages it provides. Describe the problems that cannot currently be solved without the envisioned solution. Show how it aligns with ecosystem trends, technology evolution, or strategic directions. List any other technologies, processes, or resources required to provide a complete solution. -->
 
+In order to export IBC outside of Tendermint based ecosystems, there is a need to introduce new light clients. This is a core need for
+companies and protocols trying to bridge ecosystems such as Ethereum, NEAR, Polkadot, etc. as none of these uses Tendermint as their
+consensus mechanism.
+
+
 ## Objectives
 
 <!-- Summarize the important benefits the product will provide in a quantitative and measurable way. Platitudes (become recognized as a world-class <whatever>) and vaguely stated improvements (provide a more rewarding customer experience) are neither helpful nor verifiable. -->
 
+Bridging assets, is likely the simplest for of interchain communication. Its value is confirmed on a daily basis, when considering the volumes that protocols
+like [Axelar](https://dappradar.com/multichain/defi/axelar-network), Gravity, [Wormhole](https://dappradar.com/multichain/defi/wormhole/) and
+[Layer0](TODO: add source for volume?) process. TODO: add sources for volume
+
+
 ## Scope
 
 <!-- List the product's major features or capabilities. Think about how users will use the features, to ensure that the list is complete and that it does not include unnecessary features that sound interesting but don't provide value. Optionally, give each feature a unique and persistent label to permit tracing it to other system elements. List any product capabilities or characteristics that a stakeholder might expect but that are not planned for inclusion in the product or in a specific release. List items that were cut from scope, so the scope decision is not forgotten. -->
 
-<!-- Use a table like the following:
-| Features  | Release |
-| --------- | ------- |
--->
+| Features              |  Release |
+|---------------------- |----------|
+| Dispatch messages to a|  v.7.1   |
+| light client written  |          |
+| in wasm following the |          |
+| `ClientState`         |          |
+| interface             |          |
+
 
 # User requirements
 
@@ -33,10 +58,15 @@
 
 <!-- They should describe as completely as necessary the system's behaviors under various conditions. They describe what the engineers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements. Software engineers don't implement business requirements or user requirements. They implement functional requirements, specific bits of system behavior. Each requirement should be uniquely identified with a meaningful tag. -->
 
+The scope of this feature is to allow any implemention written in WASM to be feature complete with the `tendermint` light client implementation, and hence be compliant with
+the interface expressed in [02-client ClientState interface](../../modules/core/exported/client.go).
+
 ## Assumptions and dependencies
 
 <!-- List any assumed factors that could affect the requirements. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors. -->
 
+This feature expects the [02-client refactor completed](https://github.com/cosmos/ibc-go/milestone/16).
+
 ## Features
 
 <!-- Use a table like the following for the requirements:
diff --git a/docs/requirements/requirements-template.md b/docs/requirements/requirements-template.md
new file mode 100644
index 000000000000..6afd9961bf87
--- /dev/null
+++ b/docs/requirements/requirements-template.md
@@ -0,0 +1,53 @@
+<!-- More detailed information about the requirements engineering process can be found at https://github.com/cosmos/ibc-go/wiki/Requirements-engineering -->
+
+# Business requirements
+
+<!-- They describe why the organization is implementing the product or feature (the benefits the organization hopes to achieve). They provide a reference for making decisions about proposed requirement changes and enhancements (i.e. decide if a proposed requirement is in or out of scope). Business requirements directly influence which user or functional requirements to implement and in what sequence. -->
+
+<!-- Provide a high-level, short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to ecosystem goals or strategies. -->
+
+## Problem
+
+<!-- This section describes the problem that needs to be solved or the process that needs to be improved, as well as the environment in which the system will be used. This section could include a comparative evaluation of existing products, indicating why the proposed product is attractive and the advantages it provides. Describe the problems that cannot currently be solved without the envisioned solution. Show how it aligns with ecosystem trends, technology evolution, or strategic directions. List any other technologies, processes, or resources required to provide a complete solution. -->
+
+## Objectives
+
+<!-- Summarize the important benefits the product will provide in a quantitative and measurable way. Platitudes (become recognized as a world-class <whatever>) and vaguely stated improvements (provide a more rewarding customer experience) are neither helpful nor verifiable. -->
+
+## Scope
+
+<!-- List the product's major features or capabilities. Think about how users will use the features, to ensure that the list is complete and that it does not include unnecessary features that sound interesting but don't provide value. Optionally, give each feature a unique and persistent label to permit tracing it to other system elements. List any product capabilities or characteristics that a stakeholder might expect but that are not planned for inclusion in the product or in a specific release. List items that were cut from scope, so the scope decision is not forgotten. -->
+
+<!-- Use a table like the following:
+| Features  | Release |
+| --------- | ------- |
+-->
+
+# User requirements
+
+## Use cases
+
+<!-- A use case describes a sequence of interactions between a system and an external actor that results in the actor being able to achieve some outcome of value. An actor is a person (or sometimes another software system or a hardware device) that interacts with the system to perform a use case. Identify the various user classes that will use the feature. -->
+
+# Functional requirements
+
+<!-- They should describe as completely as necessary the system's behaviors under various conditions. They describe what the engineers must implement to enable users to accomplish their tasks (user requirements), thereby satisfying the business requirements. Software engineers don't implement business requirements or user requirements. They implement functional requirements, specific bits of system behavior. Each requirement should be uniquely identified with a meaningful tag. -->
+
+## Assumptions and dependencies
+
+<!-- List any assumed factors that could affect the requirements. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors. -->
+
+## Features
+
+<!-- Use a table like the following for the requirements:
+| ID | Description | Verification | Status | 
+| -- | ----------- | ------------ | ------ | 
+-->
+
+# External interface requirements
+
+<!-- They describe the interfaces to other software systems, hardware components, and users. Ideally they should state the purpose, format and content of messages used for input and output. -->
+
+# Non-functional requirements
+
+<!-- Other-than-functional requirements that do not specify what the system does, but rather how well it does those things. For example: quality requirements: performance, security, portability, etc. -->
\ No newline at end of file