[draft] MIP-85: Lock/Mint bridge high-level description + MD-85: Bridge Architecture Requirements

.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

MD/md-85/README.md

@@ -0,0 +1,38 @@
+# MD-85: Bridge Architecture Requirements
+
+- **Description**: Elicit the requirements of the native bridge.
+- **Authors**: [Franck Cassez](mailto:[email protected])
+
+## Overview
+
+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**:
+
+### 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

MIP/mip-85/README.md

@@ -0,0 +1,106 @@
+# MIP-85: Lock/Mint bridge high-level description
+
+- **Description**: Provides a high-level description of the native lock/mint bridge.
+- **Authors**: [Frabck Cassez](mailto:[email protected])
+- **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).