Controlled Access · By Invitation

The framework built for
engineers who know the bar.

HBForge is not on npm. There are no open pull requests. No issues tab. No public roadmap votes. We work with developers who bring production-grade discipline — not contributors who want a GitHub star.

Current status: T0 internal · T1 limited enterprise · T2 preview applications open

Three levels. One bar.

Every tier carries the same quality expectations. What changes is scope, depth, and influence over the roadmap.

Core
T0 — Internal
HyperBridge Team
The engineers who built HBForge
  • Full source access — every module, every branch
  • Writes the implementation for all approved RFCs
  • Owns the quality bar and conformance harness
  • Controls the release cadence and semver decisions
  • Uses HBForge daily on live production systems
T1 — Vetted Partners
Enterprise Clients
Invited enterprise accounts with production use-cases
  • Full module access including pre-release builds
  • Private changelog — release notes before public site
  • Can submit RFCs — reviewed each monthly window
  • Direct line to the T0 team for integration support
  • NDA required · access token rotates every 90 days
  • Kynetra Prime hosted infra + SLA
T2 — Preview Guild
Selected Developers
Engineers who passed the application review
  • Read-only source access to approved modules
  • Sandbox environment with all 75 modules
  • Guild channel — async access to T0 team
  • Monthly RFC window — submit capability requests
  • Preview builds 2 weeks before T1
  • Credited in changelog on accepted RFCs

T2 → T1 graduation after 3 months of active, production-grade usage + one accepted RFC

"The open source model optimises for reach. We optimise for correctness. Anyone can open a PR. Not everyone should ship to production."
— HyperBridge Digital, on why HBForge is not open source

Five reasons engineers choose
the harder path.

The guild is not the easiest way to build. It is the most honest way to build. Here is what you get in return.

01
🔐

Your code never breaks because of someone else's package

Every production incident you've ever blamed on a transitive dependency ends here. HBForge has zero external dependencies — not "minimal", not "optional" — zero. When you ship on HBForge, the only code that runs is code you can read, understand, and trust. No supply-chain surprises at 3 AM. No abandoned maintainer pulling a package. No version conflict two levels deep. Guild engineers describe this as the first time they've felt in control of a production stack.

0 external deps 106,300+ lines of auditable source no transitive CVEs possible
02
🏗️

You work on production systems, not demo projects

HBForge isn't a framework built to showcase ideas. It powers HyperBridge Digital's own internal products — live systems under real load, with real clients, real audits, and real consequences. When a guild engineer integrates HBForge, they're using the same stack the team that built it uses every day. There's no "works in theory, breaks in production" gap. Every API surface, every edge case, every performance decision was made under production pressure — not in a greenfield demo.

used in HB production daily real enterprise clients real security audits passed
03
📐

Your ideas become real framework features — with your name on them

Most open-source contributions disappear into PR queues and never ship. In the guild, an accepted RFC means the T0 team implements your capability request in the next release cycle. Your name appears in the public changelog — permanently. This isn't a contributor credit buried in a README. It's authorship on a production framework used by engineers across India and enterprise clients globally. One good RFC is worth more on a CV than fifty merged PRs to a project no one uses.

credited in public changelog T0 implements, you're cited monthly RFC windows
04
🌐

You get early access to the Web7 stack before it goes public

Web7-L6 is the next generation of the web protocol stack — intent-first APIs, cryptographically attested outcomes, decentralised identity, zero-knowledge ML proofs, and L0 settlement. HBForge is the only framework that implements this stack today with 30/30 conformance tests passing. Guild members use these capabilities in production before any public release. By the time the ecosystem catches up to Web7, guild engineers will have 12–18 months of production experience that no one else has.

Web7-L6 AAA · 30/30 ZK-ML + PoO + DID 12–18 months ahead of public
05
🧠

You raise your own bar — permanently

The guild's quality standards are not a checklist to get through. They're a way of thinking that changes how you write code outside HBForge too. Engineers who've worked in the guild report that they can no longer write a function without asking "does this have hidden side effects?" or accept a dependency without asking "do I need this, or do I need what it does?". The zero-dependency discipline, the named-exports architecture, the explicit error handling, the conformance testing mindset — these compound. You leave the guild a fundamentally better engineer than you entered it.

production-grade discipline one mental model, 75 modules standards that compound

The bar every developer must clear.

These are not aspirational guidelines. They are enforced gates. Guild members are expected to maintain them in any integration, RFC, or production deployment that touches HBForge.

0
External dependencies added
Every integration built on HBForge must remain dependency-free within the HBForge layer. You can have deps in your app — not in anything that wraps or extends the framework.
30/30
Web7-L6 conformance tests
Any module or extension must pass all 30 conformance tests across 12 categories before it can be considered production-ready. Grade AAA is the only acceptable baseline.
100%
Auditable, readable source
No minification in source. No obfuscation. No generated code without a visible generator. Every line of HBForge must be readable by a developer who didn't write it.
Code Quality — Required
  • Pure functions wherever state is not needed — no hidden side effects
  • Named exports only — no default exports (breakage vector in tree-shaking)
  • Explicit error types — never throw raw strings or generic Error()
  • JSDoc on every public API surface — type, param, return, example
  • Consistent naming with existing module conventions (camelCase, PascalType)
  • No console.log in library code — use forge/notify or forge/trace
  • Every async path has explicit error handling — no silent catch blocks
Architecture — Required
  • Tree-shakeable — every export is independently importable
  • No circular dependencies between modules
  • Browser + Node conditional exports where the module touches both runtimes
  • All crypto and binary ops use forge/data or Node built-ins — never third-party
  • Shared primitives go in _internal/ — never duplicated across modules
  • Semver-safe — no breaking API changes without major version bump
  • Bundle size documented in PR RFC — no unexplained growth over 5%
Testing — Required
  • Unit tests using forge/test — no external test runners
  • Every public API must have at least one happy-path + one error-path test
  • Edge cases documented inline — out-of-range input, concurrent access, empty state
  • Conformance suite must pass locally before RFC is submitted
  • Integration tests for any module that touches forge/data or forge/auth
  • No mocking of internal HBForge APIs — test with real instances
Security — Required
  • No eval(), Function(), or dynamic script injection anywhere
  • All user-supplied input treated as untrusted — sanitised before use
  • Cryptographic operations: AES-GCM or ChaCha20 minimum, no MD5/SHA1 for secrets
  • JWT claims validated strictly — exp, iss, aud all checked
  • No secrets, tokens, or credentials in source — use env or forge/consent
  • All HTTP calls default to HTTPS — no plaintext fallback option
  • Side-channel resistant comparisons for sensitive equality checks
Automatic Disqualifiers
  • Any external npm dependency introduced without explicit T0 approval
  • Code that fails the 30/30 conformance baseline
  • Breaking changes to a stable public API without version bump
  • Copied or adapted code from other frameworks without clear attribution
  • AI-generated code submitted without human review and full comprehension
  • Dead code, commented-out blocks, or TODO/FIXME in shipped modules
  • Benchmarks not provided for any performance-sensitive change
Grounds for Guild Removal
  • Sharing access credentials, preview builds, or source with non-members
  • Reverse-engineering or forking HBForge without T0 written consent
  • Submitting RFCs that misrepresent production use-cases or benchmarks
  • Public disclosure of unreleased features without explicit approval
  • Three consecutive months of inactivity without prior notice
  • Conduct inconsistent with HyperBridge Digital's professional standards

No pull requests. Only RFCs.

Guild members don't push code to HBForge. They submit structured capability requests. The T0 team evaluates, decides, and implements. This is how the framework stays coherent.

1
Identify a real production gap
RFCs must describe a problem you have hit in a real production deployment — not a hypothetical, not a feature request based on another framework. Include the exact error, the workaround you used, and why the workaround is insufficient. No production evidence = RFC closed immediately.
Guild Member
2
Submit via the RFC form (monthly window)
RFCs are accepted in a structured 7-day window each month. Required sections: Problem (with reproduction), Proposed API surface (exact method signatures), Usage example (real code from your codebase), Performance envelope (estimated size + latency impact), Alternatives considered. Incomplete RFCs are not reviewed.
Guild Member
3
T0 review — fit, philosophy, and cost
The T0 team evaluates against three criteria: (1) Does it fit the zero-dependency constraint? (2) Does the proposed API surface feel like HBForge — consistent naming, composable, tree-shakeable? (3) Is the bundle cost justified by the capability? Most RFCs are declined at this stage. A decline is not a rejection of you — it is a commitment to quality over completeness.
T0 Review
4
Approved RFCs enter the implementation queue
If approved, the RFC is assigned to a T0 engineer. The submitting guild member is kept in the loop and may be asked questions during implementation — but does not write the code. This ensures the implementation meets HBForge's internal standards and is backed by the team that owns the codebase.
Approved HB Team Implements
5
Shipped — credited in changelog
Accepted RFCs are shipped in the next release cycle. The originating guild member is credited by name in the public changelog. T1 partners also receive a private note on the implementation decisions and any limitations. This is how you build a track record in the guild.
Shipped to Guild First

Be honest before you apply.

The guild application takes time to review. Don't waste yours or ours if any of the following apply.

You want to contribute codeYou want to add features, fix bugs, or own a module. That's the T0 team's job. Guild members influence the roadmap — they don't write the framework.
You want an open-source alternativeHBForge is not and will not be open source. The source is readable to T1 partners and selective T2 members under NDA. If you need an MIT-licensed framework, use something else.
You're evaluating frameworks for a side projectGuild access is for engineers running production workloads. If you don't have a live system in mind, your application will be deprioritised behind those who do.
You can't explain why zero dependencies mattersIt's not a constraint for its own sake. If you don't understand the security, reliability, and determinism arguments, you'll fight the framework more than you use it.
You want to reverse-engineer and forkApplications include a lightweight NDA. Any attempt to clone, fork, or republish HBForge source — even partial — results in immediate removal and legal action.
You want free enterprise supportPreview access is not free enterprise support. The guild channel is async and community-first. Dedicated SLA support requires a T1 enterprise contract.

npm install @hyperbridge/forge

Once your guild token is issued, two lines in .npmrc and you're installing from our private registry — no public npm involved.

01 Add registry + token to .npmrc
# .npmrc (project root or ~/.npmrc)
@hyperbridge:registry=https://registry.hbforge.dev
//registry.hbforge.dev/:_authToken=hbf_t2_<your-token>
02 Install — works exactly like any npm package
# Install the full framework
npm install @hyperbridge/forge

# Or specific subpath imports (tree-shakeable)
import { signal, computed } from '@hyperbridge/forge/client'
import { ForgeSearch } from '@hyperbridge/forge/search'
import { conform } from '@hyperbridge/forge/conformance'
03 Verify your identity anytime
npm whoami --registry https://registry.hbforge.dev
# → your@email.com (tier: t2)

Registry hosted at registry.hbforge.dev · Powered by Cloudflare Workers + R2 · Zero third-party infra

One email. Manual review.
No shortcuts.

Send a brief introduction: who you are, what you're building, why zero dependencies matters to you, and what production gap you think HBForge can close. Applications without a clear production use-case are declined without reply.

Applications are reviewed manually within 5–10 business days. If approved, you'll receive a signed access agreement and scoped npm token. If declined, you'll receive a one-line reason — no negotiation.