White Paper



Bullieverse is an Open Metaverse and built on the foundations of Web3.0. We use blockchain technology and NFTs to enable our network participants and community to be self-sovereign. NFTs enable digital property ownership on the internet. Each NFT is distinct or unique, it is indivisible and it is not interchangeable for another.


Non-fungible tokens (NFTs) enabled a whole new dynamic where digital assets can be unique and scarce to create one-of-a-kind digital assets. NFTs are built on a cryptocurrency platform in compliance with Ethereum's ERC-721, ERC-1155 and ERC-1337 token standards. NFTs are units of value that are non-fungible, unique and digitally scarce which cannot be replaced by another equal part or quantity.
Below is the list of NFTs that are widely used in The Bullieverse ecosystem

ERC 721

Our Avatar NFTs are ERC 721 compliant and allow multiple unique items that are minted by deploying a single smart contract to allow interoperability with all the games in the Metaverse. Below is the list of NFT collections that can be used as Avatars in the Metaverse.
  1. 1.
    The first 10,000 genesis collection (COBI) Bull NFTS
  2. 2.
    10,000 Bear NFT collection (Play to Earn rewards)
  3. 3.
    10,000 Cow NFT collection
  4. 4.
    NFT collection that is generated through breeding
  5. 5.
    Land parcels
  6. 6.
    Game portals

ERC 1155

  1. 1.
    In-Game assets
  2. 2.
    Assets minted by creators

Smart Contracts

Contract Address
ERC 721 - 10,000 BULL NFTs
ERC20 - In-Game Utility and DAO Governance Token
Barbearian NFT
ERC 721 - 10,000 Bear NFTs
Solidity contracts for Marketplace
New NFT Collection
ERC 721 - 10,000 NFTs
Q1 2023
Land Sale
ERC 721 - Land Parcels
Q1 2023

Game Engine

We use the Unreal Engine from Epic Games for developing games in our Metaverse. SnowCrash is our in-game creator engine. Bullieverse client can be launched through a browser call after authenticating with MetaMask or any supported wallet provider which loads up a specific developer-created game. This gives SnowCrash an interesting capability: Creators can place portals in our Metaverse Island which lead to other games. Our engine uses in-built Gameplay framework classes thereby leveraging the full potential of the Unreal Engine. The Gameplay Debugger is useful for watching real-time data at runtime, even on clients in networked games using replication. It works in Play In Editor (PIE), Simulate In Editor (SIE), and standalone game sessions, and all of the data is displayed as an overlay on the game viewport. Below is the summary of different layers of the Game engine.
  1. 1.
    Build: It consists of technology that solely processes assets and codes offline for the sake of generating the game build which is an executable. This makes our build process both effective and fast.
  2. 2.
    Networking: This mostly conducts the networking side of the engine, and the scene graph, which is how gameplay-level systems will access most objects and information.
  3. 3.
    Gameplay: This defines the behavior tree that gets used at a high level in the game, such as scripting and AI. This will also include an event messaging system.
  4. 4.
    Tools: These are essentially the tools that will be used to debug and test the gameplay.
  5. 5.
    Core: This is a self-contained layer that provides the underlying foundations for everything including the audio engine and rendering engine. They are like the screws and bearing upon which everything else runs.


The Bullieverse platform architecture is composed of blockchain, AWS-based cloud infrastructure to support our services, IPFS (Interplanetary File System) to store the in-game assets, and any other assets created by the game developers.
When the creator publishes an asset in our market place it will temporarily get stored in S3 buckets, our minter service will deploy the assets onto IPFS and mints an ERC 721 NFT on the Ethereum blockchain using the metadata. This NFT will be transferred to the creator's wallet.
Below is the list of components that consist of the Bullieverse Technical Architecture.
Game clients
The game client searches for existing game sessions, requests matchmaking or starts a new game session by communicating with the GameLift service. The client service makes requests to the GameLift service and in response receives game session information, including connection details, which is relayed back to the game client. The game client uses this information to connect directly to the game server and join the game.
We use our Lambda services to validating of NFT ownership. As shown in the architecture diagram, information from an external service can be passed to your game servers (via a client service and the GameLift service) without going through the game client.
Game servers
Game servers communicate with the GameLift service by using the GameLift Server SDK, exchanging requests to start new game sessions, validating newly connected players, and reporting the status of game sessions, player connections, and available resources. Game clients connect directly to a game server after receiving connection details from the GameLift service.
GameLift service
The GameLift service is the core service that deploys and manages fleets of resources to host the game servers, coordinates how game sessions are placed across your available resources, starts and stops game sessions, and tracks game server health and activity in order to maintain game availability as player traffic fluctuates. Game servers that are deployed onto GameLift fleets use the GameLift Server SDK to maintain communication with the GameLift service to start and stop game sessions, report server health, exchange game and player data as needed, etc.
Smart Contracts
The smart contracts running on the blockchain include our asset smart contracts, ERC 20 tokens used for purchasing assets in our marketplace and ERC 721, ERC 1155 NFT contracts. Our services check for ownership of NFTs and populate the assets in the game session once the user successfully authorizes with the wallet.


Our marketplace relies on the security of the blockchain for the functioning of its smart contracts. We use a multi-signature wallet that uses the gnosis MultiSig wallet backed with five hardware wallets and need 3/5 signers to affect any change to the logic of our smart contract. Our Event tracker AWS lambda functions track the events emitted from the marketplace transactions (smart contracts) and cache them in dynamodb to keep track of ownership and exchange of assets and notify users on their registered email immediately after the transaction.