BridgTime Whitepaper
BRTM Token Utility — feature access & operations bonding
BRTM is a live utility token used for feature access, operations bonding (quality assurance), and limited input on operating parameters. It is not equity or debt and is not designed to provide profit participation, dividends, interest, redemption rights, or any guaranteed price outcome. Holding or locking BRTM, by itself, does not generate monetary benefits.
4.1 Purpose & Scope
• Access: grants permissions or priority to use network features such as dashboards, APIs, and reports. Benefits are limited to non-monetary convenience, including higher rate limits, processing priority, or access to additional tooling.
• Operations bonding: provides conditional quality bonding for roles such as oracle operators, validators, indexers, and auditors. Compensation is paid only as predefined service fees or rewards for completed and validated work; mere holding of BRTM does not yield fees.
• Governance (advisory/limited): allows non-binding input or limited execution on operating parameters (for example disclosure scope, rating formulas, SLAs/SLOs, alert thresholds). It does not cover financial decisions such as profit distribution, listings, or market-making.
4.2 Payment & Pricing Principles
• Products and services are priced and charged primarily in fiat currency or stablecoins.
• BRTM is not intended to function as a general means of payment or store of value. It may be linked to non-monetary conveniences such as processing priority, usage credits, or sandbox access.
• Holding or locking BRTM alone does not generate interest, dividends, rewards, cashback, or rebates.
4.3 Operations Bonding & Quality Assurance
• Fees or incentives are paid only for work that meets role-specific minimum bonding requirements and key performance indicators such as availability, latency, accuracy, and integrity.
• False, delayed, negligent, abusive, or malicious behavior may lead to slashing of bonded BRTM and suspension or removal of network roles.
• As network usage grows, certain roles may require higher bonded amounts (for example based on the volume of RVAs handled or tenants served), which can temporarily reduce effective liquid supply during periods of high usage.
4.4 Governance Boundaries
• Scope: operating parameters, technical configuration, data disclosure policies, and related non-financial matters.
• Exclusions: finance, profit distribution, dividends, price, listings, liquidity management, market-making, and capital allocation.
• Process: proposals typically follow a simple flow (propose → review → vote → timelock → limited execution or advisory outcome). The project and relevant entities retain discretion where legal, regulatory, or security considerations apply.
Usage → Fees → Treasury → Incentives / Buyback
4.5 Notes
• Whether BRTM is held, staked, or used has no direct effect on settlement flows, receipt of funds, or prepayment decisions for receivables.
• The project does not guarantee or arrange any specific exchange listing, liquidity level, price path, or trading volume for BRTM.
4.6 Notice
The descriptions above summarize the current design of the token utility. As BridgTime evolves, specific parameters and role requirements may be refined through transparent updates and governance where appropriate.
5. Tokenomics (Allocation & Operations)
5.1 Token Overview (Role)
BRTM is the utility token of the BridgTime network. Its main roles are:
① Access and usage credits for dashboards, RVA issuance and lookup, oracle feeds, and related tools,
② Operations bonding and staking for oracle, validation, indexing, audit participation, and quality assurance,
③ Governance over selected operating parameters within the non-financial scope.
BRTM does not grant equity, debt, revenue share, profit participation, or redemption rights.
5.2 Network & Issuance (On-chain Status)
• Chain: Base
• Standard: ERC-20 (18 decimals)
• Total supply: 1,000,000,000 BRTM
• Contract (Base):
0x7c0f8a1562B89d5D2fBdA2662F22bF80B6Fb58E1
All BRTM tokens are already minted and allocated on-chain into internal wallets that correspond to the distribution buckets summarized in Section 5.3. At the time of writing, roughly one hundred wallets are actively involved in internal RVA-related transactions and experiments on Base. These activities reflect early network usage and testing and are not, by themselves, a public token sale or exchange listing.
5.3 Distribution — 100%
| Bucket | Share | Amount (BRTM) | Purpose (summary) |
|---|---|---|---|
| Sale | 25% | 250,000,000 | Bootstrapping onboarding and liquidity environment |
| Network incentives | 20% | 200,000,000 | Rewards for work performed by network participants |
| Bonding / Insurance pool | 15% | 150,000,000 | Coverage for slashing and operational risks |
| Team / Contributors | 15% | 150,000,000 | Long-term incentives for core development and operations |
| Partners / Ecosystem | 10% | 100,000,000 | PG, ERP, bank and ISV integrations and joint pilots |
| Marketing / Community | 10% | 100,000,000 | Education, awareness, and real usage acceleration |
| DAO / Treasury | 5% | 50,000,000 | Security, research, shared infra, contingency |
The on-chain allocation across internal wallets follows these high-level bucket ranges.
5.4 Bucket-level Plans
Sale — 25%
• Strategic onboarding of parties aligned with real usage, including pilots with PGs, ERPs, banks, and ISVs.
• Limited non-monetary benefits such as service credits or sandbox keys for early technical participants.
• Infrastructure ramp-up: bridges, indexers, RPC endpoints, and public gateways.
• Internal and external testing programs using synthetic data and load tests.
• Any tokens allocated to sale programs that are clearly not needed for those programs can be considered for permanent burn in the future, following governance and legal review rather than new primary sales.
Network incentives — 20%
• Oracle operations: availability and latency targets for signature verification and batch commits.
• Validation and audit: re-verification, anomaly cross-checks, and dispute resolution.
• Data quality: standardized schema signals and delay/missing detection.
• Alerts and signal packs: RVA aggregates, SLA widgets, and operational components.
• Builder programs: SDKs, tools, and integrations that increase real usage.
Bonding / Insurance pool — 15%
• Slashing coverage within a defined policy.
• Re-verification and re-issuance to remediate material errors.
• Incident response: key rotation, spare node spin-up, indexer recovery.
• Security hardening: cryptographic upgrades, disaster recovery exercises, and access control improvements.
Team / Contributors — 15%
• Core development of the RVA registry, dashboards, BFF layers, SDKs, and subgraphs.
• AI and data work: OCR, anomaly detection, risk scoring, explainability, and data cleansing.
• Oracle and infra: batch optimization, Merkle compression, dedupe and retry.
• Standards work: schema proposals, reference implementations, and documentation.
Partners / Ecosystem — 10%
• Connector grants for PG, ERP, and bank integrations.
• Standard adoption through templates, validators, and testing suites.
• ISV marketplace for RVA-powered apps, reporting consoles, and risk dashboards.
• Vertical pilots in sectors such as convenience retail, pharma, franchise, and logistics.
• Early-access programs: fast-track sandbox keys, “RVA Ready” checklists, and compliance starter packs.
Marketing / Community — 10%
• Developer programs: hackathons, grants, sample apps, and dashboard kits.
• Education and documentation: onboarding guides, runbooks, schema and API tutorials.
• Adoption campaigns: webinars, meetups, reference stories, and data packs.
• Community tools: public status pages, metrics boards, CLI and SDK templates.
DAO / Treasury — 5%
• Security audits and bug bounty programs.
• Shared infrastructure such as public subgraphs, indexers, and gateways.
• Research and standards around interoperability and privacy.
• Contingency for pause, resume, or emergency measures where needed.
5.5 Protocol Fees, Buyback and BRTM Flow
BridgTime charges protocol fees for products and services primarily in fiat currency or stablecoins. The current design of the fee flow is:
• Primary fee currency: fees are denominated and collected in fiat or stablecoins, not in BRTM.
• Allocation ceiling: up to 50% of net eligible protocol fees is intended to be available, over time, for on-chain mechanisms that support:
① BRTM buyback and burn,
② staking and network incentive pools, and
③ insurance and incident-response reserves.
• Initial target band: within this ceiling, an aggregate range of roughly 20–40% of net eligible fees is expected to be directed toward buyback and burn and related pools, with exact parameters set by governance and ongoing review.
• Buyback and burn: when active, the protocol or designated entities may periodically acquire BRTM on the open market using a portion of eligible fees and send it to a verifiable burn address, reducing effective circulating supply over time. The timing and size of such operations are not fixed and can be adjusted.
• Staking and incentives: a portion of eligible fees may be routed into pools that reward roles such as oracle operators, validators, indexers, and ecosystem contributors, complementing the pre-allocated network incentive bucket.
• Insurance and incident-response: a portion of eligible fees may support reserves used to address qualified incidents and remediation within a defined policy.
These mechanisms are designed to align protocol usage with long-term token dynamics and network reliability. Parameters may be updated from time to time as the network matures and as legal, regulatory, and security considerations evolve.
5.6 Vesting, Lockups & Release
The vesting and lockup framework is intended to align long-term contributors, early participants, and the broader ecosystem.
Team & Contributors (15%)
• Full lockup during an initial period (for example around eighteen months) after the token generation event.
• Linear vesting over a subsequent multi-year period (for example thirty-six months).
• No vesting acceleration based solely on token price.
Private Sale Portion of the Sale Bucket
• A small fraction (for example up to ten percent of each allocation) may unlock around TGE, with the remainder vesting linearly over roughly twenty-four to thirty-six months.
• Specific lockups and transfer conditions are defined in the respective sale documentation.
Public Sale Portion of the Sale Bucket
• Unlock and transferability parameters are designed primarily to enable participation and access to the network rather than short-term speculation.
• Jurisdictional and eligibility terms are defined in the public sale materials, where applicable.
Partners & Ecosystem (10%)
• Milestone-based unlocks linked to objective adoption metrics, such as deployed connectors, traffic or RVA volume, and completed pilots or certifications.
• Unused partner allocations can remain locked, be repurposed for future ecosystem initiatives, or be considered for burn in the future, following governance and legal review.
Incentive, Bonding, Insurance, DAO & Treasury Buckets
• Released on program schedules (for example by epoch, campaign, or initiative).
• Designed to support network security, reliability, and participation over several years rather than concentrating emissions in the earliest phase.
As BridgTime grows, details of vesting schedules and lockups may be refined and documented in dedicated program or policy materials. Any such updates will aim to keep incentives transparent and aligned with sustainable network development.