Components of BUK Protocol

The BUK Protocol solution stack

BUK Protocol architecture

The BUK protocol is a collection of smart contracts, Oracles, APIs and SDKs, marketplace indexers for tokenizing, transferring, trading, burning, staking, locking, listing, and indexing of dynamic assets creating tradability and liquidity for them on-chain. The protocol is modularized in such a way that stakeholders can use the entire stack of services or choose a subset of services to use.

Here’s how you can use BUK Protocol’s modules across lifecycle of a dynamic asset.

1. Ingestion Oracles:

   The typical lifecycle of a dynamic asset starts with a producer app holding the inventory of dynamic assets in their databases. These producer apps can be ticketing systems for eventstravel booking apps or points, membership/subscription management systems. The producer apps may be operated by the owners of these assets (hotels, airlines, clubs, event organizers, clubs etc) or by aggregators of the assets (travel portals, event ticketing portals or other technology companies).

   Producer apps such as ticketing apps, booking engines and ERPs shall utilize BUK Protocol’s Oracles to provide a provenance verification before assets can be brought on-chain. These Oracles act as the bridge between producer apps and tokenization smart contracts.

2. Factory Smart Contracts:

   BUK Protocol smart contracts cover the on-chain lifecycle of assets creating and unlocking value latent in these dynamic assets. There are multiple smart contracts available:

   1. Tokenization:

   2. dNFT Contracts:

   3. Treasury Contracts:

   4. Marketplace Contracts:

   5. Interfaces

   Any new dynamic asset shall deploy all or few of these smart contracts. For example, if a event organizer wants their tickets only to be minted as NFTs, but does not permit trading then they will only require Tokenization, NFT and Treasury contracts; if the event organizer wants ticket traded only within their dApp they will also deploy the marketplace contract.

3. Protocol Contracts:

   In addition to Factory contracts, the protocol has its own smart contracts - key among them are Aggregated Marketplace and BUK Treasury contract.

   The Aggregated marketplace contract is a special marketplace contract used to provide a universal cross-asset marketplace for all eligible assets created or managed through the BUK protocol - essentially it maintains a global protocol-level orderbook. All assets where trading is permitted by their producers, shall be listed on the BUK Aggregated Marketplace in addition to their respective marketplaces. Listing on aggregated marketplace can be enabled or disabled by the producer apps through their factory contract configurations.

   The BUK treasury contract’s sole purpose is to manage collection and dissemination of commissions or charges collected by the protocol itself.

   In addition to aggregated marketplace and treasury, deployer contracts and interfaces shall also be a part of the Protocol contracts’ space. These are operational contracts meant to provide enabling or integration functionalities for components of the BUK protocol to inter-operate. Certain contracts shall enable connecting factory contracts with other web3 services as decentralized storage systems, decentralized identity contracts, decentralized social media platforms, DeFi protocols, exchanges etc.

4. Consumer Oracles:

   Consumer Oracles shall be used by primary and resell marketplaces; and will provide access to both tokenized inventory and resold assets on-chain via integrated APIs as well as individual feeds. A core feature of consumer Oracles is to provide access to BUK protocol’s inventory aggregation layer which shall provide cross-market and cross-chain bridging so that consumer dApps do not need to set up their own aggregation methods. Consumer Oracles will also be integrated with other aggregation layers such as CCIP, CCIF, Polygon AggLayer, LayerZero etc.

5. Web2 Integration Oracles:

   Bringing the next billion users to the blockchain requires simplifying onboarding - this may require dApps to integrate their solution with existing Identity systems, payment channels and even existing web2 marketplaces. Web2 integration Oracles provide a mechanism for two-way interchange of data with existing web2 systems.