From da6e8da0c68733e9616b915641821692511d2e33 Mon Sep 17 00:00:00 2001
From: franck44 <francksquash@gmail.com>
Date: Thu, 9 Jan 2025 13:46:22 +1100
Subject: [PATCH 1/6] First-cut MD. see #68

---
 MD/md-bridge-archi/README.md | 51 ++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 MD/md-bridge-archi/README.md

diff --git a/MD/md-bridge-archi/README.md b/MD/md-bridge-archi/README.md
new file mode 100644
index 00000000..5ae606a8
--- /dev/null
+++ b/MD/md-bridge-archi/README.md
@@ -0,0 +1,51 @@
+# MD-\<number\>: Bridge Architecture Requirements
+- **Description**: Elicit the requirements of the native bridge.
+- **Authors**: [Franck Cassez](mailto:franck.cassez@movementlabs.xyz)
+
+
+## Overview
+
+This MD summarises the requirements of the _Native Bridge_ (bridge in the sequel).
+
+## Desiderata
+
+
+### D1: High-level Description of the Native Bridge
+
+**Description**: A high-level diagram of the architecture
+
+**Justification**: Provides a reference for documentation and implementation.
+
+**Recommendations**: 
+
+### D2: List the expected functionalities of the bridge
+
+**Description**: A list of expected functionalities.
+
+**Justification**: Provides a reference for documentation and implementation.
+
+### D3: Elicit the trust assumptions and permissions
+
+**Description**: Provide a list of trusted systems/components and the associated permissions.
+
+**Justification**: Provides a reference for documentation and implementation and governance.
+
+
+### D4: Explain how the bridge transfers work
+
+**Description**: Provide sequence diagrams to explain how bridging from Move to Ethereum (and back) works.
+
+**Justification**: Explain the sequence of actions required on the chains and their ordering, to complete a bridge transfer.
+
+## Change Logs
+<!--
+  Errata should be maintained after publication.
+
+  1. **Transparency and Clarity**: An erratum acknowledges any corrections made post-publication, ensuring that readers are not misled and are always equipped with the most accurate information.
+
+  2. **Accountability**: By noting errors openly, we maintain a high level of responsibility and ownership over our content. It’s an affirmation that we value precision and are ready to correct oversights.
+
+  Each erratum should briefly describe the discrepancy and the correction made, accompanied by a reference to the date and version of the desiderata in which the error was identified.
+
+  TODO: Maintain this comment.
+-->
\ No newline at end of file

From 60b1345998b0dda372248779b7e5e33ae8d4098d Mon Sep 17 00:00:00 2001
From: franck44 <francksquash@gmail.com>
Date: Thu, 9 Jan 2025 13:50:54 +1100
Subject: [PATCH 2/6] First-cut MIP brideg architecture. see  #68

---
 MIP/mip-bridge-archi/README.md | 105 +++++++++++++++++++++++++++++++++
 1 file changed, 105 insertions(+)
 create mode 100644 MIP/mip-bridge-archi/README.md

diff --git a/MIP/mip-bridge-archi/README.md b/MIP/mip-bridge-archi/README.md
new file mode 100644
index 00000000..1ddfc6c5
--- /dev/null
+++ b/MIP/mip-bridge-archi/README.md
@@ -0,0 +1,105 @@
+# MIP-\<number\>: Lock/Mint bridge high-level description.
+- **Description**: Provides a high-level description of the native lock/mint bridge.
+- **Authors**: [Frabck Cassez](mailto:franck.cassez@movementlabs.xyzm)
+- **Desiderata**: [MIP-\<number\>](../MIP/mip-\<number\>)
+
+<!--
+  READ MIP-1 BEFORE USING THIS TEMPLATE!
+
+  This is the suggested template for new MIPs. After you have filled in the requisite fields, please delete these comments.
+
+  Note that an MIP number will be assigned by an editor. When opening a pull request to submit your MIP, please use an abbreviated title in the filename, `mip-draft_title_abbrev.md`.
+
+  The title should be 44 characters or less. It should not repeat the MIP number in title, irrespective of the category.
+
+  The author should add himself as a code owner in the `.github/CODEOWNERS` file for the MIP.
+
+  TODO: Remove this comment before finalizing.
+-->
+
+## Abstract
+
+This MIP provides a high-level description of the architecture of the native bridge, its components and inner workings.
+
+## Motivation
+
+This MIP is associated with [MD-xx](../../MD/md-bridge-archi/README.md).
+
+## Specification
+
+<!--
+  The Specification section should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations.
+
+  It is recommended to follow RFC 2119 and RFC 8170. Do not remove the key word definitions if RFC 2119 and RFC 8170 are followed.
+
+  TODO: Remove this comment before finalizing
+-->
+
+> [!NOTE] 
+> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+
+## Reference Implementation
+
+<!--
+  The Reference Implementation section should include links to and an overview of a minimal implementation that assists in understanding or implementing this specification. The reference implementation is not a replacement for the Specification section, and the proposal should still be understandable without it.
+
+  TODO: Remove this comment before submitting
+-->
+
+## Verification
+
+<!--
+
+  All proposals must contain a section that discusses the various aspects of verification pertinent to the introduced changes. This section should address:
+
+  1. **Correctness**: Ensure that the proposed changes behave as expected in all scenarios. Highlight any tests, simulations, or proofs done to validate the correctness of the changes.
+
+  2. **Security Implications**: Address the potential security ramifications of the proposal. This includes discussing security-relevant design decisions, potential vulnerabilities, important discussions, implementation-specific guidance, and pitfalls. Mention any threats, risks, and mitigation strategies associated with the proposal.
+
+  3. **Performance Impacts**: Outline any performance tests conducted and the impact of the proposal on system performance. This could be in terms of speed, resource consumption, or other relevant metrics.
+
+  4. **Validation Procedures**: Describe any procedures, tools, or methodologies used to validate the proposal against its requirements or objectives. 
+
+  5. **Peer Review and Community Feedback**: Highlight any feedback from peer reviews or the community that played a crucial role in refining the verification process or the proposal itself.
+
+
+  TODO: Remove this comment before submitting
+-->
+
+Needs discussion.
+
+---
+
+## Errata
+<!--
+  Errata should be maintained after publication.
+
+  1. **Transparency and Clarity**: An erratum acknowledges any corrections made post-publication, ensuring that readers are not misled and are always equipped with the most accurate information.
+
+  2. **Accountability**: By noting errors openly, we maintain a high level of responsibility and ownership over our content. It’s an affirmation that we value precision and are ready to correct oversights.
+
+  Each erratum should briefly describe the discrepancy and the correction made, accompanied by a reference to the date and version of the proposal in which the error was identified.
+
+  TODO: Maintain this comment.
+-->
+
+---
+
+## Appendix
+<!--
+  The Appendix should contain an enumerated list of reference materials and notes.
+
+  When referenced elsewhere each appendix should be called out with [A<number>](#A<number>) and should have a matching header.
+
+  TODO: Remove this comment before finalizing.
+
+-->
+
+### A1
+Nothing important here.
+
+---
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).
\ No newline at end of file

From dbc6a67f82b3222f82a32879c97f5822a45f450d Mon Sep 17 00:00:00 2001
From: franck44 <francksquash@gmail.com>
Date: Thu, 9 Jan 2025 13:53:55 +1100
Subject: [PATCH 3/6] Assign id to MD (PR #85). see #68.

---
 MD/{md-bridge-archi => md-85}/README.md | 2 +-
 MIP/mip-bridge-archi/README.md          | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename MD/{md-bridge-archi => md-85}/README.md (97%)

diff --git a/MD/md-bridge-archi/README.md b/MD/md-85/README.md
similarity index 97%
rename from MD/md-bridge-archi/README.md
rename to MD/md-85/README.md
index 5ae606a8..e23a5eda 100644
--- a/MD/md-bridge-archi/README.md
+++ b/MD/md-85/README.md
@@ -1,4 +1,4 @@
-# MD-\<number\>: Bridge Architecture Requirements
+# MD-85: Bridge Architecture Requirements
 - **Description**: Elicit the requirements of the native bridge.
 - **Authors**: [Franck Cassez](mailto:franck.cassez@movementlabs.xyz)
 
diff --git a/MIP/mip-bridge-archi/README.md b/MIP/mip-bridge-archi/README.md
index 1ddfc6c5..387f4792 100644
--- a/MIP/mip-bridge-archi/README.md
+++ b/MIP/mip-bridge-archi/README.md
@@ -23,7 +23,7 @@ This MIP provides a high-level description of the architecture of the native bri
 
 ## Motivation
 
-This MIP is associated with [MD-xx](../../MD/md-bridge-archi/README.md).
+This MIP is associated with [MD-85](../../MD/md-85/README.md).
 
 ## Specification
 

From e771deeff20ad2ad1488a0e5729485075754409b Mon Sep 17 00:00:00 2001
From: apenzk <dr.andreas.penzkofer@gmail.com>
Date: Mon, 13 Jan 2025 09:48:52 +0100
Subject: [PATCH 4/6] apply mip number

---
 .github/CODEOWNERS                         |  2 ++
 MD/md-85/README.md                         | 19 +++----------------
 MIP/{mip-bridge-archi => mip-85}/README.md |  7 ++++---
 3 files changed, 9 insertions(+), 19 deletions(-)
 rename MIP/{mip-bridge-archi => mip-85}/README.md (97%)

diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 86530438..de0a89e5 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -12,3 +12,5 @@
 /MD/md-15/ @l-monninger @apenzk
 /MIP/mip-39/ @franck44
 /MIP/mip-53/ @l-monninger
+/MD/md-85/ @franck44
+/MIP/mip-85/ @franck44
diff --git a/MD/md-85/README.md b/MD/md-85/README.md
index e23a5eda..d8b97698 100644
--- a/MD/md-85/README.md
+++ b/MD/md-85/README.md
@@ -1,22 +1,21 @@
 # MD-85: Bridge Architecture Requirements
+
 - **Description**: Elicit the requirements of the native bridge.
 - **Authors**: [Franck Cassez](mailto:franck.cassez@movementlabs.xyz)
 
-
 ## Overview
 
-This MD summarises the requirements of the _Native Bridge_ (bridge in the sequel).
+This MD summarizes the requirements of the _Native Bridge_ (bridge in the sequel).
 
 ## Desiderata
 
-
 ### D1: High-level Description of the Native Bridge
 
 **Description**: A high-level diagram of the architecture
 
 **Justification**: Provides a reference for documentation and implementation.
 
-**Recommendations**: 
+**Recommendations**:
 
 ### D2: List the expected functionalities of the bridge
 
@@ -30,7 +29,6 @@ This MD summarises the requirements of the _Native Bridge_ (bridge in the sequel
 
 **Justification**: Provides a reference for documentation and implementation and governance.
 
-
 ### D4: Explain how the bridge transfers work
 
 **Description**: Provide sequence diagrams to explain how bridging from Move to Ethereum (and back) works.
@@ -38,14 +36,3 @@ This MD summarises the requirements of the _Native Bridge_ (bridge in the sequel
 **Justification**: Explain the sequence of actions required on the chains and their ordering, to complete a bridge transfer.
 
 ## Change Logs
-<!--
-  Errata should be maintained after publication.
-
-  1. **Transparency and Clarity**: An erratum acknowledges any corrections made post-publication, ensuring that readers are not misled and are always equipped with the most accurate information.
-
-  2. **Accountability**: By noting errors openly, we maintain a high level of responsibility and ownership over our content. It’s an affirmation that we value precision and are ready to correct oversights.
-
-  Each erratum should briefly describe the discrepancy and the correction made, accompanied by a reference to the date and version of the desiderata in which the error was identified.
-
-  TODO: Maintain this comment.
--->
\ No newline at end of file
diff --git a/MIP/mip-bridge-archi/README.md b/MIP/mip-85/README.md
similarity index 97%
rename from MIP/mip-bridge-archi/README.md
rename to MIP/mip-85/README.md
index 387f4792..bc561fa2 100644
--- a/MIP/mip-bridge-archi/README.md
+++ b/MIP/mip-85/README.md
@@ -1,7 +1,8 @@
-# MIP-\<number\>: Lock/Mint bridge high-level description.
+# MIP-85: Lock/Mint bridge high-level description
+
 - **Description**: Provides a high-level description of the native lock/mint bridge.
 - **Authors**: [Frabck Cassez](mailto:franck.cassez@movementlabs.xyzm)
-- **Desiderata**: [MIP-\<number\>](../MIP/mip-\<number\>)
+- **Desiderata**: [MD-85](../../MD/md-85)
 
 <!--
   READ MIP-1 BEFORE USING THIS TEMPLATE!
@@ -35,7 +36,7 @@ This MIP is associated with [MD-85](../../MD/md-85/README.md).
   TODO: Remove this comment before finalizing
 -->
 
-> [!NOTE] 
+> [!NOTE]
 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
 
 

From 8e5048c2891e9b6f099db833b90d973ca4628dcd Mon Sep 17 00:00:00 2001
From: apenzk <dr.andreas.penzkofer@gmail.com>
Date: Tue, 25 Mar 2025 12:43:26 +0100
Subject: [PATCH 5/6] remove mip-85

---
 .github/CODEOWNERS   |   1 -
 MIP/mip-85/README.md | 106 -------------------------------------------
 2 files changed, 107 deletions(-)
 delete mode 100644 MIP/mip-85/README.md

diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 179259e7..3479022a 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -24,7 +24,6 @@
 /MIP/mip-61/ @apenzk @musitdev
 /MIP/mip-60/ @franck44 @apenzk
 /MIP/mip-84/ @apenzk
-/MIP/mip-85/ @franck44
 /MIP/mip-88/ @apenzk @Primata
 /MIP/mip-91/ @apenzk
 /MIP/mip-94/ @andygolay
diff --git a/MIP/mip-85/README.md b/MIP/mip-85/README.md
deleted file mode 100644
index bc561fa2..00000000
--- a/MIP/mip-85/README.md
+++ /dev/null
@@ -1,106 +0,0 @@
-# MIP-85: Lock/Mint bridge high-level description
-
-- **Description**: Provides a high-level description of the native lock/mint bridge.
-- **Authors**: [Frabck Cassez](mailto:franck.cassez@movementlabs.xyzm)
-- **Desiderata**: [MD-85](../../MD/md-85)
-
-<!--
-  READ MIP-1 BEFORE USING THIS TEMPLATE!
-
-  This is the suggested template for new MIPs. After you have filled in the requisite fields, please delete these comments.
-
-  Note that an MIP number will be assigned by an editor. When opening a pull request to submit your MIP, please use an abbreviated title in the filename, `mip-draft_title_abbrev.md`.
-
-  The title should be 44 characters or less. It should not repeat the MIP number in title, irrespective of the category.
-
-  The author should add himself as a code owner in the `.github/CODEOWNERS` file for the MIP.
-
-  TODO: Remove this comment before finalizing.
--->
-
-## Abstract
-
-This MIP provides a high-level description of the architecture of the native bridge, its components and inner workings.
-
-## Motivation
-
-This MIP is associated with [MD-85](../../MD/md-85/README.md).
-
-## Specification
-
-<!--
-  The Specification section should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations.
-
-  It is recommended to follow RFC 2119 and RFC 8170. Do not remove the key word definitions if RFC 2119 and RFC 8170 are followed.
-
-  TODO: Remove this comment before finalizing
--->
-
-> [!NOTE]
-> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
-
-
-## Reference Implementation
-
-<!--
-  The Reference Implementation section should include links to and an overview of a minimal implementation that assists in understanding or implementing this specification. The reference implementation is not a replacement for the Specification section, and the proposal should still be understandable without it.
-
-  TODO: Remove this comment before submitting
--->
-
-## Verification
-
-<!--
-
-  All proposals must contain a section that discusses the various aspects of verification pertinent to the introduced changes. This section should address:
-
-  1. **Correctness**: Ensure that the proposed changes behave as expected in all scenarios. Highlight any tests, simulations, or proofs done to validate the correctness of the changes.
-
-  2. **Security Implications**: Address the potential security ramifications of the proposal. This includes discussing security-relevant design decisions, potential vulnerabilities, important discussions, implementation-specific guidance, and pitfalls. Mention any threats, risks, and mitigation strategies associated with the proposal.
-
-  3. **Performance Impacts**: Outline any performance tests conducted and the impact of the proposal on system performance. This could be in terms of speed, resource consumption, or other relevant metrics.
-
-  4. **Validation Procedures**: Describe any procedures, tools, or methodologies used to validate the proposal against its requirements or objectives. 
-
-  5. **Peer Review and Community Feedback**: Highlight any feedback from peer reviews or the community that played a crucial role in refining the verification process or the proposal itself.
-
-
-  TODO: Remove this comment before submitting
--->
-
-Needs discussion.
-
----
-
-## Errata
-<!--
-  Errata should be maintained after publication.
-
-  1. **Transparency and Clarity**: An erratum acknowledges any corrections made post-publication, ensuring that readers are not misled and are always equipped with the most accurate information.
-
-  2. **Accountability**: By noting errors openly, we maintain a high level of responsibility and ownership over our content. It’s an affirmation that we value precision and are ready to correct oversights.
-
-  Each erratum should briefly describe the discrepancy and the correction made, accompanied by a reference to the date and version of the proposal in which the error was identified.
-
-  TODO: Maintain this comment.
--->
-
----
-
-## Appendix
-<!--
-  The Appendix should contain an enumerated list of reference materials and notes.
-
-  When referenced elsewhere each appendix should be called out with [A<number>](#A<number>) and should have a matching header.
-
-  TODO: Remove this comment before finalizing.
-
--->
-
-### A1
-Nothing important here.
-
----
-## Copyright
-
-Copyright and related rights waived via [CC0](../LICENSE.md).
\ No newline at end of file

From 84a9c16ea3fc2695f1b5247b056dfec586ffaa37 Mon Sep 17 00:00:00 2001
From: apenzk <dr.andreas.penzkofer@gmail.com>
Date: Tue, 25 Mar 2025 12:46:18 +0100
Subject: [PATCH 6/6] edit

---
 MD/md-85/README.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/MD/md-85/README.md b/MD/md-85/README.md
index d8b97698..6e43b6f9 100644
--- a/MD/md-85/README.md
+++ b/MD/md-85/README.md
@@ -15,8 +15,6 @@ This MD summarizes the requirements of the _Native Bridge_ (bridge in the sequel
 
 **Justification**: Provides a reference for documentation and implementation.
 
-**Recommendations**:
-
 ### D2: List the expected functionalities of the bridge
 
 **Description**: A list of expected functionalities.