New chains rarely start from an empty file. Teams copy a proven codebase and modify it, which is why many networks share behavior they never advertised.
Why copying is the sensible default
Consensus code is unusually unforgiving, since a subtle bug produces a chain split or a halted network rather than a recoverable error.
Starting from software that has run under real load for years transfers that hard-won correctness, along with the edge cases nobody would think to test for.
It also transfers tooling. Wallets, explorers, libraries and node operators already understand the interfaces, so an ecosystem exists on day one.
What teams usually change
Parameters come first: block time, block size, issuance schedule and the fee model. These are configuration decisions rather than rewrites.
Consensus is the deeper change, and swapping proof of work for a stake-based mechanism touches far more of the codebase than a parameter table.
Execution environments are the third axis. Keeping compatibility with an established virtual machine lets existing contracts deploy unchanged, which is often the entire point.
Compatibility as a distribution strategy
A chain that speaks the same contract language as a large ecosystem can attract applications by asking developers to change a configuration value rather than rewrite code.
The trade is inheriting that ecosystem's design constraints, including its account model, its address format and its accumulated quirks.
Chains that diverge deliberately accept a smaller initial developer pool in exchange for design freedom, which is a bet on their differences being worth the friction.
What forking does not copy
Security in these systems comes from the participants securing the chain, not from the software. A copied codebase starts with none of the original network's validators or miners.
Liquidity is similarly non-transferable. Applications may deploy identical contracts, but the assets and users sit on whichever chain they were already on.
Ongoing maintenance also stops being shared. Once forked, upstream fixes must be manually adopted, and divergence makes that progressively harder.
Reading a fork's actual position
The informative questions are what was changed, who maintains the changes and whether upstream security fixes are still being tracked.
A repository that has not pulled upstream changes in a long while may be carrying known issues that the original project fixed some time ago.
Shared ancestry also means shared vulnerabilities, so a flaw disclosed in a widely copied codebase becomes a problem for every descendant at once.