diff --git a/.github/workflows/pre-commit.yml b/.github/workflows/pre-commit.yml index 2295eb5f..e18c54dd 100644 --- a/.github/workflows/pre-commit.yml +++ b/.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 diff --git a/docs/FAQ/faq-1.mdx b/docs/FAQ/faq-1.mdx index 5f8ed9cc..30d39fb6 100644 --- 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 index 30a07eee..01de91b3 100644 --- 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 index 30e5f2d3..a82dd13a 100644 --- 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 index a10555e7..ce587585 100644 --- 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 index 5c2c0c73..5cf9a425 100644 --- 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 index eb614707..ae2be96e 100644 --- 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 index 3d606e91..e27940fa 100644 --- 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 index a5b59716..b198166b 100644 --- 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"` -- `""` +- `"REGISTER"` +- `"ITN"` +- `""` :::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 index 15dc6bac..cb88b916 100644 --- a/docs/intro.md +++ b/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 diff --git a/docs/orcfax-feeds/feed-overview.md b/docs/orcfax-feeds/feed-overview.md index 6d7ac66e..ed5d4c96 100644 --- 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 index 737d049f..eeca1b88 100644 --- 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. -- 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. -- 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 index f491b2a0..ae6c9b4c 100644 --- 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 index 549caab3..0da2ee34 100644 --- 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 index 40f8a282..889d0c88 100644 --- a/docs/project-catalyst/f12-explorer.md +++ b/docs/project-catalyst/f12-explorer.md @@ -37,16 +37,16 @@ What follows is a mapping of what was promised for Milestone 1 to the newly integrated explorer features. 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 index f8c9bdaf..0bd78267 100644 --- a/docs/project-catalyst/f12-staking.md +++ b/docs/project-catalyst/f12-staking.md @@ -63,8 +63,8 @@ and diagrams where appropriate. Orcfax will produce software code that demonstrates how a validator node operator can: -- deposit testFACT stake -- receive testFACT rewards -- have testFACT slashed for non-conformant behaviour +- deposit testFACT stake +- receive testFACT rewards +- have testFACT slashed for non-conformant behaviour ## Final Milestone 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 index 8e24a8c2..883a1f13 100644 --- a/docs/project-catalyst/wallis-koch--2024--a-comparative-analysis-consensus.md +++ b/docs/project-catalyst/wallis-koch--2024--a-comparative-analysis-consensus.md @@ -89,13 +89,13 @@ Orcfax Validators will be expected to execute a number of tasks, many of which require consensus. A non-exhaustive list of the tasks that validators must do includes: -- running the existing data collectors and feeds -- ensuring maintenance of existing code base -- ensuring health of data sources / definitions of feeds -- sunsetting and discontinuing underused feeds -- defining and developing new feeds -- ensuring the health of the network (removing bad validators and collectors) -- maintaining optimal remuneration parameters +- running the existing data collectors and feeds +- ensuring maintenance of existing code base +- ensuring health of data sources / definitions of feeds +- sunsetting and discontinuing underused feeds +- defining and developing new feeds +- ensuring the health of the network (removing bad validators and collectors) +- maintaining optimal remuneration parameters In the present proposal we are mostly concerned with consensus as it is involved in the running of existing feeds. We hope that the underlying techniques can be @@ -165,10 +165,10 @@ how and over precisely what. The framing of the requirements is partly based on assumptions on the form of the output. -- The software is, or mimics, a service on a computer. -- Each participant is running an instance of the software. -- State must be communicated between participants. -- If relevant, assume participants can communicate via TCP or UDP based. +- The software is, or mimics, a service on a computer. +- Each participant is running an instance of the software. +- State must be communicated between participants. +- If relevant, assume participants can communicate via TCP or UDP based. Given these, Orcfax has identified the following as a preliminary list of Must Have requirements (parameters outlined below): @@ -187,10 +187,10 @@ Have requirements (parameters outlined below): Parameters: -- N = number of nodes in the network: 100 -- K = number of malicious or incompetent nodes: 30 -- T = time of delivery: 60s -- V = velocity of statements: 10 tps +- N = number of nodes in the network: 100 +- K = number of malicious or incompetent nodes: 30 +- T = time of delivery: 60s +- V = velocity of statements: 10 tps :::info[\*] @@ -652,15 +652,15 @@ requirements identified by Orcfax, none of the reviewed consensus protocols fully meets all of Orcfax's needs out-of-the-box. The most protocol that seems to best align with the requirements is Cosmos's CometBFT. In particular: -- Simplicity-(ish). Limiting the participants to 180 nodes allowed - Cosmos/CometBFT to be simpler, than some of the alternatives. EchoNet is - targeting only 100 nodes. -- Built as SDK. What for other solutions maybe considered "internal APIs", are - external for CometBFT. This means the code and the ideas behind the code are - much more accessible. -- Synergies. The development of the IBC by the Cardano Foundation provides a - hope that there will be other tooling that we can take advantage of and - contribute to. +- Simplicity-(ish). Limiting the participants to 180 nodes allowed + Cosmos/CometBFT to be simpler, than some of the alternatives. EchoNet is + targeting only 100 nodes. +- Built as SDK. What for other solutions maybe considered "internal APIs", are + external for CometBFT. This means the code and the ideas behind the code are + much more accessible. +- Synergies. The development of the IBC by the Cardano Foundation provides a + hope that there will be other tooling that we can take advantage of and + contribute to. ### 4.1 Limitations @@ -682,14 +682,14 @@ became clear. The most interesting lines of inquiry are with the CometBFT implementation of the Cosmos consensus protocol. -- CometBFT meets requirements on node count; it demonstrably handles at least - 180 nodes which is more than enough as EchoNet will accommodate 100 Validators - with licenses. -- Finality is faster than Ouroboros and exceeds our current understanding of - EchoNet requirements. -- The tooling lacks the significant complexity that would impair an Orcfax - implementation of another solution; this makes CometBFT a much more feasible - starting point given time constraints. +- CometBFT meets requirements on node count; it demonstrably handles at least + 180 nodes which is more than enough as EchoNet will accommodate 100 + Validators with licenses. +- Finality is faster than Ouroboros and exceeds our current understanding of + EchoNet requirements. +- The tooling lacks the significant complexity that would impair an Orcfax + implementation of another solution; this makes CometBFT a much more feasible + starting point given time constraints. An Orcfax implementation of a Cosmos consensus solution could make future Cardano-IBC tooling from the Cardano Foundation available and relevant to 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 index c700e3b0..8f630c1b 100644 --- a/docs/project-catalyst/wallis-koch--2024--a-comparative-analysis-staking.md +++ b/docs/project-catalyst/wallis-koch--2024--a-comparative-analysis-staking.md @@ -148,8 +148,8 @@ through its staking mechanism. In order for network operators to participate, Orcfax requires each to stake the following: -- Orcfax Validator License: One of 100 NFTs. -- Minimum stake: 500,000 FACT tokens. +- Orcfax Validator License: One of 100 NFTs. +- Minimum stake: 500,000 FACT tokens. ### 2.3 System components @@ -185,13 +185,13 @@ Orcfax has identified the following as staking protocol Must haves: In addition to this initial draft of system requirements, each staking mechanism assessed within this paper will be evaluated against Orcfax priorities for: -- Security: to what degree is it apparent that the design choices for each - staking mechanism impact the overall security of the network? -- Participation: to what degree does the staking mechanism provide opportunities - for equitable participation within the network? -- Decentralization: Given the previous two, to what degree do choices - influencing network security and participation have on the degree of - decentralization or any risks towards centralization of the network? +- Security: to what degree is it apparent that the design choices for each + staking mechanism impact the overall security of the network? +- Participation: to what degree does the staking mechanism provide + opportunities for equitable participation within the network? +- Decentralization: Given the previous two, to what degree do choices + influencing network security and participation have on the degree of + decentralization or any risks towards centralization of the network? ## 3. Overview of staking Protocols @@ -556,10 +556,10 @@ do not have the ability to delegate to validators for a share in rewards, as some of the other chains in this paper allow, participants have multiple methods by which they may operate validator nodes: -- as an independent (i.e. Home staking) -- by leveraging cloud compute (i.e. Staking as a Service) -- by pooling (which allows multiple holders to mutually participate) -- or by staking through a CEX (i.e. Centralized Exchange) +- as an independent (i.e. Home staking) +- by leveraging cloud compute (i.e. Staking as a Service) +- by pooling (which allows multiple holders to mutually participate) +- or by staking through a CEX (i.e. Centralized Exchange) [source][eth-1] @@ -678,14 +678,14 @@ choices affect key design goals will be crucial for network success. From the staking protocols reviewed, each exhibited unique strengths and weaknesses when measured against the Orcfax Staking Protocol Requirements. -- **Algorand and Avalanche** struggle with incentives and security, limiting - their appeal and robustness. -- **Bitcoin Lightning's** complexity and potential removal of penalties may - hinder user engagement. -- **Cardano and Cosmos** offer accessible models but vary in terms of risk, - particularly regarding slashing. -- **Ethereum's** comprehensive incentive and security structure are commendable, - though its high entry barrier remains a concern. +- **Algorand and Avalanche** struggle with incentives and security, limiting + their appeal and robustness. +- **Bitcoin Lightning's** complexity and potential removal of penalties may + hinder user engagement. +- **Cardano and Cosmos** offer accessible models but vary in terms of risk, + particularly regarding slashing. +- **Ethereum's** comprehensive incentive and security structure are + commendable, though its high entry barrier remains a concern. Ultimately, the protocol used by Orcfax must balance accessibility, security, and incentives to meet the evolving needs of staking participants. diff --git a/drafts/FAQ/faq-2.md b/drafts/FAQ/faq-2.md index 50be04c2..598b81dc 100644 --- a/drafts/FAQ/faq-2.md +++ b/drafts/FAQ/faq-2.md @@ -33,11 +33,11 @@ blockchain transaction are irreversible by their very design. For 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 or protests. +- 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 or protests. diff --git a/editorialGuide.md b/editorialGuide.md index 155915fc..9294284b 100644 --- a/editorialGuide.md +++ b/editorialGuide.md @@ -11,20 +11,20 @@ All acronyms capitalized unless never capitalized. > Examples: > -> - CER -> - ID -> - eUTXO +> - CER +> - ID +> - eUTXO > > Exceptions: > -> - dApp -> - DeFi +> - dApp +> - DeFi Rules regarding acronyms extends to currencies. > Example: > -> - ADA-USD +> - ADA-USD ### Titles @@ -44,8 +44,8 @@ numbers, or to illustrate a range. > Example: > -> - on-chain -> - between 1-10 +> - on-chain +> - between 1-10 Usage Example: This is an example of a PhoneGap client – which uses the Big Widget to run – and does x, y, and z. @@ -171,9 +171,9 @@ being: a, b, c, and d. Bulleted lists should use a single dash and follow the following convention: -- The first -- The second -- And so on +- The first +- The second +- And so on If the items within a bulleted list are complete sentences, use appropriate punctuation. @@ -193,11 +193,11 @@ consumed bit by bit. Documents that fall within this style are: -- Specs -- Glossary -- Editorial guide -- Integrator communications -- Third party solicitations +- Specs +- Glossary +- Editorial guide +- Integrator communications +- Third party solicitations The narrative style is intended for aggregate documents which can be read and understood as one document, to be read in parts or in whole. While a reader may @@ -206,9 +206,9 @@ in fuller understanding. Documents that fall within this style are: -- Orcfax updates -- Orcfax docs content -- Other Orcfax public relations documents +- Orcfax updates +- Orcfax docs content +- Other Orcfax public relations documents These two styles are further styled by their intended purpose. @@ -240,9 +240,9 @@ should also include the name of the technical component being introduced. Good page titles are: -- Understanding Orcfax validation -- Orcfax update # -- The subject of the update -- Orcfax architecture overview +- Understanding Orcfax validation +- Orcfax update # -- The subject of the update +- Orcfax architecture overview > Sample > @@ -316,7 +316,7 @@ keep titles shorter by leaving off extraneous language such as "how to". Good examples for page titles for instructive documentation are: -- Consuming Orcfax Statements +- Consuming Orcfax Statements > Sample > @@ -383,15 +383,16 @@ should not need to know anything about its implementation. ## General styling -- If a max line length is stipulated in a repositories config, then contributors - should ensure their adherence. +- If a max line length is stipulated in a repositories config, then + contributors should ensure their adherence. ## Resources This guide has been informed by the following editorial guides: -- [Adobe style guide][res-1] -- [Diátaxis][res-2]: A semantical approach to technical documentation authoring +- [Adobe style guide][res-1] +- [Diátaxis][res-2]: A semantical approach to technical documentation + authoring [res-1]: https://raw.githubusercontent.com/adobeio/styleguide/master/opensource/doc-style.md diff --git a/package.json b/package.json index ae15dc3c..73f6f4d4 100644 --- a/package.json +++ b/package.json @@ -14,6 +14,7 @@ "write-heading-ids": "docusaurus write-heading-ids", "typecheck": "tsc", "lint": "prettier --check . && eslint .", + "lint-write": "prettier --write .", "format": "prettier --write .", "pre-commit": "pre-commit run --all-files", "prepare": "husky"