Workflow

.github/workflows/pre-commit.yml

@@ -4,21 +4,21 @@ on:
     pull_request:
     push:
         branches: [main]
-
 jobs:
     pre-commit:
         runs-on: ubuntu-latest
         steps:
-            - uses: actions/checkout@v3
-            - uses: actions/setup-python@v3
-            - uses: actions/setup-node@v3
+            - uses: actions/checkout@v4
+            - uses: actions/setup-python@v5
+              with:
+                  python-version: "3.14"
+            - uses: actions/setup-node@v4
               with:
                   node-version: ">=18.0"
-
             - name: Install dependencies
               run: npm install
-
             - uses: pre-commit/action@v3.0.0
-
             - name: Run eslint and prettier linting checks
-              run: npm run lint
+              run: |
+                  npm cache clean --force
+                  npm run lint

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.
 
 :::
 

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
 

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
 

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
 

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]
 

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.

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.

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]
 
 :::
 

docs/intro.md

@@ -22,7 +22,7 @@ will expand to report on diverse types of other real-world facts as oracle use
 cases, and their importance beyond blockchain domains, becomes more important to
 society at large.
 
-[oracle-1]: oracle-basics#what-is-a-blockchain-oracle
+[oracle-1]: http://example.com
 [cardano-1]: https://medium.com/coinmonks/why-cardano-in-2023-b481846028bc
 [smart-1]: oracle-basics#what-is-a-smart-contract
 
@@ -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

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
 
 :::
 

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]
 

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

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: