Update ADR status (#1637)

These should reflect the current state of affairs on the hydra-node
implementation.

docs/adr/2022-03-17_015-admin-api.md

@@ -3,12 +3,12 @@ slug: 15
 title: | 
   15. Configuration Through an Admin API
 authors: []
-tags: [Draft]
+tags: [Proposed]
 ---
 
 ## Status
 
-Draft
+Proposed
 
 ## Context
 

docs/adr/2022-03-28_017-udp-networking.md

@@ -3,12 +3,12 @@ slug: 17
 title: |
   17. Use UDP protocol for Hydra networking
 authors: []
-tags: [Draft]
+tags: [Proposed]
 ---
 
 ## Status
 
-Draft
+Proposed
 
 ## Context
 

docs/adr/2022-07-22_019-reference-scripts.md

@@ -3,12 +3,12 @@ slug: 19
 title: | 
   19. Use of reference scripts
 authors: []
-tags: [Proposed]
+tags: [Accepted]
 ---
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

docs/adr/2022-12-05_021-Bounded-transaction-validity-on-Hydra-protocol-transactions.md

@@ -8,7 +8,7 @@ tags: [Accepted]
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context
 

docs/adr/2022-12-06_022-model-based-testing.md

@@ -32,7 +32,7 @@ Accepted
 - We need to ensure the Model covers the full lifecycle of a Hydra Head network which at the time of writing this ADR is not the case
 - There cannot be _One Model to Rule Them All_ so we should refrain from defining different `StateModel` or different `RunModel` depending on what needs to be tested
 - In particular, testing against adversarial conditions will certainly require defining different instances of the `Network` or `Chain` components, for example:
-  - An _Active Adversary_ that fully the controls the protocol and the parties,
+  - An _Accepted Adversary_ that fully the controls the protocol and the parties,
   - A _Network Adversary_ that can delay and or drop messages,
   - A _Faulty Filesystem_ that can causes exceptions when reading or writing files,
   - ...

docs/adr/2023-08-18_025-resource-based-api.md

@@ -3,12 +3,12 @@ slug: 25
 title: |
   25. Event-sourced, resource-based API
 authors: []
-tags: [Draft]
+tags: [Proposed]
 ---
 
 ## Status
 
-Draft
+Proposed
 
 ## Context
 

docs/adr/2023-09-08_026-stateless-observation-construction.md

@@ -1,14 +1,14 @@
 ---
 slug: 26
 title: |
-  26. Stateless transaction observaion & construction
-authors: []
-tags: [Draft]
+  26. Stateless transaction observation & construction
+authors: [ch1bo]
+tags: [Proposed]
 ---
 
 ## Status
 
-Draft
+Proposed
 
 ## Context
 

docs/adr/2023-09-09_027-network-resilience.md

@@ -3,12 +3,12 @@ slug: 27
 title: |
   27. Network failures model
 authors: [abailly, pgrange]
-tags: [Proposed]
+tags: [Accepted]
 ---
 
 ## Status
 
-Draft
+Accepted
 
 ## Context
 

docs/adr/2023-10-16_028_offline_adr.md

@@ -3,18 +3,23 @@ slug: 28
 title: |
   28. Offline mode
 authors: [cardenaso11]
-tags: []
+tags: [Accepted]
 ---
+
 ## Status
-Proposed
+
+Accepted
 
 ## Context
+
 Currently, the Hydra node requires a Layer 1 Cardano node running in order to operate; The L1 node is needed to submit and watch for L1 transactions. Generally speaking, the transactions watched are for learning the state of the Hydra node, as reflected by the L1 chain. The transactions submitted are to transition between states (e.g. after submitting a Commit tx to the L1, a node watches to see when all other nodes have also Committed.)
 
 There are applications for the Hydra node where interaction with an L1 chain is unnecessary. Offline mode will be a key component of the Gummiworm protocol, a Layer 2 protocol being built by Sundae Labs, which enables actors other than Hydra head participants to validate transactions that occur in the head.
 
 The Hydra node offline mode would remove the dependency on the L1 Cardano node, for applications like Gummiworm where it is unneeded. It would also remove the dependency on the L1 Cardano node for peer-to-peer Hydra node communication. This would be useful for other Layer 2s that build on top of Hydra instead of duplicating its efforts, and for anyone who wants to easily validate a set of Cardano transactions.
+
 ## Decision
+
 Hydra node will be executable in offline mode, as an alternative to the default online mode. When online, the Hydra node depends on querying a Cardano node for Era History information and Genesis parameters. When offline this is not necessary, because the Hydra node will not connect to any Layer 1 .
 
 The initial state of the head will be specified in a flag, which makes any Commit redundant. The flag will specify a file for the starting Layer 2 UTXO. The Hydra node can be configured to write the current UTXO into a file, including the starting UTXO file.
@@ -25,7 +30,6 @@ Commit endpoint will return 400 instead of building a transaction, in offline mo
 
 Support for peer Hydra nodes in offline mode is considered out of scope, as it doesn't seem immediately useful. A node running in offline mode will not be configurable with any peer nodes, nor will it make a network connection to any peer nodes.
 
-
 ## Consequences
 
 The Hydra node would be usable offline, for transaction validation, and other custom L2 applications. The lifecycle & state machine associated with a Hydra would remain unchanged in both online, and offline mode.

docs/adr/2023-12-06_029-use-cbor-for-tx.md → docs/adr/2023-12-06_030-use-cbor-for-tx.md

@@ -3,12 +3,12 @@ slug: 30
 title: |
   30. Use CBOR in external representation of Cardano transactions
 authors: [abailly]
-tags: [Proposed]
+tags: [Accepted]
 ---
 
 ## Status
 
-Proposed
+Accepted
 
 ## Context