Repository Inventory
This page is a complete inventory of repositories across the Elastos GitHub ecosystem. All figures below reflect actual GitHub analysis of the elastos/ and CyberRepublic/ organizations: star counts, last-push dates, archive flags, and fork relationships were collected from repository metadata and commit activity.
Repository counts, star totals, and “last push” dates change continuously on GitHub. Use this document as a structural map (what exists, how it clusters, what replaced what). Re-verify critical deployment decisions against live github.com/elastos and github.com/CyberRepublic pages.
Status Legend
| Status | Meaning |
|---|---|
| Active | Recent commits (2025–2026), meaningful ongoing development |
| Maintained | Occasional updates; stable code paths, not dormant |
| Stale | No material updates for 2+ years; may still build and run |
| Archived | Repository explicitly archived on GitHub (read-only) |
| Fork | Fork of an external upstream (not Elastos-original) |
| Deprecated | Superseded by another repository or product line; do not start new integrations |
Stale does not mean “broken.” Many libraries remain usable for existing deployments; it means no recent maintenance was observed at analysis time. Prefer Active or Maintained repos for new work.
Core Chain Infrastructure (20 repos)
The following table lists core blockchain and node repositories: main chain, sidechains, SPV, deployment, monitoring, merged mining, and legacy stacks.
| Repo | Language | Status | Stars | Last Push | Purpose |
|---|---|---|---|---|---|
Elastos.ELA | Go | Active | 112 | 2026-01 | Main chain node: BPoS + AuxPoW, UTXO model, 40+ transaction types |
Elastos.ELA.Arbiter | Go | Active | 2 | 2026-01 | Cross-chain bridge coordinator: multi-sig / Schnorr flows |
Elastos.ELA.SPV | Go | Active | 10 | 2025-10 | SPV library for light clients and wallet backends |
Elastos.ELA.SideChain | Go | Maintained | 13 | 2023-03 | Base sidechain framework (shared by ESC/EID lineage) |
Elastos.ELA.SideChain.ESC | Go | Active | 25 | 2026-01 | EVM sidechain (geth fork); Chain ID 20: smart contracts / DeFi |
Elastos.ELA.SideChain.EID | Go | Active | 1 | 2025-11 | Identity chain (EVM); Chain ID 22: DID-related on-chain ops |
Elastos.Node | Shell | Active | 2 | 2026-01 | Deployment orchestration scripts and packaging for operators |
Elastos.ELA.SideChain.ID | Go | Stale | – | – | Legacy ID sidechain experiments (superseded by EID / main-chain ID flows) |
Elastos.ELA.SideChain.Token | Go | Deprecated | – | – | Token sidechain retired in consolidation |
Elastos.ELA.SideChain.NeoVM | Go | Deprecated | – | – | NeoVM sidechain line dropped (2019–2020 architecture shift) |
Elastos.ELA.SPV.Cpp | C++ | Stale | – | – | Legacy C++ SPV stack; superseded by Go SPV for new projects |
Elastos.ELA.SPV.Java | Java | Stale | – | – | Legacy Java SPV bindings / samples |
Elastos.ELA.SPV.Node | Go | Stale | – | – | SPV node variant; niche operator use |
Elastos.Rosetta.API | Go | Stale | – | – | Rosetta-style API surface for integrations |
Elastos.Monitor | Go | Stale | – | – | Chain / node monitoring tooling |
Elastos.Elephant.Node | Go | Stale | – | – | Historical Elephant node distribution |
Elastos.Alliance.IBFT | Go | Stale | – | – | IBFT / alliance experiments (not mainnet path) |
Elastos.btcpool | C++ | Fork | – | – | Merged-mining pool fork (Bitcoin-side infrastructure) |
Elastos.MiscTools | Mixed | Stale | – | – | Miscellaneous utilities and one-off tools |
Elastos.Utility | Mixed | Stale | – | – | Shared utility scripts and helpers |
Operators and integrators should treat ESC (Chain ID 20) and EID (Chain ID 22) as distinct EVM namespaces. Wallet defaults, RPC endpoints, and contract addresses are not interchangeable.
Solidity Contracts (2 repos)
| Repo | Status | Purpose |
|---|---|---|
StakeTicket.Solidity | Active | BPoS staking contracts and NFT-style stake tickets on ESC |
ELink.Solidity | Maintained | Cross-chain oracle / bridge logic (ELink pattern) for EVM-side coordination |
Always verify deployed contract addresses per network (mainnet vs testnet) from official sources. Repository names alone do not imply a single canonical deployment.
DID (10 repos)
Decentralized Identifier (DID) support spans method specification, multi-language SDKs, contexts, and sample applications.
| Repo | Typical role |
|---|---|
DID.Method | did:elastos method specification and documentation |
DID.JS.SDK | JavaScript/TypeScript DID SDK |
DID.Java.SDK | Java DID SDK |
DID.Native.SDK | Native (C/C++) DID stack for mobile and embedded |
DID.Swift.SDK | Swift SDK for iOS/macOS |
DID.Cordova.SDK | Apache Cordova bridge for hybrid apps |
DID.Contexts | JSON-LD contexts and vocabulary files |
DID.App.KYC | KYC-oriented sample / application patterns |
DID.App.CredentialTools | Credential tooling and demos |
DID.Agent | Agent services for DID operations (issuance, resolution helpers) |
End-user identity flows in production often go through Essentials and ecosystem apps; SDK repos are the integration surface for developers building custom wallets and backends.
Hive (4+ repos)
Hive is Elastos decentralized storage: node software plus client SDKs.
| Repo | Role |
|---|---|
Hive.Node | Storage node: vault backends, provider APIs |
Hive.JS.SDK | JavaScript/TypeScript client |
Hive.Java.SDK | Java client |
Hive.Swift.SDK | Swift client |
Additional Hive-related repositories (plugins, samples, or lab repos) may appear under elastos/; treat them as per-repo Active/Stale based on last push when selecting dependencies.
Carrier (8 repos)
Carrier is the P2P communication layer. The ecosystem underwent a major rewrite (v1 → v2).
| Repo | Notes |
|---|---|
Carrier.Native | v2 native stack (current direction for new work) |
Carrier.Java | v2 Java bindings |
CarrierClassic.Native | v1 native (deprecated in favor of v2) |
| Additional Carrier repos | Classic v1 bindings, samples, and tooling; often Stale or Deprecated |
Do not mix v1 and v2 stacks in one product. New projects should standardize on Carrier v2 repositories and verify platform support (mobile, desktop, embedded) before committing to a client architecture.
Essentials (10+ repos)
Essentials is the flagship wallet / super-app and related services.
| Repo | Role |
|---|---|
Essentials | Meta-repo or umbrella for Essentials product |
Essentials.App | Mobile / client application |
Essentials.API | Backend/API surfaces supporting Essentials features |
| Additional Essentials.* | Plugins, branding, regional builds, experimental features; check last push per repo |
Essentials is the primary end-user entry point. Wallet SDKs (below) are the developer path for custom wallets and exchanges.
Wallet SDKs (6 repos)
| Repo | Role |
|---|---|
Wallet.JS.SDK | Primary TypeScript/JavaScript wallet SDK (HD, tx building, signing) |
Utilities.Java | Java utilities for server-side and exchange-style flows |
Keypair.C | C keypair and low-level crypto |
Keypair.Java | Java keypair helpers |
Keypair.Javascript | JavaScript keypair helpers (minimal surface) |
Connectivity.Client | dApp ↔ wallet connectivity client (not a full wallet) |
Historical note: Keypair.* capabilities were increasingly folded into Wallet.JS.SDK for JS/TS developers; prefer the unified SDK unless you need a minimal embedded footprint.
Governance (4 repos)
Repositories under CyberRepublic/ and related services support Elastos DAO governance, elections, and DID-based voting.
| Repo | Organization | Role |
|---|---|---|
CyberRepublic | CyberRepublic | Elastos DAO web platform and governance UX |
Service.Election | elastos / CR | Election services and APIs |
Service.DIDVote | elastos / CR | DID-linked voting services |
App.DIDVoting | elastos / CR | DID voting application frontends / clients |
Proposal and council mechanics interact with on-chain data, but many user-facing flows are served by off-chain services (APIs, indexes). Treat these repos as integration points, not as the sole source of consensus rules.
Summary Statistics Table
Aggregated across ~195 repositories in elastos/ and CyberRepublic/ (including forks, archives, and deprecated lines):
| Category | Total | Active | Maintained | Stale | Fork / Archived |
|---|---|---|---|---|---|
| All repositories | ~195 | ~21 | ~22 | ~41 | ~37 |
| Core chain & infra | 20 | (see section) | (see section) | (see section) | (see section) |
| Smart contracts (Solidity) | 2 | 1 | 1 | 0 | 0 |
| DID | 10 | – | – | – | – |
| Hive | 4+ | – | – | – | – |
| Carrier | 8 | – | – | – | – |
| Essentials | 10+ | – | – | – | – |
| Wallet SDKs | 6 | – | – | – | – |
| Governance | 4 | – | – | – | – |
Totals are approximate because (1) some repos span categories, (2) forks may be counted under “Fork / Archived,” and (3) private or transferred repositories may not appear in public scans. The ~195 figure is the documented ecosystem size at analysis time.
Deprecation Timeline
The following chronological list summarizes major deprecation waves and rationale. Exact archive dates vary per repo; years indicate ecosystem narrative, not necessarily the GitHub “archived on” timestamp.
2019: Early multi-chain simplification
- NeoVM-oriented sidechain experimentation scaled back; developer focus shifted toward EVM (ESC) and clearer main-chain responsibilities.
- ORG.* and early micro-service sprawl reviewed; redundant services consolidated or left unmaintained.
2020: Token chain and parallel stacks
- Token sidechain line deprecated in favor of asset representation on ESC and main-chain primitives.
- Wallet / SDK duplication targeted: teams encouraged Wallet.JS.SDK and Essentials-aligned paths.
- Several sample and boilerplate repos moved to Stale as documentation moved to official docs sites.
2021: Carrier and client ecosystem
- Carrier v1 repositories marked legacy as v2 APIs stabilized.
- SPV.Cpp / Java stacks gradually superseded by Go SPV for new integrations (exceptions for existing mobile binaries).
2022: Carrier v2, DID, and governance tooling
- Carrier v2 and DID work dominated core engineering; identity and P2P stacks matured alongside wallet and Essentials integrations.
- Election and voting services refactored; older CR web repos split between Maintained frontends and Stale experiments.
- Rosetta and exchange-integration repos: useful for specific partners, but not all received steady updates.
2023: Consolidation and documentation
- SideChain base framework updates slowed; ESC/EID forks remained Active as product chains.
- Broad stale cohort: repos with no commits 2+ years classified as Stale unless explicitly Archived.
When migrating: (1) identify the replacement repo from sections above, (2) check chain ID and RPC compatibility, (3) run integration tests against current testnets, (4) update CI to pin maintained dependencies only.
Key Observations
-
2019–2020 consolidation: NeoVM and Token chain directions were dropped or absorbed; ORG.*-style services retired or folded into fewer maintained surfaces. This reduced surface area for integrators at the cost of short-term migration work.
-
Carrier rewrite (v1 → v2): Approximately six Carrier-related repositories were deprecated or frozen as CarrierClassic and v2 Native/Java stacks took over. Mixed v1/v2 deployments are a frequent source of bugs.
-
SDK consolidation: Keypair.* libraries and scattered JS helpers were absorbed into
Wallet.JS.SDKwhere possible, lowering the number of supported entry points for TypeScript developers. -
Deprecation rate: About 47 of ~195 repositories (~24%) are deprecated or legacy. For a 7+ year project with two major architecture revisions (sidechain model + Carrier v2), this is expected: prefer Active/Maintained repos and treat the inventory as a living map.
- Run nodes: Start from
Elastos.ELA,Elastos.Node,SideChain.ESC,SideChain.EID, andArbiterdocumentation. - Build dApps: Prioritize ESC/EID, Wallet.JS.SDK, DID.JS.SDK, and Connectivity.Client.
- Storage: Use Hive SDK matching your language.
- P2P: Standardize on Carrier v2 native/Java bindings.
- Governance: Use CyberRepublic and Service.* election/voting repos as integration references.
Related reading
- Wallet SDK Ecosystem: language matrix and curve caveats (main chain P-256 vs ESC secp256k1).
- Cross-chain: bridge and asset flows (high level).
- Governance: Elastos DAO context.
Appendix A: Category rollups (ecosystem-wide)
The table below assigns each public repository to a single primary category for counting. Repos that could fit multiple labels (for example, a sample that uses DID and Hive) are classified by maintenance owner and default integrator expectation.
| Primary category | Approx. repo count | Typical status mix |
|---|---|---|
| Core chain, nodes, pools, monitoring | ~35 | Active concentrated in ELA, ESC, EID, Arbiter, Node |
| SDKs (wallet, DID, Hive, Carrier, connectivity) | ~55 | Higher Stale rate in legacy Keypair and v1 Carrier |
| Apps (Essentials, demos, CR web) | ~25 | Essentials line Active; many demos Stale |
| Specs, contexts, documentation-only | ~15 | Often Maintained with infrequent commits |
| Solidity / EVM contract sources | ~5 | Small set; high leverage (StakeTicket, ELink) |
| Infrastructure (CI, Docker, build) | ~20 | Mixed; pin by last push |
| Forks and mirrors | ~25 | Counted under Fork / Archived in summary |
| Deprecated / archived / experimental | ~47 | See Deprecation Timeline |
For any production service, generate a private inventory: list direct git dependencies, map each to this table’s Status, and fail CI if a dependency is Deprecated or Archived without an approved exception.
Appendix B: Extended deprecation notes (by theme)
Sidechain and execution environments
- NeoVM-oriented repositories were superseded by the EVM-first strategy on ESC (Solidity toolchain, standard Ethereum debugging).
- Token-specific chain repositories were retired in favor of ERC-20-style assets on ESC and native assets on the main chain where appropriate.
SPV and light-client stacks
- Go-based SPV is the default recommendation for new services that need merkle-proof style verification without a full node.
- C++ and Java SPV repositories remain as compatibility layers for long-lived mobile binaries, not as the preferred stack for greenfield apps.
Exchange and integration APIs
- Rosetta-aligned code may still be valuable for partners with Rosetta-centric middleware, but maintenance is intermittent. Validate endpoint parity with current node releases.
Mining and merged mining
- btcpool-family forks are Fork-classified; they track upstream pool software. Operational security for pool deployments is out of scope for this document; treat as infrastructure, not application code.
Appendix C: Quick lookup (“what should I use?”)
| If you need… | Prefer these repos (verify live status) |
|---|---|
| Run a supernode / participate in BPoS | Elastos.ELA, Elastos.Node, operator docs |
| EVM smart contracts (Chain ID 20) | Elastos.ELA.SideChain.ESC, StakeTicket.Solidity, ELink.Solidity |
| DID resolution and credentials | DID.Method, DID.JS.SDK (or language SDK matching your stack) |
| Decentralized storage | Hive.Node + Hive.*.SDK |
| P2P messaging / data channel | Carrier.Native, Carrier.Java (v2) |
| Mobile wallet UX | Essentials.App, Essentials.API |
| Custom wallet | Wallet.JS.SDK, Utilities.Java, platform Keypair.* only if required |
| Elastos DAO proposals / elections | CyberRepublic, Service.Election, Service.DIDVote |
Wrong chain ID or RPC URL is one of the most common production misconfigurations. ESC (20) and EID (22) are both EVM-family but not the same network; double-check in wallet settings and deployment configs.
Last synthesized from GitHub organization analysis of elastos and CyberRepublic. Re-validate counts and statuses before production dependency lock-in.