w3f/polkadot-wiki

The source of truth for Polkadot.

Polkadot Wiki

The Source of Truth for Polkadot

• Contributing to Documentation
• Running Locally
  • Build
  • Start
  • Publish
• Style and Configuration Guide
  • Formatting
  • Search Engine
  • Automation
    • Deployments
    • GitHub Actions
  • Conditional Rendering
  • Inline React Components
• Internationalization
• License

---

The Polkadot Wiki is the central source of truth for Polkadot. It is a community-focused initiative led by Web3 Foundation to keep an up-to-date resource on the best information for learning, building, or maintaining on Polkadot.

Contributing to Documentation

The Technical Education team at Web3 Foundation are the primary maintainers of the Wiki and will review all issues and pull requests created on this repository. If you notice typos or grammatical errors, please feel free to create pull requests with these corrections directly. Larger contributions may start as issues to test the waters on the subject with the maintainers. It is generally preferable to create a pull request over an issue to propose a change to the Wiki content.

✨ The Wiki belongs to the community, help generate its identity. ✨

identity.mp4

📥 There will be an upcoming initiative that will promote and encourage contributions towards Polkadot-based content and documentation. In the meantime, feel free to share any ideas or feedback you may have for the Wiki by opening a Feature Request issue.

Keep engaged by checking out these common Polkadot ecosystem resources.

Running Locally

Both the Polkadot Wiki and the Kusama Guide are built from the source files in this repository. After cloning the source locally, you can start the websites with each of these respective commands (ensure you run yarn at the root of the repository first to install dependencies).

The Wiki uses Algolia search, which can be accessed locally by providing the correct App ID and API key. The app_id and api_key environment variables are needed for the Wiki to be built successfully. If you are an external contributor, set the variables with some values like shown below, which lets the Wiki repo build successfully (but disables the search bar).

export app_id="xxxxxx" api_key="xxxxxxx"

Using yarn, run:

yarn install

Build

🐦 Building the Kusama Guide:

yarn kusama:build

🟣 Building the Polkadot Wiki:

yarn polkadot:build

Start

🐦 Starting the Kusama Guide:

yarn kusama:start

🟣 Starting the Polkadot Wiki:

yarn polkadot:start

Publish

🐦 Publishing the Kusama Guide:

yarn kusama:publish-gh-pages

🟣 Publishing the Polkadot Wiki:

yarn polkadot:publish-gh-pages

Style and Configuration Guide

Use the style guide from the Substrate Knowledge Base

Formatting

Prettier is automatically run when making a local commit. Verify that all changes render as expected after making new commits by running the projects locally.

See the Conditional Rendering and React Components sections for additional details regarding how to properly format syntax for elements outside of the standard markdown library.

Search Engine

Algolia DocSearch is the search engine that is used, which is built into Docusaurus. Indexing via Algolia provides faster lookup; the actual configuration for lookup is located in another repository that Algolia DocSearch maintains.

We have enabled searching on the Wiki by declaring the algolia section in the siteConfig.js file in scripts, and defining an API key and index name that are provided by DocSearch.

  algolia: {
    apiKey: "53c6a4ab0d77c0755375a971c9b7cc3d",
    indexName: "kusama_guide",
    algoliaOptions: {
      facetFilters: ["language:LANGUAGE"],
    }, // Optional, if provided by Algolia
  }

If you would like to access and modify this, you can re-submit the documentation url via DocSearch Program, where they will send a JavaScript snippet that you can re-integrate into the configuration, similar to the one shown above.

Automation

Deployments

The Polkadot Wiki is built on the gh-pages branch and automatically deployed to GitHub Pages. The Kusama Wiki is also deployed to GitHub Pages (via a separate repository).

Development servers exist at https://staging.polkadot.network and https://staging.kusama.network. The servers will reflect the latest master commit or PR put up against the master branch by a member of the Technical Education team. A staging environment can be generated to reflect a specific branch by invoking the workflow_dispatch command via the GitHub UI and can then be reviewed by the team before proceeding to production. If all is well, the new commits on master are transferred into the production branch,prod, by rebasing master on prod. This is completed automatically every 24 hours or manually through a workflow_dispatch command. After these jobs are completed, the CICD production workflow will automatically deploy prod to the public sites: Polkadot Wiki and Kusama Guide, respectively.

GitHub Actions

Job	Description	Frequency
Audit Images	Searches for unreferenced images in the docs repository and archives them into /docs/assets/_legacy.	Monthly or Workflow Dispatch
Audit Links	Test all links in the docs for broken references and opens a new issue displaying results if any are found.	Monthly or Workflow Dispatch
Code QL Analysis	Tests for vulnerabilities across the codebase	Weekly, Push to master or Pull Request to master
Dependabot	Helps keep packages up-to-date with latest release.	Daily
Deploy Kusama Prod	Deploy Kusama docs to GitHub Pages (production).	Daily or Workflow Dispatch
Deploy Kusama Staging	Deploy Kusama docs to staging environment.	Workflow Dispatch
Deploy Polkadot Prod	Deploy Polkadot docs to GitHub Pages (production).	Daily or Workflow Dispatch
Deploy Polkadot Staging	Deploy Polkadot docs to staging environment.	Workflow Dispatch
Generate PDF	Generate a PDF for the docs and upload it to the static website.	Disabled Manually
Greetings	Greet first time contributors.	First Time Pull Request or Issue Creation
Jest Testing Coverage	Run a series of Jest tests related to React functionality.	Weekly or Workflow Dispatch
Pages and Build Deployment	Deploy Polkadot docs prod branch from GH Pages to public site. (This was originally setup through the GitHub settings menu, prior to GitHub Actions flows)	On Push to gh-pages branch
Prettier All	Run prettier over all docs to maintain styling standards.	Weekly or Workflow Dispatch
Status Badges	Update the commit history of various open source projects in the ecosystem.	Weekly or Workflow Dispatch

Conditional Rendering

The two Wikis support conditional rendering depending on which Wiki is being deployed. This is useful for mirrored pages with most content in common but have minor differences. To use this functionality, surround Kusama specific content with {{ kusama: KUSAMA_SPECIFIC_CONTENT :kusama }}, and polkadot specific content with {{ polkadot: POLKADOT_SPECIFIC_CONTENT :polkadot }}.

For example the syntax:

The {{ polkadot: Polkdadot Wiki :polkadot }} {{ kusama: Kusama Guide :kusama }} is a great resource!

Will render:

The Polkdadot Wiki is a great resource!

or

The Kusama Guide is a great resource!

depending on which project is currently loaded.

To verify the appropriate values have been substituted in each scenario, run polkadot:start and kusama:start in separate terminals. If prompted with [WARNING] Something is already running on port 3000. Would you like to run the app on another port instead?, proceed with yes. This will likely launch one project on port 3000 and the other on 3001, allowing you to compare the rendered outputs for both projects locally and simultaneously.

Inline React Components

Occasionally you may require additional functionality that is outside of the scope of basic markdown. React components can be used inline in existing markdown documents as a solution, allowing you to render custom elements. This is currently the strategy used to retrieve live on-chain values and display them directly in the docs without the need to recompile or even reload the web app using RPCs.

If you are looking to invoke and embed data from 3rd party APIs or sources, checkout the Http-Request-Sample component. A full list of sample components can be found here.

Try and reuse existing components as much as possible instead of creating new ones to keep the code lean and comprehensive. It is also important to verify prettier has not modified the formatting of your component after making a commit. Below are some best practices for achieving common formatting that will not be modified by the prettier command:

Always wrap RPC components in conditional rendering & keep them on new lines:

{{ polkadot: <RPC network="polkadot" path="query.staking.validatorCount" defaultValue={297}/> :polkadot }}
{{ kusama: <RPC network="kusama" path="query.staking.validatorCount" defaultValue={297}/> :kusama }}

To add grammar without added spacing, place the grammar inside the conditional brackets:

The validator count followed by a period is
{{ polkadot: <RPC network="polkadot" path="query.staking.validatorCount" defaultValue={297}/>. :polkadot }}
{{ kusama: <RPC network="kusama" path="query.staking.validatorCount" defaultValue={297}/>. :kusama }}

The validator count in parentheses is
{{ polkadot: (<RPC network="polkadot" path="query.staking.validatorCount" defaultValue={297}/>) :polkadot }}
{{ kusama: (<RPC network="kusama" path="query.staking.validatorCount" defaultValue={297}/>) :kusama }}

Failing to follow this schema can results in unexpected formatting, such as added line-breaks or spacing, especially after running prettier.

Internationalization

❗ The Wiki is currently being reorganized and updated. Work will resume on translations after the Wiki revamp is completed.

License

The Polkadot Wiki is licensed under the GPL-3.0 free software license.

polkadot-wiki's Issues

Council Election Guide

-To be a council member (Submit candidacy)
-Vote for a candidate

Remove incorrect statements about account keys and session keys

Brings in this open PR from the old wiki.

@burdges, any idea when the proxy key will be introduced? I'm a bit hesitant adding it to the wiki if it's not going to implemented during the Kusama cycle.

Parachain section

As we progress closer to the launch of the main Polkadot network, and more soon the availability of Kusama as a network for parachain developers to start experimenting with launching parachains on, the wiki should evolve a whole new section that contains parachain specific information.

Since parachain content currently lives across the three main sections of the wiki, in the Build, Learn, and Maintain sections, the Parachain section would be on the same level as these headers.

Parachains
  |
  |-- Collators
  |-- Parachain Development Kits
  |-- Parachain Economics
  |-- Parachain Standards

The biggest question if we do this is how much it overlaps with what we currently have in the Build section, since the build section focuses on parachains. Smart contracts and tooling would still live in the build section; also tutorials and materials for workshops and hackathons.

Implementations - Kagome

Implementations page (https://wiki.polkadot.network/docs/en/learn-implementations) says Kagome will be released in August 2019. Needs an progress update, maybe a link to the release post if one exists, or an extension of the release date.

Clarify that stash is selected when nominating a validator

Migrate validator procedure

Add a section/page on how to migrate the validator node to another machine

Phragmen Updates + Council Documentation

Now that phragmen is enabled for Kusama for the council elections we should update the documentation on Phragmen to reflect the latest functionality. We should also add information on running for the council that is more accurate to Kusama.

Add more SPREE information

Information on SPREE is kind of light (although since it is not yet implemented, this is to be expected).

Host presentation slides

We need a directory that hosts all the presentation slides for people to read, copy, remix and use.

Explain what happens to parachain slots when number of validators dramatically drops

If the goal is to have 5 validators per parachain slot, then what happens when number of validators decreases suddenly and some chains end up with a single validator responsible for them? How is such a scenario mitigated? Would there ever be purposeful skipping of a slot to normalize things? Say out of 100 validators 81 have stupidly hosted on AWS. Now the 20 parachain slots have 19 validators between them because AWS went down. What happens?

Slashing across eras with NPoS

-add a section to explain how slashing would happen across eras

Source: https://research.web3.foundation/en/latest/polkadot/slashing/npos/

Redirect if a translation page is not found

When clicking on a page in a different language that doesn't yet have a page we should redirect to the English version instead of throwing 404.

Polkadot UI page and address generation

The Polkadot UI page is not being displayed on the sidebar.

https://github.com/w3f/polkadot-wiki/blob/c1bf0d5879532beaa7b57fcaad69e7e03e3fb737/docs/learn-UI.md

[high priority] Address generation page

HIGH PRIORITY

We need a page that is updated / full of images with step-by-step instructions for generating an address.

Phragmen storage bloat and equalization clarification

If 16 validators can be nominated by a nominator, and the table of stakes per validator for each nominator is stored on chain and rebalanced every Phragmen run, this makes it seem like we'll be writing a lot of arbitrary data regularly.

What are the storage implications, has any research been done? Can offline workers help? Run phragmen locally, commit just a hash, gossip table and hash with other nodes?

Further, Phragmen needs an offline simulation runner to be able to present people with a solution to a question like this:

Given only 2 slots, and validators of such setup:

• A: 0 own stake, 50 DOT from N1, 50 DOT from N2
• B: 25 own stake, 50 DOT from N1, 10 DOT from N2, 15 DOT from N3
• C: 105 own stake, 0 DOT from nominators
• D: 100 own stake, 0 DOT form nominators

Which two validators end up being in the slots? C is obvious (hopefully) but who is the second?

Add Session, Era, Epoch to glossary

Additionally, it would be nice to add a couple related pages to glossary entries, so that it also acts as a kind of index.

Create a validator slashing conditions section

Many times validator groups have asked specific questions about what conditions would result in certain slash/s happening

E.g. from today:

"are there guidelines as to the percentage that a validator has to adhere to? For example, 90% of blocks must be produced in under a second? If yes what are the penalties/sanctions for a validator that doesn't meet the required performance?"

It would be nice to have a section explaining each slashing condition and what might result in being slashed in a clear way on the wiki for validators.

add parathreads to polkadot builders guide & developer portal

The parathread model is missing from our story. Now you can more easily and less expensively be a solo chain and access the relay chain when you need finalization/interoperability. People still believe getting a parachain/building on Polkadot is expensive. With the advent of parathreads, that's not true. So we should highlight that in our builders portal so builders know that it is economically viable to build a blockchain w/o running an initial parachain offering or buying a bunch of DOTs.

Polkadot abstracts away the infrastructure layer for blockchains

• choose your own security model
• seamlessly transition between Shared Security and Solo Chain Security (PoA/PoS/PoW)
• pay for interoperability/finalization as-you-go (less DOTs) or all upfront (more DOTs)

Get interoperability, security, & finalization as a parathread for 50 DOTs [pay as you go model] or as a parachain [open auction, guaranteed-24/7 throughput]

Commoditization of Trust

How does Polkadot make trust into a commodity? What does this mean on concrete terms? How can we move more towards a continuum of trust <-> trustless rather than the binary option of either full trust or no trust?

Explain the validator limit

The validator number being thrown around is 1000. This warrants some explaining due to Ethereum aiming for up to 250000 validators and also using BLS aggregation (though I understand Polkadot keys are not BLS yet).

The validator count is one people really sink their teeth into when speaking about decentralization, and most will not look into Phragmen and the rebalancing that's going on there.

I do know both projects are basically guesstimating, but in our tests on Nimbus we've easily surpassed 1000 validators on non-local machines in our Nimbus-only testnet, over Libp2p. Granted, no data, just empty blocks being gossiped and justified/finalized, but still.

I understand that no one knows how much our limit will actually end up being when data comes into play and the network is saturated with gossiping collators and validators, but in light of Ethereum advertising numbers 2 orders of magnitude higher, we should at least explain that this is a guess and a conservative estimate and that we absolutely hope / expect that number to go way higher, unless this is not the case.

Thoughts?

The description in the wiki render is invalid

This causes renders in social media, slack, and other previews to look weird.

When there are empty blocks, AURA kicks in. Documentation needed.

During the shuffling, some blocks have no slot leader candidates. These slots used to remain empty under BABE, but with AURA which runs in constant time to catch up with those, they are handled. This has some ICMP implications too, given that queues can get filled up if a block is skipped.

We need a document about AURA. I'll see what I can do about that once I've digested the paper unless someone is already more familiar.

Storage rent and tombstones

There are two implementations of this.

1. In smart contracts, the system will function just like in Eth where you restore a contract for a price, from an archive node. This is documented in the substrate dev docs: https://substrate.dev/docs/en/ecosystem/contracts/ink#storage-rent\

2. There exists also the tombstoning concept of parathreads (and possibly chains?). A dead chain / thread will have its last block registered on the relay chain it's attached to. If all collators die, then that block becomes a tombstone. In such a case, all that's needed to restore this thread/chain to life if there ever appears a need to do this again is by paying the restore fee (explain? To whom? How?) and continuing to build on it as a revived collator. For this to happen, archive nodes are necessary (archive of what - the parachain / thread? Isn't that every collator basically?).

Further explanation necessary on what happens with hierarchical chains / threads. Consider a relay parachain with parathreads and child chains. So, say their blocks are being stored on the relay chain, and then one such sub-chain or sub-thread dies (no collators). It can be restored via the mechanics outlined above, that's ok. But what if our relay parachain dies - the one keeping the last block of this thread/chain? How do you restore that? You would first need to somehow restore the relay parachain to get the last block of its children, and then restore those? Again, to whom are the restore fees paid?

Further reading:

• https://github.com/paritytech/substrate/blob/master/srml/contracts/src/lib.rs
• https://github.com/paritytech/srml-contracts-waterfall/tree/master/contracts/rust/restore-contract

Add fishermen section

-What's the role of fishermen responsible for?

-Mechanism of the whole reporting procedure

-Which level of the slashing(4 different levels) will be specifically for fishermen

-Is that anyone allows being a fisherman (just by running a program)?
-Required to lockup DOT or not?
Only allow validators to run or open for everyone (I think it makes sense to open for anyone with depositing a minimums amount of DOT for security purpose to prevent misbehaviour in the network(e.g. keep submitting incorrect reports)

-Rewards mechanism
the first reporter gets all or based on the submission time or case by case?

-Fishermen program
Running an external fishermen program (e.g. MakerDAO CDP keeper) or could be a Polkadot node with customised configuration?

The link to BABE randomness is dead

https://research.web3.foundation/en/latest/polkadot/BABE/3-VDF/#unbiased-randomness does not exist. Could not find matching page in Research.

Related to #73. Randomness is a black box and desperately needs to be clarified.

Update Kusama validator page (no Controller = Stash) once PoS is live

After PoS goes live, we'll want to eliminate any talk of Controller being the same as Stash.

https://github.com/w3f/polkadot-wiki/blob/master/docs/maintain-guides-how-to-validate-kusama.md

Explain moving to/from parathread/parachain

In learn-parathreads.md, we should go into more detail about moving back and forth between parachain and parathread.

https://github.com/w3f/polkadot-wiki/pull/52/files/7fb7bae49f4879f52fdb2d6b73c7dfc8b52e0e97#diff-1d51784cdb2416bf4d25a9ee46604911

Document uncle rewards

https://research.web3.foundation/en/latest/polkadot/Token%20Economics/#payment-details

(the exact values of the point system are up for discussion. There are no good reasons for those exact values)

Validators get paid for different actions. Both to the block producer who includes a reference to an uncle block, and the author of the uncle block are paid.

We pay more to the former. The logic is that the system doesn't really benefit from uncle blocks, but it does benefit from having a record that an uncle block exists, so we can detect equivocations (i.e. the block producer deciding to create two blocks at the same height). I guess it made sense in PoW where uncle rewards were a consolation for wasted energy to no fault of the miner (latency, instead), but here the cost of block production is nothing.

Best location - learn-dot? learn-consensus? Leaning towards learn dot, plus a mention in learn-consensus with link.

Replace "two spaces after full stop" with "one space after full stop"

It's time for Bill to finally get with the Times New Roman

Comparison of blockchain projects based on expectation and delivery

This issue is a replication of this one from the old wiki. The idea is that we compare projects that have promised certain features or capabilities to what they have delivered in practice, or at least what progress they have made toward the delivery.

This is to dispel some of the myths that projects create about the functionality of their chain.

All we need to close this issue is a table that compares features of each project. All detailed information should be in the individual comparison articles for each project, if they exist.

See the table on Wikipedia's Comparison of Linux for an example of what this table should look like.

Update ICMP

There's new information on ICMP that needs to be integrated into the ICMP page on the wiki:

Gav's write-up
Research write-up

Kusama Section

Evaluate integrating all Kusama content into the wiki in it's own "Kusama" section. This would make it easier to maintain as a single repository but may clutter up the Polkadot wiki unnecessarily.

Secure Validator Sentry

Instruct users to set the --sentry flag on public nodes.

Check with lack of "blob" due to 15 -> 12 digit granularity

See: https://github.com/w3f/polkadot-wiki/pull/52/files/528df777623db790828b65ebe7d7c4d55a97c504

Add GTM

Google analytics and Google Tag Manager

Sidebar subsection structure proposal

Here's a proposal for restructuring the wiki's sidebar.

Current

• DOT
• Polkadot Runtime Environment (PRE)
• Polkadot UI
• Architecture
• Parachain Slots Auction
• Basics
• Bridges
• Polkadot vs. Cosmos: Design Comparison
• Polkadot comparisons
• Polkadot Consensus
• Cryptography Explainer
• Frequently Asked Questions (FAQs)
• Governance
• GRANDPA
• Polkadot Implementations
• Learn about Polkadot
• Interchain Message Passing (ICMP)
• Polkadot
• Polkadot Keys
• Parachains
• Parathreads
• What is Phragmen and what does it mean for node operators?
• Randomness
• Links
• Roadmap
• Security of the network
• SPREE
• Staking
• Treasury
• WebAssembly (Wasm)

Proposed

• Basics (remove current basics page altogether)
  • Polkadot (append "Learn about Polkadot")
  • Architecture
  • Security of the Network
  • Consensus (merge with GRANDPA page)
  • Governance
  • Bridges
  • Parachains
  • Parathreads
  • Polkadot Runtime Environment (PRE)
  • Treasury
• Advanced
  • Staking
  • Randomness
  • SPREE
  • WASM
  • What is Phragmen and what does it mean for node operators?
  • Interchain Message Passing (ICMP)
• Cryptography
  • Cryptography in Polkadot (Cryptography Explainer)
  • Polkadot Keys
• Polkadot Comparisons
  • Polkadot vs. Cosmos
  • Polkadot vs. Ethereum (will be external link to my post published elsewhere)
  • Polkadot vs. Tezos (split from current Comparisons page)
• Economics
  • DOT
  • Parachain Slots Auction
• Implementations
  • Runtime Clients (renamed from current Implementations page)
  • Web3 Tools (browsers, wallets)
  • Polkadot UI
  • Developer Tools (github repos of interesting projects)
• Misc
  • Roadmap
  • Links
  • FAQ

Probably warrants some reordering in individual subsections to keep the learning flow intact and more aggressive cross-linking across pages, but should read better if following things in sequence.

Parathreads, parachains, and local tokens

Assuming a parathread has its own local token system, it pays the collators from the transaction fees in its local token. If the parathread does not implement a local token, then it can use DOTs

As mentioned in #66 the local economy and related aspects of chain/thread need to be clarified. The second sentence seems restrictive, given that a thread and become a chain and vice versa - what happens to this condition then? Shouldn't this choice be entirely up to the chain/thread developer? So...

• thread: should use local token to reward collators. Can use DOT if not using local tokens.
• chain: should use DOTs for everything. Can use local tokens.

Is the above accurate? That's the impression I'm getting from the wording above.

---

Collators may be paid in local parathread currency. However, the relay chain transacts with the Polkadot universal currency (DOT) only. Collators must then submit block candidates with an associated bid in DOT. This means that if the parathread offers a local currency, the collator will need to understand the exchange rate between this currency and DOT in order to place a proper DOT bid on the relay chain and ensure that they make a profit.

So collators of chains vs collators of threads differ in implementation. Where collators of chain pass data to the validator who then submits a block, collators of threads build and submit a block themselves and then submit it for block inclusion via the block bid. This difference in collator should be specified somewhere more concretely, and whether or not this will be implemented in Cumulus by default or if one will need a different PDK for thread projects.

Validator anonimity

Is there any official mention somewhere about validator anonymity or research being done I could look at?

There is an answer by gav saying that dos resistance is up to the validator / collator. Seems a little discouraging to the home staker / nominator, but I guess some best practices like using a dedicated internet connection which can switch IP on demand would be a decent solution.

@lsaether says Sergei is doing some of this work, so I'm going to talk to him asap, but in the meanwhile is there any official roadmap/discussion on this? Any thoughts from you guys as potential collators / validators?

Contributors

Add a page that list out all contributors / maintainers

Guide: Voting for Referenda

We need a step-by-step guide for how one would vote on a referendum using the democracy module.

Beginner's Page

We should have a page for someone that is totally new to Polkadot and introduces the major concepts using some videos and light articles.

Validators are storage-rich because they need to keep state of ALL chains

The validator hardware requirements need to be updated to say that while an average CPU will be fine, an average disk will not be, nor will an average internet connection probably. People are expected to need 1TB SSDs fairly quickly given that all validators need to sync all parachains at all times, due to not knowing which chains they are being assigned to ahead of time.

PDF Downloads

We should enable PDF download so that people can have an offline way to read the content.

Create Circle CI scripts

https://docusaurus.io/docs/en/next/translation#automated-file-sync-using-circleci

We should do autmoated file sync and automated deployment.

• Automated Deployment
• Pulling in translations

Translation Migration

@ansonla3 mentioned in the weekly sync that the migration of the translated docs involves a lot of manual work. If it's possible to write a script to migrate the docs we should do that, but otherwise might just need to bite the bullet and copy-paste everything over now in chunks.

Anson, do you have any ideas for getting all the translated content onto CrowdIn?

Randomness page needs clarifications

The randomness page needs more work, especially in comparison with Ethereum 2.0's RANDAO+VDF approach and why the quadratic compute doesn't hit them, while advertising much higher numbers on much weaker hardware in terms of nodes.

Create a dedicated community page with logos

Right now, we have a bare bones community page with links. Instead we should have a dedicated page that projects can submit their logos with links. Similar to what Docusaurus does in the "Who's using Docusaurus" section.

Clarify onlineness

It is not clear how often or how hard one would be penalized when offline.

We should make it very clear that:

• the size of the penalty depends on how many others are offline at the same time
• the frequency of the liveness ping is once per epoch, which is 4 hours currently. This means that you may be asked to chime in twice in 10 minutes (if you get asked at the end of one and the start of another epoch), or once in 7 hours. The unanswered question here is - what happens if I chime in as online once per epoch, but then still don't show up for work when selected? Is the "work" part counted as another "I'm online" ping?
• the ping is on-chain (state bloat possible?)

Reading blockchain parameters from the chain

There are several bits of information in the wiki which get outdated easily, whenever a parameter in Kusama (and later Polkadot) changes. E.g. the validator count going from 25, to 50, to 100. The council mandate duration going from 100 blocks, to 2 hours, to 1 year(?). The number of parachain slots, the reward distribution, and more.

My suggestion is making a simple script we could slap into the docusaurus output template which would, on each render or each CI run fetch these values from the live blockchain and replace template values with them. For example, instead of writing "Council members remain in position for 1 year unless voted out by a referendum" you'd write "Council members remain in position for {{COUNCIL_DURATION || 1 year}}" and the script would fetch council duration straight from the chain, translate to human readable value, and replace the template. If it doesn't find a value it defaults to "1 year".

This would also be a nice side project, a super-lightweight JS package for reading chain params, which would then be usable by others as well (block explorers, for example).

This is maybe a good target for Hackusama?

Compare to Dfinity