Apply pre-commit fixes

ross-spencer · ross-spencer · commit e435bd367026 · 2026-01-08T19:21:12.000+01:00
diff --git a/docs/FAQ/faq-1.mdx b/docs/FAQ/faq-1.mdx
@@ -64,14 +64,14 @@ blockchain transaction are irreversible by their very design.
 
 :::note[Example:]
 
-- A change in the Bitcoin to ADA price may trigger a limit order in a DeFi smart
-  contract.
-- The final score in a sports event may trigger a payout in a betting dApp smart
-  contract.
-- An extreme weather event may trigger a payout for a crop insurance smart
-  contract.
-- The words spoken in a political speech and authenticated via blockchain
-  notarization may trigger policy changes.
+-   A change in the Bitcoin to ADA price may trigger a limit order in a DeFi
+    smart contract.
+-   The final score in a sports event may trigger a payout in a betting dApp
+    smart contract.
+-   An extreme weather event may trigger a payout for a crop insurance smart
+    contract.
+-   The words spoken in a political speech and authenticated via blockchain
+    notarization may trigger policy changes.
 
 :::
 
diff --git a/docs/developer-manual/archived-docs.md b/docs/developer-manual/archived-docs.md
@@ -73,11 +73,11 @@ those sent by others to the same address.
 Users were required to use the following information to identify the latest
 Facts published.
 
-- Minting policy ID.
-- Datum format, including:
-    - Most recent (`ValueReference -> PropertyValue[1] -> value)`, i.e. the
-      largest POSIX timestamp compared to other Fact Statement datum,
-    - Feed name, e.g. "ADA-USD".
+-   Minting policy ID.
+-   Datum format, including:
+    -   Most recent (`ValueReference -> PropertyValue[1] -> value)`, i.e. the
+        largest POSIX timestamp compared to other Fact Statement datum,
+    -   Feed name, e.g. "ADA-USD".
 
 :::note
 
diff --git a/docs/developer-manual/terms-of-service.md b/docs/developer-manual/terms-of-service.md
@@ -204,11 +204,10 @@ These Terms shall be governed by and construed in accordance with the laws of
 the British Virgin Islands, without regard to its conflict of law principles.
 Any dispute arising out of or relating to these Terms or the Services shall be
 resolved exclusively through binding arbitration in the British Virgin Islands
-under the rules of [e.g., the International Chamber of Commerce], and you waive
-any right to participate in class actions or representative proceedings.
-Judgment on the award may be entered in any court having jurisdiction." This
-channels disputes to a favorable, low-cost forum and waives class actions to
-limit mass claims.
+under the rules of [e.g., the International Chamber of Commerce], and you waive any
+right to participate in class actions or representative proceedings. Judgment on
+the award may be entered in any court having jurisdiction." This channels disputes
+to a favorable, low-cost forum and waives class actions to limit mass claims.
 
 ## Miscellaneous
 
diff --git a/docs/incentivized-testnet/itn-overview.md b/docs/incentivized-testnet/itn-overview.md
@@ -22,10 +22,10 @@ with Orcfax.
 The ITN will progress through four phases, each adding additional layers of
 validator node functionality; these phases, and their manuals, are listed below:
 
-- [Phase 1](phase-1-manual): Data collection for CEXes
-- [Phase 2](phase-2-manual): Incorporating DEX data
-- [Phase 3](phase-3-manual): Decentralized validator protocol
-- [Phase 4](phase-4-manual): Decentralized publication & Mainnet soft launch
+-   [Phase 1](phase-1-manual): Data collection for CEXes
+-   [Phase 2](phase-2-manual): Incorporating DEX data
+-   [Phase 3](phase-3-manual): Decentralized validator protocol
+-   [Phase 4](phase-4-manual): Decentralized publication & Mainnet soft launch
 
 ## Joining the ITN
 
diff --git a/docs/incentivized-testnet/phase-1-manual.md b/docs/incentivized-testnet/phase-1-manual.md
@@ -26,8 +26,8 @@ During this phase of the ITN, the hardware requirements will be minimal to
 handle the tasks involved. Participants should expect to meet the following
 minimum requirements:
 
-- 2GB of RAM
-- A single CPU
+-   2GB of RAM
+-   A single CPU
 
 ### Logging issues
 
@@ -63,9 +63,9 @@ guide [here][alias-1].
 There are three components needed for Phase 1 of the ITN. You will need the
 latest versions of each.
 
-- [collector-node][collector-1]
-- [cex collector (gofer)][collector-2]
-- [cer-feeds.json][collector-3]
+-   [collector-node][collector-1]
+-   [cex collector (gofer)][collector-2]
+-   [cer-feeds.json][collector-3]
 
 :::info[KEEPING UP TO DATE]
 
diff --git a/docs/incentivized-testnet/phase-1-period-8.md b/docs/incentivized-testnet/phase-1-period-8.md
@@ -17,8 +17,8 @@ cex collector software and the feed runner file. Details are provided below.
 
 Period 8 requires the upgrade of two components:
 
-- gofer (cex collector).
-- cer-feeds.json (collector runner).
+-   gofer (cex collector).
+-   cer-feeds.json (collector runner).
 
 ITN participants will need to upgrade these components so as to collect enough
 information to be able to claim rewards.
diff --git a/docs/incentivized-testnet/phase-2-manual.md b/docs/incentivized-testnet/phase-2-manual.md
@@ -22,9 +22,9 @@ publisher.
 During this phase of the ITN, participants should expect to meet the following
 minimum requirements\*:
 
-- 32 GB RAM
-- 8 CPU
-- 600 GB disk
+-   32 GB RAM
+-   8 CPU
+-   600 GB disk
 
 \* Specs are based on the minimal viable digital ocean servers operated by
 Orcfax.
diff --git a/docs/incentivized-testnet/signing-key-aliasing.md b/docs/incentivized-testnet/signing-key-aliasing.md
@@ -87,10 +87,10 @@ cardano-cli address key-hash \
 
 At this point, you should have the following files in your working directory:
 
-- `payment.addr`
-- `payment.skey`
-- `payment.vkey`
-- `payment.hash`
+-   `payment.addr`
+-   `payment.skey`
+-   `payment.vkey`
+-   `payment.hash`
 
 :::
 
@@ -124,9 +124,9 @@ The transaction **must** be constructed as follows:
 The metadata label must be `"674"` and must have the following 3 fields in
 order:
 
-- `"REGISTER"`
-- `"ITN"`
-- `"<YOUR_PAYMENT_HASH>"`
+-   `"REGISTER"`
+-   `"ITN"`
+-   `"<YOUR_PAYMENT_HASH>"`
 
 :::info[N.B.]
 
@@ -136,9 +136,9 @@ Cardano metadata character limit (max-length: 64 bytes).
 For more information, refer to the following Cardano transaction metadata
 specifications:
 
-- [CIP-20][md-1]
-- [Schema][md-2]
-- [JSON Conversion][md-3]
+-   [CIP-20][md-1]
+-   [Schema][md-2]
+-   [JSON Conversion][md-3]
 
 :::
 
diff --git a/docs/intro.md b/docs/intro.md
@@ -51,9 +51,9 @@ have about Orcfax or oracles in general.
 
 ## Stay updated
 
-- Follow our [Medium][med-1] for project and community updates
-- Subscribe to our [RSS Feed][rss-1] for important network status alerts
-- Join our [Discord][Discord-1] to engage directly with the team and community
+-   Follow our [Medium][med-1] for project and community updates
+-   Subscribe to our [RSS Feed][rss-1] for important network status alerts
+-   Join our [Discord][Discord-1] to engage directly with the team and community
 
 [med-1]: https://medium.com/@orcfax
 [Discord-1]: https://dsc.gg/orcfax
diff --git a/docs/orcfax-feeds/feed-overview.md b/docs/orcfax-feeds/feed-overview.md
@@ -29,9 +29,9 @@ For a feed of type CER, the naming convention is
 
 :::note[Examples:]
 
-- crypto-fiat: ADA-USD
-- crypto-stable: ADA-iUSD
-- crypto and another native asset: FACT-ADA
+-   crypto-fiat: ADA-USD
+-   crypto-stable: ADA-iUSD
+-   crypto and another native asset: FACT-ADA
 
 :::
 
diff --git a/docs/project-catalyst/f12-audit.md b/docs/project-catalyst/f12-audit.md
@@ -51,8 +51,8 @@ successfully signed a contract for services in August of 2024.
 
 <!-- markdownlint-enable MD013 -->
 
-- Announcement on [X][m1-2]
-- Announcement on [Discord][m1-3]
+-   Announcement on [X][m1-2]
+-   Announcement on [Discord][m1-3]
 
 ![Discord announcement](/img/2024-08-27--audit-txpipe-announcement.png)
 
@@ -75,8 +75,8 @@ successfully signed a contract for services in September of 2024.
 
 <!-- markdownlint-enable MD013 -->
 
-- Announcement on [X][m1-5]
-- Announcement on [Discord][m1-6]
+-   Announcement on [X][m1-5]
+-   Announcement on [Discord][m1-6]
 
 ![Discord announcement](/img/2024-09-30--audit-blink-announcement.png)
 
@@ -182,27 +182,28 @@ The findings can be simplified as follows:
 **ORC-301**: When using a chain indexer, if an integrator filters on address,
 they may miss utxos that have different stake credentials.
 
-- This is correct. However, integrators can just as easily filter on the payment
-  credential, which is the preferred method as this ensures the use of a valid
-  FS as publication is permissionless.
+-   This is correct. However, integrators can just as easily filter on the
+    payment credential, which is the preferred method as this ensures the use of
+    a valid FS as publication is permissionless.
 
 **ORC-302**: The frequent use of acronyms in the documentation added some
 difficulty in navigation as readers may need to reference explanations
 elsewhere.
 
-- Readers are expected to take care when reviewing technical documentation.
-  Additionally, the use of acronyms is advantageous in code.
+-   Readers are expected to take care when reviewing technical documentation.
+    Additionally, the use of acronyms is advantageous in code.
 
 **ORC-303**: The auditor questioned the need for the FSP to be included within
 its current repository, and therefore its inclusion within the scope of the
 audit.
 
-- While the suggestion is not without merit, we disagree as the FSP is an
-  integral part of the current design. Ultimately, the FSP is quite simplistic;
-  t is underpinned by a single key and is thereby entirely controlled by a
-  single entity. As Orcfax continues to decentralize its processes, we hope that
-  this component will be subsumed by a decentralized model, where the FSP and
-  other components are controlled by the network not single entity.
+-   While the suggestion is not without merit, we disagree as the FSP is an
+    integral part of the current design. Ultimately, the FSP is quite
+    simplistic; t is underpinned by a single key and is thereby entirely
+    controlled by a single entity. As Orcfax continues to decentralize its
+    processes, we hope that this component will be subsumed by a decentralized
+    model, where the FSP and other components are controlled by the network not
+    single entity.
 
 **ORC-304**: A potential inefficiency was found in the FS UTxO spending; in a
 collect transaction, for each UTxO being spent, the inputs list is traversed to
@@ -212,11 +213,11 @@ redeemer and verify its correctness against the script hash from the Mint
 purpose. this way, during FS UTxO spending, the datum field can be read instead
 of traversing the inputs list.
 
-- Our team was interested in this proposal. However, without additional testing
-  it'sa difficult to know whether the proposal would result in a decrease to the
-  cost of collect but at the cost of increasing the tx size of publish (and so
-  decrease max number of outputs). Unfortunately, the scope of TxPipe's work did
-  not include tests of this type.
+-   Our team was interested in this proposal. However, without additional
+    testing it'sa difficult to know whether the proposal would result in a
+    decrease to the cost of collect but at the cost of increasing the tx size of
+    publish (and so decrease max number of outputs). Unfortunately, the scope of
+    TxPipe's work did not include tests of this type.
 
 :::info["INFO" as defined by TxPipe]
 
diff --git a/docs/project-catalyst/f12-consensus.md b/docs/project-catalyst/f12-consensus.md
@@ -37,9 +37,9 @@ Orcfax conducted limited research which investigates a sample set of consensus
 protocols. This research was executed with a limited initial understanding of
 the consensus landscape, but covers topics such as:
 
-- what might be Orcfax requirements for staking?
-- what consensus resources exist for Cardano developers?
-- how do these resources map to Orcfax requirements?
+-   what might be Orcfax requirements for staking?
+-   what consensus resources exist for Cardano developers?
+-   how do these resources map to Orcfax requirements?
 
 This research and its findings are made available in _A Comparative Analysis of
 Consensus Protocols used in Blockchain Networks_ [(Wallis &
@@ -67,9 +67,9 @@ diagrams where appropriate.
 Orcfax will produce software code that demonstrates how a validator node
 operator can:
 
-- receive external source data
-- apply validation logic
-- compare results with other nodes in the L2 network
-- arrive at consensus on datum value
+-   receive external source data
+-   apply validation logic
+-   compare results with other nodes in the L2 network
+-   arrive at consensus on datum value
 
 ## Final Milestone
diff --git a/docs/project-catalyst/f12-economic-model.md b/docs/project-catalyst/f12-economic-model.md
@@ -105,8 +105,8 @@ Orcfax is an aspiring decentralized Oracle service. To participate within the
 network, a participant must be in possession of two types of Cardano native
 assets:
 
-- One Orcfax Validator License, one of 100 NFTs
-- At least 500,000 \$FACT
+-   One Orcfax Validator License, one of 100 NFTs
+-   At least 500,000 \$FACT
 
 Participants are strongly discouraged from behaving badly through the use of
 slashing. A participant must first put 'at stake' some asset(s). If the
@@ -119,10 +119,10 @@ their good service.
 However, when balancing incentives and penalties for participants, care must be
 taken. The wrong incentive structure may either:
 
-- cause a race to the top. Rewards only go to a few participants. Eventually
-  this leads to centralization which degrades robustness.
-- cause a race to the bottom. Participants are rewarded even if they are poor
-  service providers.
+-   cause a race to the top. Rewards only go to a few participants. Eventually
+    this leads to centralization which degrades robustness.
+-   cause a race to the bottom. Participants are rewarded even if they are poor
+    service providers.
 
 Both are bad for the long term health of the service.
 
@@ -323,8 +323,8 @@ $r$ from $n$. In the specific use case of Orcfax, $r$ represents the number of
 ways to choose 10 individuals from the 100 total nodes ($n$) without regard to
 order.
 
-- $n = 100$
-- $r = 10$
+-   $n = 100$
+-   $r = 10$
 
 This can be represented as:
 
diff --git a/docs/project-catalyst/f12-explorer.md b/docs/project-catalyst/f12-explorer.md
@@ -37,16 +37,16 @@ What follows is a mapping of <u>what was promised</u> for Milestone 1 to the
 <u>newly integrated explorer features</u>. Links will direct readers to
 additional context and the relevant code enhancements for each.
 
-- Orcfax feed price charts
-    - [Feeds list page][m1-1]
-    - [Feed details page][m1-2]
-    - [Feed price charts][m1-3]
-- State change timelines
-    - [Show calculation details on UI][m1-4]
-- Data provenance
-    - [Display sources][m1-5]
-    - [Show collection details on UI][m1-6]
-    - [Show validation details on UI][m1-7]
+-   Orcfax feed price charts
+    -   [Feeds list page][m1-1]
+    -   [Feed details page][m1-2]
+    -   [Feed price charts][m1-3]
+-   State change timelines
+    -   [Show calculation details on UI][m1-4]
+-   Data provenance
+    -   [Display sources][m1-5]
+    -   [Show collection details on UI][m1-6]
+    -   [Show validation details on UI][m1-7]
 
 These Orcfax Explorer upgrades give users an enhanced ability to verify the
 authenticity and provenance of the collected data. While this information has
@@ -103,12 +103,12 @@ it now displays information about Orcfax network activity in real time.
 
 The new feature set for the explorer brings the following changes:
 
-- The dashboard now has a section which dynamically displays statistics relating
-  to node participation
-    - Identifies when each node last published.
-    - Identifies the feed each node last published to.
-    - Identifies the total number of publications (i.e. Facts) for each node.
-    - Provides the status/health of each node.
+-   The dashboard now has a section which dynamically displays statistics
+    relating to node participation
+    -   Identifies when each node last published.
+    -   Identifies the feed each node last published to.
+    -   Identifies the total number of publications (i.e. Facts) for each node.
+    -   Provides the status/health of each node.
 
 The upgrades which enable this functionality are now included in the public
 github explorer [repo][m3-1] along with additional context.
@@ -132,12 +132,12 @@ reports during network events.
 
 The new feature set for the explorer brings the following changes:
 
-- Adds a [landing page to a Status Dashboard with key statistics][m4-1]
-- Adds [“Incidents” to Status Dashboard][m4-2]
-- Adds [“Network Updates” to Status Dashboard][m4-3]
-- Adds an [RSS Feed Url Builder to Status Dashboard][m4-4]
-    - Allows Orcfax to [Serve Orcfax RSS Feed from Status App][m4-5]
-- Provides an [index of Sources for the Orcfax RSS Feed][m4-6]
+-   Adds a [landing page to a Status Dashboard with key statistics][m4-1]
+-   Adds [“Incidents” to Status Dashboard][m4-2]
+-   Adds [“Network Updates” to Status Dashboard][m4-3]
+-   Adds an [RSS Feed Url Builder to Status Dashboard][m4-4]
+    -   Allows Orcfax to [Serve Orcfax RSS Feed from Status App][m4-5]
+-   Provides an [index of Sources for the Orcfax RSS Feed][m4-6]
 
 These new features are now included in the public github [explorer repo][m4-7]
 where we provide additional context and the relevant code enhancements for each.
diff --git a/docs/project-catalyst/f12-staking.md b/docs/project-catalyst/f12-staking.md
diff --git a/docs/project-catalyst/wallis-koch--2024--a-comparative-analysis-consensus.md b/docs/project-catalyst/wallis-koch--2024--a-comparative-analysis-consensus.md
diff --git a/docs/project-catalyst/wallis-koch--2024--a-comparative-analysis-staking.md b/docs/project-catalyst/wallis-koch--2024--a-comparative-analysis-staking.md
diff --git a/drafts/FAQ/faq-2.md b/drafts/FAQ/faq-2.md
diff --git a/editorialGuide.md b/editorialGuide.md
