White Paper
Real-world assets for productive infrastructure
Architecture overview of bGate Digital — connecting real assets, operating cash flows, and measurable impact through compliant project structures and auditable digital records.
Real assets & legal rights first · Verified performance
Version 2.0 · 1 August 2026
Draft for discussion — not an offering document
This page summarizes the architecture white paper for informational reading. It is not an offer to sell tokens or securities. Project-specific financial terms belong in separate offering documents. For the full legal notice and principal risks, see Compliance.
Contents
Architecture chapters
Project-specific financial terms belong in separate offering documents and supplements — not in this architecture summary.
- 01Executive Summary
- 02The Infrastructure Financing Problem
- 03Real-World Assets and Tokenization
- 04The bGate Vision and Design Principles
- 05Two-Layer Token Architecture
- 06Legal and Operating Architecture
- 07Project Qualification and Asset Onboarding
- 08Project Financing Structures
- 09Cash Management and Payment Waterfall
- 10Technology, Data, and Reporting Architecture
- 11Broadgate Energy as an Initial Infrastructure Use Case
- 12The bGate Participant Ecosystem
- 13Governance and Control Framework
- 14Compliance and Regulatory Framework
- 15Ecosystem Token Economic Design
- 16Secondary Transfers and Liquidity
- 17Environmental Integrity
- 18Implementation Roadmap
- 19Principal Risks
- 20Conclusion
Chapter 01
Executive Summary
Broadgate Energy is an engineering firm focused on manufacturing and operations of waste-to-energy plants using advanced pyrolysis technology — converting mixed waste and biomass into fuels and by-products in a more sustainable manner. Related pathways include green ammonia, biomethanol, gas purification, ORC power generation, electrolysers for green hydrogen, and related systems.
bGate Digital is designed as a digital capital and commerce layer for productive real-world assets. Its purpose is to connect infrastructure owners, operators, manufacturers, investors, suppliers, purchasers, communities, and service providers through legally enforceable project structures and auditable digital records.
The model begins with infrastructure that creates measurable economic output. Each financed project is placed in a legally defined project company or special-purpose vehicle (SPV) that owns or controls the relevant assets, contracts, revenues, and obligations.
bGate’s long-term objective is not to make physical assets disappear into a digital token. It is to make the relationships around those assets more transparent, standardized, accountable, and accessible — while preserving the legal protections required in the physical economy. No return is guaranteed.
Core architecture decision
The bGate Ecosystem Token is intended for commerce, access, services, and participant rewards. Plant financing is conducted through separate project-specific RWA securities issued under applicable securities laws. This separation lets legal rights, risks, and performance be evaluated project by project.
Chapter 02
The Infrastructure Financing Problem
Productive infrastructure often falls into a financing gap: projects may be too small or specialized for large funds, too early for conventional project finance, and too complex for ordinary equipment lenders. Commercially promising assets can remain idle while communities continue paying for waste disposal, imported energy, and centralized supply chains.
The gap is not only a shortage of capital — it is also a shortage of standardized evidence. Investors need clear answers on title, permits, technology performance, feedstock, offtake, construction risk, insurance, operating control, cash flow, and remedies if a project underperforms.
bGate is intended to organize these records around consistent project architecture and a shared reporting standard: qualify the project first, document legal rights second, and use blockchain only where it adds traceability, automation, or market access — never as a substitute for project quality, regulation, or investor protection.
Chapter 03
Real-World Assets and Tokenization
Real-world assets (RWAs) are tangible or financial assets whose ownership, repayment rights, revenue rights, access rights, or other economic interests can be represented digitally — for example real estate, equipment, energy facilities, commodities, receivables, bonds, and environmental instruments.
Tokenization creates a digital representation of an asset or instrument using distributed-ledger technology. Legal effect depends on structure: a token may be the security itself, may record an entitlement maintained by an issuer or transfer agent, or may only notify an off-chain register. Token format does not change the application of securities laws.
bGate therefore uses the term asset-linked rather than automatically asset-backed. A project security is backed only to the extent that definitive documents create enforceable rights to identified assets, cash flows, guarantees, reserves, or collateral.
| Benefit | Practical meaning | Important limitation |
|---|---|---|
| Fractional participation | Financing interests can be divided into standardized units. | Eligibility, minimums, and transfer restrictions still apply. |
| Auditability | Ownership and approved transfers can be recorded consistently. | Bad source data remains bad data; verification is still required. |
| Automation | Payments, notices, and compliance rules may be encoded. | Smart contracts cannot resolve every legal or operating dispute. |
| Potential liquidity | Authorized holders may transfer through permitted channels. | No market or buyer is guaranteed. |
| Lower friction | Standardized records can reduce reconciliation overhead. | Regulated intermediaries, auditors, insurers, and counsel remain necessary. |
Chapter 04
The bGate Vision and Design Principles
bGate’s vision is an independent, transparent ecosystem where capital can connect to productive infrastructure and measurable real-world results — distributing opportunity more broadly while keeping project economics anchored in operating assets rather than token speculation.
- Real assets first — verified ownership or control of identifiable equipment, property, contracts, or receivables.
- Legal rights first — token rights defined in enforceable documents and supported by a recognized holder register.
- Verified performance first — operating data, bank records, production reports, and third-party tests support reporting.
- Functional separation — commerce functions separated from investment functions and environmental instruments.
- Project-by-project accountability — each SPV has its own assets, liabilities, offering terms, accounts, and reporting.
- Local value — retain jobs, energy value, waste savings, and economic activity in communities when commercially practical.
- Measured claims — avoid unsupported statements such as guaranteed liquidity, zero emissions, risk-free yield, or automatic ownership.
Chapter 05
Two-Layer Token Architecture
The architecture separates a general ecosystem instrument from project financing instruments. They may share compatible technical infrastructure, but they have different issuers, rights, compliance rules, and economic purposes.
The ecosystem token will not automatically convert into a project security, and a project security will not automatically convert into the ecosystem token. Any exchange between them must be a separately permitted transaction with pricing, identity, suitability, and legal controls.
| Feature | Ecosystem Token | Project-Specific RWA Security |
|---|---|---|
| Primary purpose | Payments, access, services, rewards, participation. | Finance a defined asset through documented debt, equity, or revenue participation. |
| Issuer | A designated bGate ecosystem entity, after legal review. | The applicable project SPV or financing issuer. |
| Economic rights | No plant equity, project income, or promised yield by default. | Only the rights stated in offering and governing documents. |
| Transferability | Subject to platform rules and applicable law. | Whitelisted and restricted by securities law and offering terms. |
Chapter 06
Legal and Operating Architecture
Each project must be legally understandable without the blockchain. The digital layer records and administers rights; it does not replace the entity, contracts, bank accounts, or remedies that make those rights enforceable.
The preferred model is issuer-sponsored tokenization. The project issuer or its authorized agent maintains the master securityholder record and ensures that an approved on-chain transfer corresponds to a legally effective transfer. A purely synthetic token that only tracks an asset’s value without rights against the asset owner is not the preferred bGate project model.
| Participant | Core responsibility | Required separation |
|---|---|---|
| bGate platform entity | Technology, onboarding standards, reporting, ecosystem administration. | Does not commingle project assets or imply ownership of every project. |
| Project SPV | Owns or controls project assets, contracts, revenues, and liabilities. | Separate books, accounts, governance, and disclosures. |
| Operating company | Runs the facility, maintains permits, performs commercial contracts. | Obligations documented in O&M and project agreements. |
| Investors / security holders | Provide capital under applicable offering terms. | Rights limited to definitive documents — not this paper. |
| Regulated & assurance providers | KYC/AML, custody, transfer agency, banking, audit, insurance, verification. | Engaged as required by jurisdiction and structure. |
Chapter 07
Project Qualification and Asset Onboarding
A project is not eligible merely because it can be described as green, innovative, or tokenizable. It must pass a gated review designed to expose the same weaknesses conventional lenders and infrastructure investors would examine.
Capital should be released against documented milestones — not solely against a token sale. Escrow or controlled-account procedures should link disbursements to title, shipping, delivery, installation, testing, permitting, insurance, and commissioning evidence.
- Sponsor and ownership review
- Asset review (title, condition, valuation, IP, security interests)
- Technical review (throughput, yield, energy balance, independent tests)
- Site and permitting review
- Commercial review (feedstock, offtake, counterparties)
- Financial review (budget, sensitivities, reserves, tax)
- Risk transfer / insurance package
- Offering readiness (disclosures, custody, transfer restrictions, reporting)
Chapter 08
Project Financing Structures
bGate is intended to support multiple conventional financing rights in tokenized form. The token is the record and transfer mechanism; the underlying instrument determines the economics.
No single project-financing form is endorsed by this white paper. Issuer, rights, priority, collateral, dilution, distributions, term, and remedies must be selected project by project after legal, financial, technical, tax, and commercial review.
| Structure | Holder right | Key risks |
|---|---|---|
| Secured equipment note | Scheduled principal and interest supported by collateral. | Recovery value, enforcement, downtime, priority. |
| Project debt | Contractual debt service from project cash flow. | Construction, ramp-up, coverage, refinancing. |
| Project equity | Residual ownership, distributions, voting, and exit rights as documented. | Dilution, no distribution, governance, total loss. |
| Revenue participation | Defined percentage of specified revenues for a term or cap. | Revenue definition, margin pressure, classification, monitoring. |
Chapter 09
Cash Management and Payment Waterfall
Each project should operate through a controlled bank account structure. Token holders should never depend on an informal promise that project revenue will later be allocated fairly. The waterfall must be written into the project’s governing and financing documents.
Smart contracts may automate notices and distribution calculations after verified cash is available, but they should not transfer funds based solely on unverified production data. Bank balances, approved invoices, and the off-chain accounting ledger remain critical control records.
Revenue from one project must not be used to imply support for another project unless a legally documented portfolio or cross-collateralization structure expressly permits it and discloses the resulting risks.
- Gross receipts enter the designated collection account
- Taxes, statutory charges, bank fees, and senior obligations paid as documented
- Approved operating expenses to keep the plant safe, permitted, insured, and productive
- Maintenance, working capital, debt-service, and other required reserves replenished
- Senior debt service paid by contractual priority
- Other security distributions paid by class and priority
- Residual cash to equity or retained for expansion, subject to covenants and approvals
Chapter 10
Technology, Data, and Reporting Architecture
The proposed platform combines an on-chain record with off-chain identity, legal, banking, and operating systems. Personal information and confidential commercial documents should remain off-chain, while cryptographic proofs or document hashes can establish that an approved version existed at a specific time.
Blockchain selection remains open. Criteria should include security, cost, institutional custody, permissioned transfer support, smart-contract maturity, privacy, interoperability, environmental footprint, and long-term maintainability. Technology neutrality prevents legal rights from depending on the popularity of one network.
- Identity layer — KYC/AML, sanctions screening, eligibility, wallet association
- Asset layer — title, security filings, valuations, contracts, insurance
- Token layer — authorized issuance, holding, transfer, pause, recovery, distributions
- Register layer — legally recognized holder record reconciled with on-chain balances
- Data layer — plant systems, labs, meters, invoices, bank records, auditors
- Settlement layer — lawful bank, payment, stable-value, or digital-asset channels
Chapter 11
Broadgate Energy as an Initial Infrastructure Use Case
Broadgate electrical pyrolysis illustrates the type of productive asset bGate is intended to evaluate — an electrically heated, oxygen-free conversion process producing condensable liquid fuels, cleaned gas, and solid carbon. Preferred environmental language is closed-loop thermal recycling / advanced pyrolysis with no untreated discharge — not an unqualified claim of zero emissions.
Company-provided operating materials describe continuous operation runs and laboratory certificates for liquid samples. These figures are inputs to diligence, not bGate guarantees. Before financing a commercial project, an independent engineer should verify scale, feedstock, uptime, yield, product quality, energy balance, parasitic consumption, maintenance, emissions, and site replication.
bGate is not dependent on one reactor, one manufacturer, one site, or one revenue stream — although each early transaction must remain narrow enough for participants to understand the exact value chain.
Evidence boundary
A plant should not be admitted merely because another unit has operated. Each project data room must include site-specific permits, land control, feedstock agreements, product offtake, construction status, insurance, financial model, and commissioning plans.
Chapter 12
The bGate Participant Ecosystem
bGate is intended to connect participants who already create or purchase real economic value. The network becomes useful when it reduces friction among them — not when participation depends primarily on token price appreciation.
The bGate Ecosystem Token may eventually support access fees, approved services, participant rewards, data products, settlement, and discounts. These uses must be live, understandable, and legally reviewed before a token is sold or widely distributed.
- Project sponsors and operators
- Equipment and technology providers
- Investors and finance providers
- Feedstock and material suppliers
- Energy, fuel, material, and credit purchasers
- Communities and public bodies
- Auditors, engineers, laboratories, insurers, and counsel
- Merchants and service providers
Chapter 13
Governance and Control Framework
Governance must prevent the platform sponsor, project sponsor, operator, and token treasury from becoming an indistinguishable pool. The platform should publish a governance charter before launch. Project investors should receive separate governance terms for their issuer.
- Separate legal entities, books, bank accounts, contracts, wallets, and statements per project unless consolidation is expressly disclosed
- Written related-party and conflict-of-interest policies
- Board or manager authority matrices for borrowing, sales, issuance, treasury, contracts, and distributions
- Multi-approval controls for digital-asset treasury movement and key access
- Independent verification of material technical milestones and operating data
- Regular financial reporting, covenant reporting, and material-event notices
- Documented incident response, wallet recovery, cybersecurity, and upgrade procedures
- Holder voting only where documents grant a defined voting right — not from token possession alone
Chapter 14
Compliance and Regulatory Framework
bGate should assume from the outset that a project token representing equity, debt, revenue participation, or profit expectation is a regulated security unless qualified counsel concludes otherwise for the relevant facts and jurisdiction. Calling an instrument a utility token, RWA, membership, or digital receipt does not control its legal classification.
In the United States, tokenized securities remain subject to federal securities laws; offers and sales require registration unless an exemption is available. Custody, transfer agency, broker-dealer activity, trading venues, state law, tax, Investment Company Act, and money-transmission rules may also apply.
In the United Kingdom, the financial-promotion regime and evolving authorization framework for cryptoasset activities must be accounted for. Overseas firms serving U.K. consumers may fall within authorization perimeters for relevant activities. Promotions must be fair, clear, and not misleading.
In the European Union, cryptoassets that qualify as financial instruments may fall outside MiCA’s general cryptoasset regime and remain subject to securities and markets law. Classification must be performed before marketing or admission to trading.
This white paper is an architecture document. It must never be used in place of an offering memorandum, prospectus, subscription agreement, note, indenture, security agreement, shareholder agreement, risk factors, or legal opinion.
- Offering route — registration or exemption before solicitation
- KYC/AML and sanctions screening through qualified providers
- Balanced financial promotions with prominent risks
- Legally permitted custody and safeguarding arrangements
- Whitelisted transfers and authorized venues where required
- Sensitive identity data kept off-chain; privacy duties applied
- Issuer and investor tax and accounting analysis per jurisdiction
Chapter 15
Ecosystem Token Economic Design
This revision intentionally does not announce a final supply, public-sale price, exchange listing, or allocation for the bGate Ecosystem Token. Publishing arbitrary tokenomics before legal classification, platform utility, technical design, treasury controls, and demand modeling would create avoidable regulatory and economic risk.
The recommended sequence is to operate the early platform using conventional payment channels and project-specific securities. A separate token issuance addendum may be published only after real consumptive uses exist and counsel has reviewed the design.
Do not use an ecosystem-token presale as the principal means of financing plant construction. Use project-specific securities with project-specific disclosure. Do not guarantee appreciation, floors, or redemption unless a separately regulated and fully documented structure supports the promise.
- Disclosed maximum or clearly governed issuance rule — no undisclosed minting
- Majority of distributable supply reserved for ecosystem use and long-term network purposes
- Transparent long-term vesting for founders, team, advisers, and strategic recipients
- Published treasury authority, approved uses, custody, reporting, and conflict controls
- Utility tied to services and participation that actually exist
Chapter 16
Secondary Transfers and Liquidity
Tokenization can improve transfer administration, but it does not create a market. A holder may be unable to sell a project security for an extended period or at any acceptable price. Every offering must disclose this risk prominently.
Project-security transfers should require approved wallets, identity checks, eligibility confirmation, compliance with holding periods, issuer consent where applicable, and synchronization with the recognized holder register.
The platform should not promise 24/7 liquidity. Even where a technical network operates continuously, market hours, venue access, settlement, pricing, disclosures, buyer demand, lockups, and regulatory restrictions can limit actual trading.
Any issuer repurchase, redemption, refinance, or liquidity facility must be separately funded and documented. DeFi integration is not a launch feature and should be considered only after counsel, custody providers, venues, and project investors approve a compliant structure.
Chapter 17
Environmental Integrity
bGate’s environmental claims must be as disciplined as its financial claims. A project can create local energy and emissions benefits without supporting every possible sustainability statement.
Environmental revenue should enter a project financial model only when eligibility, methodology, ownership, registration, verification, issuance timing, pricing, and buyer access are supportable — and should be separated from base operating revenue in downside analysis unless contracted.
- Use measured baselines and defined system boundaries
- Distinguish avoided emissions, removal credits, renewable attributes, compliance credits, and voluntary credits
- Do not treat a bGate token or project security as a carbon credit unless separately issued and retired under a recognized program
- Prevent double counting when attributes are sold to offtakers, utilities, registries, or investors
- Use qualified third parties for lifecycle analysis, emissions testing, and credit verification
- Replace vague “zero emissions” claims with precise, testable descriptions of controls and discharge pathways
Chapter 18
Implementation Roadmap
bGate should launch through readiness gates rather than a calendar-driven token sale. Each gate produces evidence needed by the next.
The recommended pilot is narrow: one project, one issuer, one instrument, one defined use of proceeds, and one reporting package. A successful pilot creates standards for later projects; an overly broad first launch multiplies legal, technical, and execution risk.
| Gate | Objective | Minimum exit evidence |
|---|---|---|
| Legal architecture | Define entities, jurisdictions, instruments, regulated-service needs. | Counsel-approved structure memo, compliance map, authorities, document list. |
| Pilot project readiness | Select one financeable asset and complete data-room review. | Title, site, permits, budget, feedstock, offtake, insurance, model, independent technical scope. |
| Financing readiness | Prepare the selected project-specific security. | Term sheet, offering documents, escrow, KYC/AML, custody/register, milestone draws. |
| Commissioning & reporting | Deploy capital and verify the physical asset. | Delivery, installation, acceptance tests, permits, insurance, live reporting. |
| Platform MVP | Operate holder records, reporting, notices, controlled distributions. | Security audit, reconciliation, recovery, privacy, service providers. |
| Controlled transfer | Enable legally permitted transfers for eligible holders. | Venue or bilateral process, whitelist, disclosures, register sync. |
| Ecosystem token decision | Determine whether a general token adds real utility. | Live use cases, legal classification, token addendum, treasury charter, technical audit. |
Chapter 19
Principal Risks
Participation in an early-stage infrastructure and digital-asset platform involves substantial risk, including the possibility of total loss. The summary below is not exhaustive and does not replace project-specific risk factors.
Project structures can allocate and mitigate risk but cannot eliminate it. Full category detail — with examples and mitigation directions — is published on the Compliance page.
Read the full risks section
See Compliance → Principal Risks for examples and primary mitigation directions for each category.
Open full risks on Compliance →- Project development
- Technology and operations
- Commercial
- Financial
- Legal and regulatory
- Digital and cyber
- Liquidity and market
- Environmental and reputational
Chapter 20
Conclusion
bGate Digital’s opportunity is larger than launching a coin. It is the opportunity to build a disciplined bridge between capital, real productive assets, local economic participation, and verifiable performance.
The revised architecture gives every instrument one clear pathway: the Ecosystem Token supports commerce and participation; project-specific RWA securities finance defined assets through legally documented rights; environmental instruments remain separately verified; project SPVs preserve accountability; the platform provides common standards, records, controls, and reporting.
This structure does not remove the hard work of infrastructure — it makes that work visible. Permits, feedstock, offtake, engineering, insurance, construction, operations, cash management, and investor protection remain the foundation.
With this approach, bGate can pursue a global RWA ecosystem without confusing community participation with securities ownership, or confusing technical transferability with guaranteed liquidity. That clarity is the basis for trust and responsible scale.
Governing proposition
Qualified assets, documented and approved rights, open access to online data rooms, third-party auditing, and clarity with transparent governance to deliver verifiable performance. Use tokenization to make the resulting system more transparent, efficient, and accessible.
Appendix
Appendix A — Project Data-Room Checklist
A structured diligence checklist covering corporate governance, site/equipment/technical evidence, commercial and regulatory materials, and financial/offering readiness. Full checklist detail is in the downloadable PDF.
Corporate and governance
- Entity formation, good standing, ownership, registers, authority
- Board approvals, related-party disclosures, organization chart
- Litigation, liens, defaults, investigations, insolvency history
Site, equipment, and technical
- Land title/lease, site control, utilities, drawings
- Equipment list, title, warranties, valuation, condition
- Operating data, energy balance, feedstock tests, independent engineer scope
- Installation, commissioning, performance testing plan
Commercial and regulatory
- Permits, environmental approvals, H&S, emissions testing
- Feedstock contracts/LOIs and offtake agreements/LOIs
- Insurance binder and lifecycle policies
Financial and offering
- Project summary, forecast, risk register
- Bank accounts, covenants, security package
- Tax analysis and incentive treatment
- Offering route, KYC/AML, custody, register, transfer controls
Appendix
Appendix B — Defined Terms
Key defined terms used across the architecture paper. Full definitions are in the downloadable PDF.
- Asset-linked
- A digital instrument connected by enforceable documents to identified assets, obligations, cash flows, or rights — not a guarantee of value or recovery.
- bGate Ecosystem Token
- A proposed instrument for approved commerce, access, services, and participation — not a pooled ownership interest in bGate projects by default.
- Project-Specific RWA Security
- A security issued for a defined project or assets to approved participants, with rights established by definitive documents.
- Project SPV
- A special-purpose entity that owns or controls the applicable project assets, contracts, revenues, and liabilities.
- Master Securityholder Record
- The legally recognized record of security ownership maintained by the issuer or authorized agent.
- Whitelisting
- A control that permits a token to be held or transferred only by approved addresses or persons.
Full document
Download the White Paper PDF
Download only — the PDF is not opened or previewed inside the website. Also review Important Notice and Principal Risks on Compliance.