DOCSEARCHbyAlgolia
Submit Docs

Oasys Documentation

website·Indexed 35 days ago

https://docs.oasys.games/

Oasys is a multi-layered, EVM-compatible PoS public blockchain specializing in games. The documentation covers its architecture, including the Hub-Layer (Layer 1) and Verse-Layer (Layer 2), tokenomics, governance, and technical guides for building Verse nodes, operating validators, and deploying contracts using Hardhat.

Tokens
52K
Snippets
233
Records
415
Agent score
69%

What's inside Oasys

  1. Overview of the Oasys Verse Verifier

    The Verse Verifier is an instant verifier of the Verse-Layer for the Oasys Blockchain. All Hub Layer Validators are required to install a Verse Verifier. Its primary functions include:

    • Verifying rolled-up state from the Verse-Layer to the Hub-Layer.
    • Creating and sharing signatures with other verifiers via P2P.
    • Finalizing rollups by collecting signatures for 51% or more of the total stake and submitting them to the verification contract.
    • The verification of rollup state, P2P node, and signature submission can be used individually.

  2. Overview of oNFT creation requirements

    An oNFT is a Non-Fungible Token created by Oasys Hub that can be bridged between the Verse Layer (L2) and the Hub Layer (L1). To create an oNFT, you must deploy a corresponding ERC721 contract on both the Hub (L1) and the Verse (L2).

  3. Overview of oFT (Oasys Fungible Token)

    An oFT is a Fungible Token created on the Oasys Hub (L1) that can be bridged between the Hub Layer (L1) and the Verse Layer (L2). To implement an oFT, a corresponding ERC20 contract must be created on both the Hub and the Verse layers.

  4. Overview of joining the Oasys validator network

    Becoming a validator involves registering a node as a potential validator by linking a validator owner account and an operator account. The joining process must be completed before staking can occur. To officially become a validator, the validator owner must stake a minimum of 10,000,000 OAS. Note that the staking process may take up to one epoch (approximately 1 day) to complete. Oasys recommends a commission rate of 10% on the mainnet.

  5. Overview of the Verse Instant Verifier

    The Instant Verifier for the Verse-Layer of the Oasys Blockchain verifies rollup states from the Verse-Layer to the Hub-Layer. It creates signatures and shares them with other verifiers via P2P. Hub-Layer validators must install a Verse Verifier. The verifier is verified by the Hub-Layer validator and can finalize rollups by collecting signatures representing 51% or more of the total stake.

    Requirement: The Instant Verifier requires at least one Replica node of the Verse node, operated by someone other than the Verse Builder, to validate transactions and ensure integrity.

  6. Overview of Oasys SAND Verse for developers

    Oasys SAND Verse is a Layer-2 (Verse) network designed for verse developers to test contract deployment and transaction execution. Transactions on Oasys Verse, including SAND Verse, do not require gas fees. Because transactions are public and visible via the SAND Verse explorer, developers should avoid including sensitive project information within their transactions.

  7. Overview of Verse-Layer system contract upgrades

    System contracts in Verse-Layer (e.g., Cross-Domain Messenger and Token Bridge) are deployed by writing compiled bytecode directly into the blockchain state rather than through standard transactions. Upgrading these contracts requires overwriting the state with new bytecode. This process requires a maintenance window of 30 to 90 minutes during which Verse-Layer must be shut down. If deployed on Oasys Mainnet, the Oasys team must be contacted to coordinate the upgrade of the Instant Verify replica node.

  8. Overview of Verse-Layer replica node synchronization

    Read-only replica nodes of the Verse-Layer allow users to retrieve verse information and can be promoted to writable origin nodes. There are two synchronization methods:

    1. Synchronize from Origin: Transaction data is pulled from the origin node via the data-transport-layer. This offers low latency (500ms - 1000ms) and is recommended for RPC load balancing by the origin node owner.
    2. Synchronize from Hub-Layer: Transaction data is pulled from the Hub-Layer's rollup contract (CanonicalTransactionChain). This ensures only data validated by Oasys validators is synchronized, but introduces a 30-60 second delay. This is recommended for all other use cases.

  9. Overview of Oasys Blockchain Architecture

    Oasys is an EVM-compatible public blockchain designed specifically for gaming. It utilizes a multi-layered architecture consisting of two primary components: the Hub-Layer, which serves as a highly scalable Layer 1, and the Verse-Layer, which functions as a specialized Layer 2 utilizing Ethereum's Layer 2 scaling solutions.

  10. Understand the Optimism Virtual Machine (OVM) state model

    The Optimism Virtual Machine (OVM) is a scalability solution for Ethereum. It utilizes an EVM that manages multiple states on Optimism. OVM programs use a logic function satisfies_assumptions(assumptions, ethereum_state, local_information) => true/false to determine if a specific Ethereum state is possible based on local information and predefined assumptions. This mechanism is often used for 'dispute liveness assumptions,' such as ensuring that malicious withdrawals are disputed by participants in a channel.

  11. Understand Delegated Proof of Stake (DPoS) in Oasys

    Delegated Proof of Stake (DPoS) is an evolution of PoS that introduces a delegation system. Token holders use their tokens to vote for a specific number of validators. These elected validators are granted the authority to create and validate blocks on behalf of the token holders. Delegators are eligible to claim rewards from the delegation process.

  12. Understand Oasys Hub Layer Validator Account Roles

    Oasys uses a Delegated Proof of Stake (DPoS) system with a separation of accounts to enhance security and operational stability. The system distinguishes between three primary roles: Delegators, Validator Owners, and Validator Operators.