🧠 How DVM Works

Factum DVM is a pivotal pillar of Factlink’s ecosystem, intricately intertwined with the Factlink Optimistic Oracle to adjudicate disputes over real-world data assertions when challenges arise.

---

1. What is Factum DVM? The Big Picture 🌐🔍

Picture a decentralized courtroom where disputes over real-world data—be it the price of a cryptocurrency on a specific date 📉 or the outcome of a significant event 🏆—are resolved not by a solitary judge, but by a vibrant community of stakeholders voting based on evidence and economic incentives. 🏛️💡 This is the core essence of Factum DVM, a robust dispute resolution mechanism meticulously crafted to deliver verifiable, trustworthy outcomes for queries in decentralized systems like the Factlink Optimistic Oracle.

Factum DVM, standing for Data Verification Mechanism, operates as a decentralized voting system where participants, known as voters, stake tokens to assert their belief in the correct answer to a disputed query. Leveraging the principles of game theory and financial incentives, the system encourages honest participation, ensuring that the majority consensus mirrors the truth. 💰🧩 Unlike centralized arbitration, Factum DVM disperses decision-making power across a network of participants, significantly reducing risks of manipulation or bias.

Built on the lightning-fast Solana blockchain 🚀, Factum DVM is engineered for efficiency and scalability, making it a perfect fit for resolving disputes in real-time decentralized applications (dApps). It integrates seamlessly with Factlink’s Optimistic Oracle, stepping in as the ultimate arbiter when an assertion (a proposed answer) is challenged, ensuring that smart contracts and dApps rely on accurate data without depending on a single point of failure. 🌉🔒

---

2. Why Factum DVM? Purpose and Context 🤔❓

In the blockchain realm, smart contracts frequently require access to external data—think price feeds 📈, weather conditions 🌦️, or sports results ⚽. However, when such data is disputed, as often occurs in systems like optimistic oracles, a dependable resolution mechanism becomes indispensable. Traditional dispute resolution often hinges on a centralized authority, introducing risks of centralization and potential single points of failure.

Factum DVM tackles these challenges head-on by:

• Decentralizing Decision-Making 🤝: Distributing power among a community of token holders who vote on the truth, thereby minimizing reliance on any single entity.
• Leveraging Economic Incentives 💸: Encouraging participants to stake tokens for voting, aligning their financial interests with truthful outcomes—dishonesty risks losses, while honesty reaps rewards.
• Ensuring Scalability and Speed 💨: Built on Solana, Factum DVM efficiently handles disputes, supporting high-throughput applications with ease.
• Integrating with Factlink Optimistic Oracle 🛡️: Serving as the default escalation manager for disputes within the Optimistic Oracle, ensuring seamless resolution when assertions face challenges.

Envision Factum DVM as a decentralized jury system 🧑‍⚖️, where community members collectively determine the truth through a structured voting process, underpinned by financial stakes to maintain honesty. Its mission is to deliver a final, trustworthy verdict on disputed data, empowering dApps to operate with unwavering confidence.

---

3. Core Components of Factum DVM 🧱🔧

Before delving into the intricate workflow, let’s explore the foundational elements of Factum DVM. These components form the bedrock of how disputes are resolved through community voting.

3.1 Admin Properties and Governance 👑⚙️

At the heart of Factum DVM lies a set of administrative controls that dictate the system’s operational framework. The admin sets these parameters during the DVM’s launch. While the following list covers crucial admin parameters, it is not exhaustive:

• Admin Properties: Managed by the system owner, these parameters include:
  • Voting Token Mint: The Factlink token designated for staking, voting, and rewards within the DVM, ensuring a standardized token for all transactions.
  • Staking Parameters: Rules governing staking, such as reward emission rates (incentives for staking), unstake cooldown periods (duration before staked tokens can be withdrawn), and cumulative stake tracking.
  • Phase Lengths: Defined durations for each stage of the voting cycle (commit, reveal, claim, configure), providing a predictable timeline for dispute resolution.
  • Voting Thresholds: Criteria for determining a winning vote, including the minimum stake required for a decision (GAT - God Awful Threshold) and the minimum percentage of votes needed for a majority (SPAT - Schelling Point Activation Threshold).
  • Slashing Parameters: Penalties for incorrect votes or non-participation, designed to deter dishonest or negligent behavior.
  • Round Parameters: Specifications for voting rounds, such as the maximum number of queries per round and the capacity for voter participation.

While the voting token mint remains immutable post-setup, the admin can update other properties through a governance process, ensuring adaptability to evolving needs. Updates are typically queued as pending changes and applied at the start of a new round to uphold fairness. 🛠️🔄

3.2 Oracle Authority Whitelist ✅🔐

To ensure only trusted entities can submit queries for resolution, Factum DVM maintains a curated whitelist of oracle authorities:

• Oracle Authority Whitelist: A list of approved entities (such as the Factlink Optimistic Oracle) authorized to submit disputed queries to the DVM. This safeguard prevents spam or unauthorized queries from overwhelming the system. Only Factlink's products are added to this whitelist. For custom integrations with DVM, interested parties are encouraged to contact us via Discord.
• Management: The admin retains the ability to add or remove entities from this whitelist, and storage capacity can be resized as the list expands.

3.3 Voter Accounts and Delegation 🗳️🤝

Participants who vote on disputed queries are the lifeblood of the DVM’s operation:

• Voter Accounts: Individuals or entities who stake tokens to engage in voting. Each voter possesses an account that tracks their stake, rewards, penalties (slashes), voting history, and more.
• Delegation: Understanding the importance of fund security, Factum DVM offers a delegation mechanism. Voters can stake tokens using a cold wallet for safety and vote each round via a hot wallet. Delegates can withdraw past round rewards (if chosen), and commit, reveal, and claim on queries, but they are barred from adding or removing the original stake. Voters retain full control, able to terminate delegation or appoint a new delegate at any time. Notably, one voter can have only one delegate, and a delegate cannot represent multiple voter accounts.

3.4 Query Structure ❓📋

A query in Factum DVM represents a disputed piece of data requiring resolution:

• Query Details: Encompasses a unique identifier (query ID), a hash for tracking, the type of query, and the owner (typically the optimistic oracle).
• Roll Count and Max Rolls: Monitors how many times a query has been rolled over to a new round if unresolved, with a maximum limit to prevent indefinite delays.
• Voting Details: Captures votes, total stake voted, and the outcome (resolved or unresolved).

3.5 Round Structure and Phases 🔄⏰

Factum DVM operates within structured voting rounds, each segmented into distinct phases to ensure orderly participation:

• Rounds: Each round processes a batch of queries, with a defined start time and a maximum number of queries to manage.
• Phases: Every round cycles through four phases:
  1. Commit Phase: Voters secretly commit to their votes by submitting a hashed value, concealing their actual choice initially.
  2. Reveal Phase: Voters disclose their actual votes, which are verified against their commitments to ensure honesty.
  3. Claim Phase: Voters claim rewards or face penalties based on their voting outcomes.
  4. Configure Phase: Queries are settled, unresolved queries may roll over, and the system gears up for the next round. The precise duration of each phase is under deliberation, with a tentative total of roughly 48 hours for all four phases combined per round. Voters are not required to act during the configure phase. For each query, they must commit, reveal, and claim. 🕒📅

---

4. How Factum DVM Works: Admin Setup Process (A One-Time Task) 🛠️🔧

The admin setup process is a critical one-time initialization executed by the admin right after deploying the Factum DVM smart contract on the Solana blockchain. This foundational step establishes the rules, parameters, and infrastructure essential for the DVM to function as a decentralized dispute resolution system. Let’s explore the purpose, process, and outcome of this setup in detail.

4.1 Purpose 🎯

The admin setup process defines the operational framework of Factum DVM, ensuring predictability, security, and efficiency. It sets the stage for community voting by configuring governance rules, security measures, and storage capacity, enabling the system to handle disputed queries from whitelisted oracle authorities like the Factlink Optimistic Oracle.

4.2 Process 🔄

The admin undertakes the following tasks during this one-time setup:

Initialize DVM Properties ⚙️

The admin configures the core parameters that govern Factum DVM’s operations:

• Voting Token Mint: Specifies the token (e.g., Factlink token) used for staking, voting, and rewards. This token is fixed upon initialization and cannot be altered later, ensuring consistency across financial interactions.
• Staking Parameters: Defines:
  • Emission Rate: The rate at which staking rewards are distributed to voters (e.g., tokens per second), incentivizing participation.
  • Unstake Cooldown: The waiting period (e.g., 7 days) before voters can withdraw unstaked tokens, stabilizing the system.
  • Cumulative Stake Tracking: Monitors the total staked tokens in the system for governance and reward calculations.
• Phase Lengths: Sets durations for each voting phase to ensure a structured timeline:
  • Commit Phase: Time for voters to submit secret vote commitments (e.g., 24 hours).
  • Reveal Phase: Time to reveal votes (e.g., 12 hours).
  • Claim Phase: Time to claim rewards or face penalties (e.g., 10 hours).
  • Configure Phase: Time to settle queries and prepare the next round (e.g., 2 hours).
• Voting Thresholds:
  • GAT (God Awful Threshold): The minimum total stake that must vote for a query to be resolved (e.g., 5 Million tokens).
  • SPAT (Schelling Point Activation Threshold): The minimum percentage of votes required for a majority (e.g., 55%).
• Slashing Parameters: Establishes penalties:
  • Wrong Vote Penalty: Percentage of stake slashed for incorrect votes (e.g., 0.1%).
  • Non-Participation Penalty: Penalty for failing to vote (e.g., 0.1% of stake).
• Round Parameters: Configures:
  • Max Queries per Round: Limits the number of queries processed per round (e.g., 50).
  • Max Voting Capacity: Defines the maximum votes a voter account can handle per round.

Create the Oracle Authority Whitelist ✅

• The admin populates a whitelist with trusted oracle authorities (e.g., Factlink Optimistic Oracle) permitted to submit disputed queries.
• The whitelist can be updated later via governance, but an initial set is established here.

Initialize Storage Accounts 💾

• The admin allocates on-chain storage accounts on Solana to manage system data:
  • Round Data Archive: Stores historical voting round data for transparency and auditing.
  • Voter Accounts: Tracks individual voter stakes, rewards, and voting history.
  • Query Accounts: Manages details of disputed queries (e.g., IDs, votes, outcomes).
• These accounts are initialized with sufficient capacity for initial operations and can be resized later as the system scales.

4.3 Outcome 🌟

Upon completion, Factum DVM is fully operational and primed to process disputed queries. The voting token is set, rules are defined, trusted oracles are whitelisted, and storage is prepared. This setup ensures a secure, predictable environment where voters can participate, and disputes can be resolved efficiently. While the voting token mint remains immutable, other parameters can be adjusted later through governance, providing flexibility without compromising the initial framework. 🏗️🔒

---

5. How Factum DVM Works: Voter Onboarding, Staking, and Withdrawing Process (Staking and Unstaking) 🗳️💰

Voters are the heartbeat of Factum DVM, driving decentralized decision-making by staking tokens, voting on queries, and earning rewards. This section covers the entire lifecycle of a voter’s participation—from onboarding to withdrawing funds—detailing every step of the staking and unstaking process.

5.1 Purpose 🎯

Voter onboarding enables individuals to join Factum DVM, stake tokens to gain voting power, and participate in dispute resolution. Staking aligns their financial interests with the system’s integrity, while the unstaking and withdrawal processes provide flexibility to manage their participation and rewards. Voters are incentivized with emission and voting rewards, making participation both impactful and profitable. 🌟💸

5.2 Process 🔄

The voter’s journey involves the following steps:

Creating a Voter Account 🆕

• How: An individual initializes a voter account linked to their Solana public key, establishing their identity in the DVM.
• Requirements: The account must have sufficient space to store voting data (e.g., stakes, vote commitments) for the rounds they plan to join.
• Significance: This account tracks their stake, rewards, penalties, and voting history, serving as their entry point into the system.

Staking Tokens 💳

• When: Staking occurs during the Commit Phase of a voting round, tying it to active participation.
• How: Voters deposit the designated voting token (e.g., Factlink token) into their voter account via the Voting Authority.
• Impact: The amount staked determines their voting power—more tokens mean greater influence on query outcomes.
• Rewards: Staked tokens earn emission rewards over time (e.g., a fixed rate per second), incentivizing long-term staking even outside active voting.

Delegating Voting Rights 🤝

• How: Voters can assign a delegate to vote on their behalf by setting a delegate public key in their account.
• Delegate Powers: The delegate can commit, reveal, and claim rewards but cannot add or remove the original stake.
• Rules:
  • A voter can have only one delegate at a time.
  • A delegate cannot represent multiple voters.
  • The voter can reset or change the delegate anytime, and the delegate must accept the role initially.
• Purpose: Allows secure participation (e.g., staking from a cold wallet, voting via a hot wallet) while maintaining control over funds. 🔐

Participating in Voting 🗳️

• Overview: Voters (or delegates) vote on queries during the Commit and Reveal Phases (detailed in later sections).
• Process: They commit hashed votes, reveal them, and influence outcomes based on their stake.

Requesting Unstaking 🔄

• How: Voters submit an unstake request to release a portion or all of their staked tokens.
• When: Only during the Commit Phase, ensuring alignment with voting cycles.
• Cooldown: A mandatory waiting period (e.g., 7 days) applies before tokens can be withdrawn, preventing sudden exits during active rounds.
• Limits: Voters can have a maximum number of pending requests (e.g., 5) to avoid system abuse.

Executing Unstake and Withdrawing Tokens 💳

• How: After the cooldown, voters execute the unstake request, transferring tokens from the Voting Authority to their personal Solana token account.
• When: Post-cooldown, at the voter’s discretion.
• Outcome: Tokens become freely usable or transferable outside the DVM.

Claiming and Withdrawing Rewards 🎁

• Voting Rewards:
  • When: Claimed during the Claim Phase after a query resolves.
  • How: Voters who voted correctly (with the majority) claim rewards proportional to their stake, sourced from slashed tokens of incorrect voters.
• Emission Rewards:
  • When: Accrued continuously and claimable periodically (e.g., per round).
  • How: Automatically added to the voter’s account based on staking duration and emission rate.
• Options:
  • Restake: Add rewards to their stake, increasing voting power.
  • Withdraw: Transfer rewards to their personal token account for external use.

5.3 Outcome 🌟

Voters successfully onboard, stake tokens to participate, and contribute to dispute resolution while earning rewards. The process ensures flexibility—voters can resize accounts, delegate voting, and manage stakes or rewards as needed—while maintaining system stability through cooldowns and phase restrictions. By staking and voting honestly, voters uphold the DVM’s integrity and are financially rewarded, making participation both a responsibility and an opportunity. 💪💰

---

6. How Factum DVM Works: Dispute Resolution Step by Step Process 🛠️📜

Let’s navigate the entire lifecycle of a disputed query in Factum DVM, from submission to resolution. Imagine a scenario where the Factlink Optimistic Oracle faces a disputed assertion about whether Bitcoin’s price was above $100,000 on a specific date and time, escalating the query to Factum DVM for resolution. Follow along as we dissect each step! 📊🔎

6.1 Raising a Query (Submitting a Dispute) ❓

• Purpose: An oracle (like Factlink Optimistic Oracle) submits a disputed query to Factum DVM for resolution.
• Process:
  • A whitelisted oracle authority raises a query, providing details like a unique hash, query type, and IPFS reference for full context (e.g., “Was Bitcoin above $100,000 on June 1, 2025?”).
  • The query is assigned a unique ID and added to the current or upcoming round for processing.
  • Parameters like maximum rollovers (how many times it can be deferred if unresolved) are set based on admin rules.
• Outcome: The disputed query is recorded in Factum DVM, awaiting voter input in the next voting round. 📝✍️

6.2 Voting Rounds: Commit Phase 🤐🔒

• Purpose: Voters secretly commit to their stance on each query in the current round without revealing their choice, preventing influence from others.
• Process:
  • During the Commit Phase (a fixed duration, e.g., 24 hours), voters review queries in the round and decide their position (e.g., “Yes” or “No” for a binary query like Bitcoin’s price threshold).
  • To prevent influence or collusion, voters submit a hashed commitment of their vote (a cryptographic representation hiding the actual choice) rather than the vote itself.
  • Voters (or their delegates) must have at least 1 Factlink staked token to participate, ensuring they have skin in the game.
• Outcome: Voters’ intentions are locked in via commitments, ensuring they cannot change their minds based on others’ actions, fostering independent decision-making. 🔐🧠

6.3 Voting Rounds: Reveal Phase 🕵️‍♂️🔓

• Purpose: Voters reveal their actual votes, which are verified against their earlier commitments to ensure honesty.
• Process:
  • In the Reveal Phase (e.g., another 12 hours), voters submit their actual vote (e.g., “Yes”) along with a salt (a random value used in hashing) to prove it matches their commitment.
  • The system checks if the revealed vote, when hashed with the salt and other query details, matches the commitment. If it doesn’t, the vote is deemed invalid, preventing cheating.
  • Valid votes are tallied, with each voter’s stake contributing to the weight of their choice.
• Outcome: The true voting distribution for each query becomes visible, with stake-weighted votes determining the leading answer. 📊👀

6.4 Voting Rounds: Claim Phase 🎁💰

• Purpose: Voters claim rewards if they voted correctly, or face penalties (slashing) if they voted incorrectly or didn’t participate.
• Process:
  • During the Claim Phase, the system evaluates each query’s outcome based on voting thresholds (e.g., GAT for total stake voted, SPAT for majority percentage).
  • If a query meets the thresholds, the majority answer (e.g., “Yes” with 60% of staked votes) is deemed correct. Voters who chose this answer can claim rewards proportional to their stake, often sourced from penalties on incorrect voters.
  • Incorrect voters lose a portion of their stake (slashing), calculated based on admin-defined rates (e.g., a percentage of stake per wrong vote).
  • Voters who didn’t vote on a query also face slashing for non-participation, encouraging active engagement.
  • Rewards can be restaked (added to the voter’s stake for future voting power) or withdrawn to a personal account.
• Outcome: Financial incentives reinforce honest and active participation. Correct voters are rewarded, while incorrect or inactive ones are penalized, aligning interests with truth. 💸✅

6.5 Voting Rounds: Configure Phase ⚙️🔄

• Purpose: Finalize query outcomes, handle unresolved queries, and prepare for the next round.
• Process:
  • In the Configure Phase, resolved queries are officially settled. If a query meets voting thresholds, its outcome (e.g., “Yes”) is recorded as the final truth.
  • Unresolved queries (those failing to meet thresholds like GAT or SPAT) can roll over to the next round for another voting attempt, up to a maximum number of rollovers. If the limit is reached, the query is marked unprocessable, and no definitive answer is provided.
  • Unclaimed rewards or penalties for resolved queries are seized by the system (sent to an admin-controlled account) to prevent indefinite escrow.
  • The system updates round parameters, applies any pending admin changes (e.g., new phase lengths), and schedules the next round with a new start time and query batch.
• Outcome: The round concludes, resolved queries are finalized for use by dApps or oracles, and the system resets for the next cycle of disputes. ♻️🕒

6.6 Query Closure and Cleanup 🧹✨

• Purpose: Free up blockchain storage and return remaining funds after a query is settled.
• Process:
  • Once a query is resolved or deemed unprocessable, the query owner can close its associated account, reclaiming Solana rent (lamports used for storage) should the query raiser in the optimistic oracle decide to do so.
  • Voters can also close their accounts if they have no staked tokens, pending rewards, or unstake requests, recovering rent during the Commit Phase.
• Outcome: Resources are efficiently managed, keeping the system lean and cost-effective for all participants. 🌿💡

---

7. Incentive Mechanisms: Staking, Rewards, and Slashing 💸🎯

Factum DVM’s design is anchored in a sophisticated economic model to ensure participants act in the system’s best interest. Let’s explore how these incentives drive honest behavior:

• Staking: Voters must stake tokens to participate, with their voting power proportional to their stake. Staking aligns their financial interest with the system’s integrity—more stake means more influence but also more risk if they vote incorrectly. 🪙⚖️
• Emission Rewards: Staked tokens earn ongoing rewards over time (based on an emission rate set by the admin), encouraging long-term participation even outside active voting rounds. These rewards can be withdrawn or restaked. 🌱💰
• Voting Rewards: For each resolved query, voters who chose the correct (majority) answer receive rewards proportional to their stake. These often come from slashed tokens of incorrect voters, creating a zero-sum game where honesty pays. 🎉📈
• Slashing (Penalties): Voters face financial penalties in two scenarios:
  • Wrong Vote Slashing: If a voter’s choice differs from the majority outcome, a portion of their stake is slashed (e.g., based on a rate like 0.1% per wrong vote).
  • No-Vote Slashing: Failing to vote on a query in a round also results in slashing, incentivizing active engagement.
• Outcome: The combination of rewards for correct votes, emission incentives for staking, and penalties for dishonesty or inaction creates a powerful alignment. Voters are motivated to research queries, vote truthfully, and participate consistently, ensuring reliable outcomes. ✅💪

---

8. Security and Trust Mechanisms 🛡️🔒

Trust is the cornerstone of any dispute resolution system, and Factum DVM employs multiple safeguards to prevent manipulation and ensure fair outcomes:

8.1 Commit-Reveal Voting Process 🤐🕵️‍♂️

• Two-Step Voting: The commit-reveal process prevents voters from being influenced by others’ choices. By committing a hashed vote first and revealing it later, voters cannot wait to see the majority trend before deciding, reducing herd behavior and collusion risks.
• Cryptographic Integrity: The use of hashes and salts ensures voters cannot alter their committed votes during the reveal phase, maintaining the integrity of their initial decision. 🔐🧩

8.2 Stake-Weighted Voting and Thresholds ⚖️📊

• Stake Proportionality: Voting power is tied to staked tokens, meaning participants with more “skin in the game” have greater influence. This discourages Sybil attacks (creating many fake accounts) since acquiring significant stake is costly.
• Thresholds for Validity: Outcomes must meet admin-defined thresholds (GAT for total stake voted, SPAT for majority percentage) to be considered valid, ensuring decisions reflect broad, meaningful consensus rather than small, potentially manipulated groups. 📉🛡️

8.3 Slashing as a Deterrent 🚨💥

• Financial Risk: Slashing for wrong votes or non-participation acts as a strong deterrent against dishonest or negligent behavior. Losing a portion of staked tokens is a real cost, encouraging voters to act responsibly.
• Dynamic Penalties: Slashing rates can be adjusted by the admin to balance deterrence with fairness, ensuring penalties are neither too harsh (discouraging participation) nor too lenient (allowing abuse). ⚖️🔧

---

9. Financial Operations: Rewards, Emissions, and Withdrawals 🏦💼

Factum DVM manages financial transactions through structured accounts and processes to ensure transparency and security for all participants:

• Voting Authority: A program-controlled account that holds staked tokens, manages reward distributions, and executes token transfers during claim and unstake operations. This ensures voter funds are secure and only released per system rules. 🔒💳
• Owner Authority: A separate admin-controlled account that collects unclaimed rewards or slashed tokens (e.g., during the Configure Phase). The admin can withdraw these funds to support system operations or development. 🛠️💰
• Emission Rewards: Staked tokens accrue ongoing rewards based on an admin-set rate, distributed periodically (e.g., per round or time elapsed). This incentivizes long-term staking and system participation. 🌱📈
• Unstake and Withdrawal Mechanisms: Voters can request to unstake their tokens (with a cooldown period to prevent sudden exits during critical rounds) or withdraw rewards, ensuring flexibility while maintaining system stability. 🔄💸
• Outcome: Financial operations are transparent and secure, with clear separation between participant funds (via Voting Authority) and system fees (via Owner Authority). Voters have flexibility in managing their stakes and rewards, balancing participation with liquidity needs. 🌟💼

---

With this comprehensive exploration, we’ve unraveled the intricate workings of Factum DVM, from its foundational components to its operational intricacies and security mechanisms. For any further questions, please contact us through discord.. 🌍🔒