New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
Long-running cryptocurrency projects accumulate several kinds of version numbers. A project page can name a proof-of-stake protocol generation, a wallet can publish a software release number and a repository can contain experimental work on another design. Those numbers do not form one simple ladder. Choosing the largest one does not establish which rules the intended network currently accepts. This guide explains the evidence needed to describe a change accurately. The early BlackCoin.info sources provide historical context, while present project references belong to a different period. Neither should be silently treated as a complete specification of every later implementation using a similar name.
A proposal explains an intended change
A proposal describes a design, a problem it aims to address and a set of intended changes. It can be technically valuable without having been implemented or adopted. Reading a proposal therefore answers questions about the proposed mechanism and its argument, not automatically about the behaviour of the live network. Look for its date, author, scope and assumptions. A convincing abstract is the start of an evidence trail. It does not replace the separate work of establishing whether the proposed rules were implemented, released and activated in the system being discussed.
This distinction matters when comparing old documents. A historical introduction may describe a limitation that a later design attempts to address, while another source may discuss a different implementation altogether. Combining those descriptions into one present-tense account can create a protocol that no actual network runs. A useful reading note attributes each claim to its document and version. That allows the technical argument to remain interesting without treating publication of the argument as proof that every participant changed behaviour on the document's publication date.
An implementation makes rules executable
Implementation moves a design into software, but code in a repository can occupy several states. It may be an experimental branch, a proposed change under review, a merged feature awaiting release or an older implementation preserved for reference. The exact repository and revision matter. A link to a project's front page is less precise than a reference identifying the relevant code state. Before describing how a rule works in practice, establish which implementation is meant and whether the cited code actually contains that behaviour in the version under discussion.
The relationship between a proposal and its code can also involve interpretation. A document can explain the general design while the implementation determines detailed edge cases, data formats and validation conditions. Differences should be investigated rather than automatically resolved in favour of whichever description is easier to quote. This does not require every reader to become a consensus developer. It requires honest scope: a general overview, a source-code observation and a verified runtime result provide different levels of evidence and should be labelled according to what was actually examined.
A release identifies a software artifact
A software release packages an implementation for use under the publisher's stated conditions. Its version number belongs to that software's release process. It need not match a protocol generation number printed in a white paper or on a project overview. Wallet interfaces, dependency changes and packaging fixes can lead to new software releases without a corresponding consensus change. Conversely, a consensus transition can require careful release and activation coordination beyond what a simple version label communicates. Comparing the numbers without identifying their type is therefore a category error.
A precise release description names the client, publisher, release version, relevant notes and intended network. If more than one implementation exists, keep their release series separate. A fork may publish a higher version number under its own scheme without becoming the automatic successor for every user of the original project. The useful question is compatibility with the intended rules and starting state, not numerical size. This is why a release evidence trail includes provenance and transition documentation instead of relying exclusively on the title of a downloaded file.
Activation is a network event or condition
A change can exist in released software before the conditions for using it on a network have been reached. Different systems coordinate activation differently, so a specific claim needs a specific mechanism and evidence. An announcement that a feature is available does not, by itself, establish that the intended network has activated it. Likewise, evidence of activation should identify the relevant network and rule transition rather than rely on a broad statement that an upgrade happened somewhere within a collection of related repositories.
This distinction helps prevent a common historical error: using a release date as though it were automatically the activation date. The dates can be related without being identical. A clear chronology records proposal publication, implementation milestones, release availability and observed activation separately when those facts are known. If one stage is undocumented, preserve the gap. A neat timeline assembled from assumptions is less useful than a partial timeline that accurately identifies which transition each available source supports and which event still needs verification.
Names do not define network agreement
A shared currency name, familiar logo or similar repository title cannot establish that two implementations accept the same chain under the same rules. Consensus compatibility concerns validation behaviour, not branding. Source repositories can preserve history, propose alternatives or serve different communities. An independent information site should therefore avoid declaring a particular project derivative to be the universal answer merely because its name appears prominently in a search result. The evidence must connect the implementation and release to the network and rule set actually being discussed.
The recovered BlackCoin.info pages illustrate another naming boundary. The domain once redirected toward a project site and later operated a faucet interface. Those facts do not make every statement on the faucet page a formal protocol specification. Its broad language about rewards and account behaviour belongs to its historical presentation. Current project materials are different sources with their own scope. Keeping those relationships separate makes it possible to explain the site's history without granting an old promotional paragraph authority over later technical questions that it was never designed to settle.
State which transition the evidence establishes
A strong upgrade summary can say that a particular document proposed a mechanism, that a named implementation included it at an identified revision, that a release made that implementation available and that a specified network met its activation conditions. Each clause can have its own reference. If only some clauses are supported, report only those supported stages. This does not make the description incomplete in a misleading way. It makes the remaining uncertainty visible and gives the next researcher a precise question instead of a vague instruction to find the latest version.
The lasting method is to keep the four stages separate: proposal, implementation, release and activation. They describe a chain of evidence rather than interchangeable labels for progress. This distinction makes BlackCoin's historical sources easier to place and helps readers assess other long-lived open-source networks as well. A version number becomes meaningful when its object, publisher, date and relationship to the intended network are known. Without that context, it is only a short label carrying more apparent certainty than the available evidence may justify.
Technical references
From the recovered archive
- The 2014 redirect to BlackCoin.co · captured 7 July 2014
- The historical faucet account interface · captured 15 October 2016
- The historical forbidden-status page · captured 8 December 2017