BEP-127 establishes the core architecture of the Greenfield storage network, a BNB Chain ecosystem component designed for decentralized data management. The specification formally defines the network's three principal roles: Storage Providers (SPs), who commit storage capacity and serve data; Validators, who secure the Greenfield blockchain via a Proof-of-Stake consensus mechanism and verify data integrity; and Users, who interact with the network to store and access data. This document serves as the canonical reference for the system's trust model, separating the control plane (on-chain metadata and payments) from the data plane (off-chain storage and retrieval).
Protocols
BEP-127 Greenfield Core Specification
Foundational specification for the Greenfield decentralized storage network, defining the roles of Storage Providers, Validators, and the consensus mechanism governing data integrity, payment channels, and cross-chain communication with BSC.
introduction
GREENFIELD CORE SPECIFICATION
What BEP-127 Defines
The foundational specification for the Greenfield decentralized storage network, defining its actors, consensus mechanism, and economic model.
Operationally, BEP-127 details the economic loop that governs data integrity. It specifies how users create payment streams to Storage Providers, how Validators challenge SPs to prove data availability using a Proof-of-Challenge mechanism, and how non-compliant SPs are slashed. This creates a cryptographically enforced service-level agreement where data redundancy and availability are continuously verified rather than assumed. For builders, the specification outlines the fundamental data structures—buckets, objects, and groups—and the permission model that controls access, making it the basis for all Greenfield-native application development.
For infrastructure operators and integration teams, this specification is the starting point for assessing operational risk and implementation requirements. Running a Storage Provider involves not just serving files but correctly managing the payment channel lifecycle and responding to integrity challenges to avoid slashing. Validators must run a modified Tendermint-based client and participate in the challenge game. Chainscore Labs can assess SP and validator operational readiness, review payment channel security, and help dApp developers align their architecture with the core specification's trust and permission model.
GREENFIELD CORE PROTOCOL ROLES AND FLOWS
Specification Snapshot
A structured breakdown of the core actors, economic flows, and operational requirements defined in the Greenfield Core Specification for storage providers, validators, and dApp developers.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Storage Provider (SP) Role | SPs must register on-chain, deposit BNB as a service stake, and respond to data integrity challenges. The specification defines the exact staking, slashing, and proof-of-storage submission logic. | Storage Providers, Delegators | Review staking economics and slashing conditions. Implement the challenge-response and proof-of-storage submission loop as defined in the spec. |
Validator Role | Greenfield validators use a Tendermint-based consensus to secure the ledger and verify data availability. They participate in SP staking governance and slashing execution. | Validator Operators, Staking Providers | Ensure validator client configuration matches the consensus parameters. Monitor governance votes related to SP slashing and staking parameter changes. |
Payment Channels | Users establish off-chain payment channels with SPs for streaming data operations. The spec defines the lifecycle for creating, settling, and force-closing these channels on-chain. | dApp Developers, Wallet Providers, SPs | Implement the payment channel lifecycle correctly, including dispute windows and force-close logic. Audit channel state transitions for fund safety. |
Data Integrity | The spec defines a challenge mechanism where anyone can verify that an SP stores data correctly. Failed challenges result in slashing the SP's stake. | Storage Providers, Data Availability Monitors | Implement the proof-of-challenge verification logic. SPs must maintain data redundancy to avoid accidental slashing from transient errors. |
Cross-Chain Communication | The specification defines the primitives for the BSC-Greenfield bridge, including the locking and mirroring of BEP-20 tokens for use as payment on Greenfield. | Bridge Operators, Cross-Chain dApp Developers | Verify the bridge relayer implementation against the canonical message format. Monitor for replay risks and finality assumptions between the two chains. |
Resource Bucket and Object Model | Defines the on-chain representation of storage buckets and objects, including ownership, permissions, and billing policies. | dApp Developers, Indexers, Data Analytics Teams | Model application data structures against the canonical bucket/object hierarchy. Ensure permission policies are enforced client-side before submitting on-chain transactions. |
Gas and Fee Mechanics | Operations on Greenfield incur gas fees paid in BNB. The spec defines the gas schedule for storage operations, which differs from standard BSC EVM execution. | dApp Developers, Wallet Providers, SPs | Calculate accurate gas estimates for storage operations. Wallets must display Greenfield-specific fee breakdowns to users before signing. |
technical-context
GREENFIELD CORE SPECIFICATION
Architectural Model and Consensus
Defines the tripartite architecture of Greenfield, establishing the distinct roles, economic incentives, and consensus mechanisms for Storage Providers, Validators, and users.
BEP-127 establishes the foundational architectural model for the Greenfield decentralized storage network, which is built on a tripartite system of Storage Providers (SPs), Validators, and users. Unlike monolithic storage chains, Greenfield separates concerns: SPs are responsible for storing actual object data and serving it to users, while Validators form a consensus network based on Tendermint (CometBFT) to secure the Greenfield blockchain ledger. This ledger does not store object data itself but holds critical metadata, including bucket and object access control policies, SP service-level agreements, and the cryptographic proofs that underpin data integrity challenges.
The economic security of the system is enforced through a Proof-of-Stake consensus mechanism operated by the Validator set, which collectively manages the payment and settlement layer. Users pay SPs for storage and bandwidth via off-chain payment channels, but the accounting, fund locking, and final settlement occur on-chain through the Validator-verified ledger. This architecture creates a specific trust model: users must trust SPs for data availability and service, but they can verify the integrity of that data and the correct execution of payment settlements by monitoring the Greenfield blockchain, which is secured by the Validator set's stake.
For operators and builders, this model introduces distinct operational and security considerations. Storage Providers must manage both their data-serving infrastructure and their on-chain staking and reputation, as Validators can slash SPs for provable data loss or service failures. Validators, in turn, must run a full Greenfield node and participate in the Tendermint consensus, bearing responsibility for the correctness of the metadata ledger. Integration teams building cross-chain applications between BSC and Greenfield must account for this dual-layer architecture, where asset mirroring and permission policies are enforced by the Validator consensus, not by the SPs directly. Chainscore Labs can assess the security of SP staking operations, review Validator configurations for consensus safety, and audit the integration logic that bridges BSC smart contracts with Greenfield's metadata ledger.
IMPACT BY ACTOR
Who Is Affected
Storage Providers
SPs are the most operationally impacted actors. They must implement the core protocol for storing object data, managing redundancy via erasure coding, and responding to data integrity challenges. Failure to comply with the proof-of-challenge mechanism results in slashing of staked BNB.
Operators need to maintain high-availability gRPC endpoints for upload/download traffic and continuously monitor their challenge success rate. Payment settlement occurs via payment channels with users, requiring SPs to manage off-chain state and submit on-chain settlements correctly. Teams should audit their operational playbooks for challenge response, proof generation, and payment channel closure before mainnet participation.
implementation-impact
GREENFIELD CORE SPECIFICATION
Key Implementation Impact Areas
The BEP-127 specification defines the foundational roles, consensus rules, and payment channels for the Greenfield decentralized storage network. The following areas require immediate operational and integration attention from storage providers, validators, and dApp builders.
01
Storage Provider Operational Model
BEP-127 formalizes the Storage Provider (SP) role, requiring operators to stake BNB, register on-chain, and maintain data availability. SPs must implement the core specification's data redundancy, proof-of-challenge, and repair logic. Teams running SP infrastructure should audit their operational playbooks against the canonical spec to ensure compliance with slashing conditions and service-level agreements defined at the protocol layer.
02
Validator Integrity and Data Availability
Greenfield validators do more than consensus; they verify data availability challenges and adjudicate slashing for non-compliant Storage Providers. This dual role creates a unique security dependency. Validator operators must ensure their infrastructure can process data availability proofs and challenge transactions without introducing latency that could stall the network or cause wrongful slashing.
03
Payment Channel Lifecycle Management
The specification defines off-chain payment channels for streaming payments between users and SPs. Implementers must correctly handle channel creation, settlement, and forced closure logic. A failure to monitor channel state or respond to disputes within the challenge window can result in irreversible fund loss. Wallets and dApps integrating Greenfield storage must build robust channel monitoring and settlement automation.
04
Cross-Chain Asset Reconciliation
BEP-127 establishes the core logic for locking BNB on BSC and minting it on Greenfield to pay for storage. Exchanges, custodians, and bridge operators must reconcile the native Greenfield BNB supply with locked BSC assets. Integration teams should verify their accounting systems can track the bidirectional flow and handle the unbundling process when assets return to BSC.
05
dApp Integration and Access Control
Applications building on Greenfield must align their bucket and object permissioning logic with the core specification's resource model. Incorrectly implementing the account, group, or role-based access controls defined in the spec can lead to private data exposure or unauthorized storage modifications. A specification-level review of the integration layer is critical before mainnet deployment.
GREENFIELD CORE PROTOCOL TRUST AND FAILURE MODES
Specification-Level Risk Analysis
Identifies the core trust assumptions, failure modes, and operational risks embedded in the BEP-127 specification for Storage Providers, Validators, and payment channels. This analysis helps operators and integrators understand where the protocol relies on honest behavior, economic incentives, or external verification, and what happens when those assumptions break.
| Risk Area | Failure Mode | Affected Actors | Mitigation and Action |
|---|---|---|---|
Storage Proof (PoS) Integrity | Storage Providers (SPs) fail to generate valid proofs for stored data, or proofs are accepted despite data being unavailable or corrupted. | Storage Providers, Greenfield Validators, dApp Developers, Users | SPs must monitor proof generation pipelines. Validators must verify proof challenges rigorously. dApps should implement client-side data verification. Chainscore can review SP proof-generation logic and validator challenge-verification implementations. |
Payment Channel Liveness | A payment channel party goes offline, preventing settlement. The forced-settlement timelock is too short for honest parties to respond or too long, locking funds. | Storage Providers, Users, Wallet Providers | Wallets must monitor channel state and support forced settlement. SPs need automated settlement responders. Review timelock parameters against network congestion scenarios. Chainscore can assess payment channel lifecycle management and settlement security. |
Validator Collusion in Data Integrity | A supermajority of validators colludes to approve false data availability proofs, undermining the storage network's core security guarantee. | Users, dApp Developers, Storage Providers | Monitor validator voting power distribution and slashing execution. dApps should verify data against multiple SPs. Chainscore can design monitoring for validator quorum behavior and slashing event verification. |
SP Liveness and Data Retrieval | An SP stops serving retrieval requests for stored objects, effectively holding user data hostage despite on-chain proof of storage. | Users, dApp Developers | Users should store data with multiple SPs. dApps must implement retrieval fallback logic. Monitor SP uptime and retrieval success rates. Chainscore can review data redundancy strategies and retrieval failover mechanisms. |
Cross-Chain Asset Locking (BSC-Greenfield) | Assets locked on BSC for Greenfield operations are not correctly mirrored or unlocked due to a bug in the cross-chain communication module. | Bridge Operators, Exchanges, Users | Bridge operators must monitor lock/unlock events on both chains. Exchanges should reconcile cross-chain balances. Chainscore can audit cross-chain message verification and asset reconciliation logic. |
Economic Incentive Misalignment | The cost of storing data is lower than the reward for serving it, or slashing penalties are insufficient to deter malicious SP behavior. | Storage Providers, Validators, Governance Participants | Governance must regularly review storage pricing and slashing parameters. SPs should model long-term profitability. Chainscore can provide economic modeling of incentive structures and parameter-change impact analysis. |
SP Key Compromise | An SP's signing key is compromised, allowing an attacker to sign fraudulent proofs, redirect payments, or delete data. | Storage Providers, Users | SPs must implement hardware security modules and key rotation policies. Users should verify SP identity on-chain. Chainscore can review SP key management and operational security practices. |
Specification Ambiguity in State Transitions | Ambiguities in the core specification lead to divergent implementations of the state machine by different clients, causing a chain halt or state fork. | Validator Operators, Client Developers, Infrastructure Teams | Client teams must maintain rigorous specification conformance test suites. Validators should run multiple client implementations. Chainscore can review client implementations for specification compliance and state transition correctness. |
BEP-127 GREENFIELD READINESS
Storage Provider and Validator Operational Checklist
A practical readiness checklist for Storage Providers (SPs) and Validators preparing to operate under the BEP-127 Greenfield Core Specification. This guide focuses on verifying operational alignment with the protocol's consensus, data integrity, and payment channel mechanics.
Confirm that your SP is correctly registered on the Greenfield blockchain and that your service endpoint is discoverable.
- What to check: Verify your SP's on-chain registration transaction, including the staked BNB amount, operator address, and publicly advertised endpoint (IP/domain).
- Why it matters: An incorrect or unreachable endpoint prevents users from uploading data or accessing stored objects, leading to failed requests and potential slashing for poor Quality of Service (QoS).
- Readiness signal: A successful
QueryStorageProviderInfotransaction returns your correct SP metadata and the endpoint responds to a health-check ping from a Greenfield client.
resource-links
BEP-127 GREENFIELD CORE SPECIFICATION
Canonical Resources
Use these primary sources to validate BEP-127 assumptions, track Greenfield implementation behavior, and prepare storage, validator, wallet, and dApp integrations for specification-aligned operation.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
OPERATIONAL AND INTEGRATION FAQ
Frequently Asked Questions
Common questions from validators, storage providers, and developers integrating with the Greenfield core specification.
The Greenfield core specification defines three primary roles, each with distinct economic incentives and operational requirements:
- Storage Providers (SPs): Responsible for storing user data, responding to challenges, and managing payment channels. They must maintain high uptime, sufficient bandwidth, and provable data integrity.
- Validators: Secure the Greenfield blockchain via a Tendermint-based consensus mechanism. They validate storage proofs, manage the SP set, and uphold the network's economic security.
- Users: Interact with the network to create buckets, upload objects, and set access permissions. They pay fees in BNB through a stream-based payment channel mechanism.
Understanding these roles is critical for designing secure off-chain authentication flows and on-chain challenge mechanisms.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.