Introducing the Blockworks MCPLearn more

Get a demoExplore data
Token TransparencyOvr
OVR ·B1 v1.3 ·1 gapPartial - 1 gap
Token

Project & Team

01

Description of Project

Provide a concise narrative that clearly states each of (a)–(e) below.

  • (a) Problem the project solves — The problem the project is solving.
  • (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
  • (c) High-level project overview — How the project works at a high level.
  • (d) Primary token functions — The primary functions of the token (e.g. gov participation).
  • (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.

(a) Problem the project solves

OVER addresses the lack of a shared, precise, decentralized spatial layer for the physical world. It positions itself as the world's largest 3D mapping dataset powering VPS navigation, World Models/Machine Perception Models, and Generative AR experiences. In practice it tackles two linked gaps: machines (robots, devices, autonomous systems) need centimeter-accurate ways to understand where they are and data to train Vision Foundation Models; creators/businesses need a way to anchor and publish AR content reliably to real-world locations. OVER builds comprehensive 3D digital twins of real places to serve both — feeding "Physical AI" on one side and AR publishing on the other — while keeping ownership of the underlying spatial assets decentralized rather than locked inside a single corporate map provider.

(b) Operational priorities

OVER's approach to long-term sustainability centers on the self-reinforcing flywheel described above: more 3D maps improve the Large Geospatial Models, which sharpen VPS accuracy and generative-AI capabilities, which drives more adoption and, in turn, more mapping. Each loop increases the value and coverage of the underlying spatial dataset — the asset every revenue channel draws from. Rather than relying on transactional marketplace fees, ongoing development and operations are expected to be funded primarily by the utility and monetization of that spatial data: licensing maps to AI labs for world-model and machine-perception training, VPS API usage for machine spatial orientation, and vertical applications such as indoor navigation. As these channels scale, they generate recurring, demand-driven revenue tied directly to the dataset's growth rather than to speculative token activity. This revenue is intended to feed back into the ecosystem through two parallel mechanisms. First, a buyback program: revenues generated from 3D-map monetization are used to buy back OVR from the market, linking real commercial activity to token demand and aligning the token's value with the platform's actual data economy. Second, Foundation treasury support: the Foundation's Community-Rewards and Ecosystem allocations (capped at a hardcoded 72-month linear release and governed by token-holder votes) fund community incentives and ecosystem growth. Together, buyback-from-revenue and Foundation-backed reserves are meant to sustain both continued mapping incentives (map2earn) and core protocol development over time.

(c) High-level project overview

At its core, OVER runs an incentivized 3D-mapping economy. Through its map2earn program, OVER rewards a global community of mappers in OVR tokens for scanning physical locations, producing 3D digital twins that accumulate into the world's largest 3D mapping dataset — on the order of 250k+ locations, 100M+ images, and over 1,000 TB of data. This crowdsourced supply is the central asset, and OVER monetizes it through several complementary channels: Licensing to AI labs for world models and machine perception. The curated 3D datasets are licensed to train Large Geospatial Models and other spatial-AI / machine-perception systems, positioning the map data as training fuel for "Physical AI" and robotics rather than just consumer content. Visual Positioning System (VPS) API. The same maps power a VPS that lets any camera-equipped device or robot establish its precise position and orientation in 3D space. OVER offers a Camera Pose Estimation API for centimeter-precise positioning and real-time pose estimation, live across ~249k locations — sold as a service for autonomous navigation and spatial awareness. Indirect value to OVRLand (AR anchoring). The 3D maps and VPS provide the precise anchoring substrate for OVRLand, OVER's AR spatial domains, enabling AR content to be locked accurately to real-world coordinates both indoors and outdoors. Here the maps don't generate direct revenue so much as make the AR publishing layer technically viable and more valuable driving OVRLand sales. Vertical applications. The VPS foundation supports purpose-built solutions such as indoor navigation and wayfinding systems, extending the map economy into specific commercial verticals (e.g. retail/venue navigation).

(d) Primary token functions

OVR is an ERC-20 utility token, with a fixed final supply of 89,893,756 tokens after a April 26, 2023 governance vote permanently concluded the original Initial Bonding Curve Offering. Its main functions are: Medium of exchange — used on the OVER marketplace to buy or rent OVRLand buy OVRMaps, received as payment when selling these NFT-based digital assets. Governance — holders participate in decisions affecting governance of the OVER platform. (E.g.: the IBCO closing)
Staking / liquidity mining Earn mechanisms — rewards through map2earn (3D mapping), Play2Earn games like Treasure Hunt, and creator contests.

(e) Control surface reliance

Today, control of OVER's core assets — the 3D map dataset, brand, and software — sits with Over Global OU, 100% controlled by Over Holding Srl as the operating company, with token-holder governance already exercised over specific on-chain parameters (E.g.: the IBCO closure and supply fix). The anticipated evolution moves this control surface decisively toward market-based decentralized governance via MetaDAO's futarchy. The intended end-state has three parts. First, an asset transfer: Over Holding would transfer all of the intellectual property — the 3D maps, brand, and software — to an entity controlled by a MetaDAO-style futarchy, so the IP itself sits under decentralized control rather than with the company. Second, a clean separation of roles: Over Holding is retained as the development company ("DevCo"), continuing to build and operate the technology under delegation, while ultimate authority over the IP rests with the futarchy. Third, governance binding: all proof-of-governance over the IP is delegated to the futarchy and strictly connected to token holders, so material decisions about the assets are made through the protocol rather than by the company alone. The substantive shift is in how decisions get made. Rather than conventional token-weighted voting, MetaDAO's futarchy replaces token-based voting with market-based mechanisms: a proposal spins up two prediction markets — one assuming it passes, one assuming it fails — and participants trade on the expected outcomes, with the market's relative valuation of the "pass" versus "fail" scenarios determining the decision. The governing objective is an economic metric (typically token value), so the model is designed to make choices data-driven and tied to the protocol's measured success rather than to popularity or insider influence. A practical attraction for this kind of handover is accountability: futarchy makes participants financially accountable for their predictions, so that only decisions with broad, measurable support are enacted. MetaDAO is relevant here specifically because it is the first project to put futarchy into live practice and is itself governed by futarchy, providing a platform on which other communities can create and run their own futarchies.

02

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Labs / DevCo

Full Name

Official Title

Prior Experience

Davide Cuttini

CEO - Co-Founder

Software Engineer with expertise in Augmented Reality, deep learning, and blockchain smart contract | Wide experience developing machine learning models for video, audio, and text use | System Integration and Robotics with specific applications in the industrial field | Collaborated with IBM to scale-up industrial AI solutions | Serial enterpreneur | TEDx Speaker.

Diego D Tommaso

COO - Co-Founder

Previous experience as enterpreneur in the fashion industry with successfull exit | MBA from SDA Bocconi and UCLA | Worked in PWC as senior advisor in Finance, Open innovation and Fashion retail industry | Start-up advisor | Keynote speaker | Founder of Unicorn Trainers.

Michele Zanello

CMO

Head of Growth Marketing | 11+ years of experience in marketing | Forbes Under 30 in Media & Marketing PM Metaverse fashion week | TOP #100 most influential italian people in Marketing Business (IEMBI 2023)| Rolling stone Contributor

Foundation

Full Name

Official Title

Prior Experience

DOES NOT EXIST

DAO / Onchain Governance

Full Name

Official Title

Prior Experience

DOES NOT EXIST

03

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).

  • (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
  • (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
  • (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
  • (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
  • (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

IP is owned by OVER Global OU, 100% controlled by Over Holding S.r.l.. OVER Global OU is the target of the formerly described MetaDAO operation.

(b) Contract/admin powers

Currently there is no active DAO, the only existing on-chain governance contracts are Aragon DAO-framework IBCO smart-contracts, yet the IBCO has indefinitely been stopped by a vote of token holders on 26th April, 2023 at 8:00 PM CEST, fixing the total supply to 89,893,756 OVR tokens.

(c) Locked-token rights (conditional)

N/A

(d) Value accrual & holder rights

Utility Token (OVR) value accrual is enforced by a token buy-back and burn mechanic. The planned revenue burn split is the following: 60% of revenues generated from 3D Maps Data Licencing, VPS Usage, LGM Licencing are used for buy-back and burn mechanics. While for revenues generated on the B2B XR layer, 35% goes to the OVRLand owners and 30% are used for buy-back and burn mechanics. NFT tokens issued by OVER, namely OVRLand, are spatial domains with publishing rights granted to the bearer for AR content on the geographic coordinates defined by the NFT.

(e) Dissolution authority

The formerly existing Aragon DAO-framework could be modified only by majority token vote.

04

Primary Foundation

For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

NO FOUNDATION Currently

(f) Current economic arrangements and distribution policies

Not existing

05

Primary Dev Co

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.

  • (a) Entity — Type and jurisdiction.
  • (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
  • (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
  • (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
  • (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
  • (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

Over Holding S.r.l. - Italian LTD

(b) IP ownership & control

All of the IP: 3D Maps data, software, Brand, Patents, treasury tokens, are owned by an Estonian subsidiary Over Global OU,

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

Pre-minted tokens are controlled by unmodifiable vesting smart contracts. The entity does not hold any control/power on the DAO; OVER Global OU - the Estonian entity -  has control over treasury, protocol revenue, token administration and reward parameters.

(d) Powers over Foundation

No primary foundation exists.

(e) Contract/admin powers

On 2nd May 2023 at 10:43 AM CEST, the IBCO smart contracts have been definitively stopped, and the final total supply of existing OVR tokens is equal to 89,893,756. There IBCO stop is permanent, no address can reactivate the IBCO.

(f) Current economic arrangements and distribution policies

None exist

Token Supply & Allocations

06

Initial Allocation

Ticker

Date

Allocation Category Name

Recipient Type

Allocation %

Allocation Tokens

TGE Unlock %

TGE Unlock Tokens

Cliff Months

Cliff Unlock %

Linear Vesting Months

Cadence Months

Circulating Treatment

Notes on what each category is used for

If applicable: Contract / Wallet address

OVR

20/12/20

Public IBCO Sale (Bonding Curve)

Public / Sale

0,0912828250273579

8205756

1

8205756

0

0

0

1

Yes

Tokens minted on demand via the Initial Bonding Curve Offering (Bancor-based IBCO, start price $0.07); no vesting - tokens were immediately liquid upon purchase. Modeled as 100% unlocked at TGE. IBCO closed by governance vote on 26 Apr 2023 at market price ~$0.298, fixing total supply at 89,893,756 OVR.

OVR

20/12/20

Equity Subscribers

Insiders

0,0472780334153576

4250000

0

0

0

0

72

1

Conditional

Allocated to equity subscribers. 15-day cliff post-IBCO launch (sub-month, entered as 0), linear release over 72 months. Insider bucket; counted circulating only once distributed/sellable.

0xE07f85362fe0d14d4F2b272b98d67B50A3148072

OVR

20/12/20

Private Sale Contributors

Private / VC

0,0352416023199654

3168000

0

0

0

0

12

1

Yes

Private-sale contributors. 15-day cliff, variable vesting from no lock-up to 12 months; approximated as 12-month linear release. No dedicated vesting contract published; fully vested.

OVR

20/12/20

Team Fund

Insiders

0,2947924436487

26500000

0

0

0

0

48

1

Conditional

Incentivizes team members for long-term commitment. 15-day cliff (sub-month, entered as 0), linear release over 48 months. Insider bucket; counted circulating only once distributed.

0xCEE8fcBC9676A08B0a048180d99b41a7F080bB78

OVR

20/12/20

Advisors

Insiders

0,0661892467815006

5950000

0

0

0

0

24

1

Conditional

Allocated to advisors. 15-day cliff (sub-month, entered as 0), linear release over 24 months. Insider bucket; counted circulating only once distributed.

0xC1D9261cBc6DeD410dC81929EBB0871471E7e9D3

OVR

20/12/20

Bounty Program

Community

0,0166863647348321

1500000

0

0

0

0

3

1

Yes

Rewards community members for treasure hunts and other campaigns. 15-day cliff, linear release over 3 months. No dedicated vesting contract published; fully vested.

OVR

20/12/20

Company Treasury - Community Rewards

Community

0,222484863131094

20000000

0

0

0

0

72

1

Conditional

Community rewards (IPFS nodes, staking, liquidity mining, voting). Release governed by token-holder votes, capped at a hardcoded linear release over 72 months.

0x0965cBf02906b8c854037A16D4f39456444cE600

OVR

20/12/20

Company Treasury - Ecosystem

Ecosystem

0,222484863131094

20000000

0

0

0

0

72

1

Conditional

Supports ecosystem growth and development. Governed by token-holder votes, capped at a hardcoded 72-month linear release; funds may also be burned per community governance.

0xe3729fA98e1bC66750F986E95b37044B06D26D73

OVR

20/12/20

Contingency Liquidity Bootstrapping

Liquidity

0,00355975781009751

320000

1

320000

0

0

0

1

Yes

Reserved for liquidity bootstrapping on partner exchanges at IBCO launch (immediate availability); unused tokens designated to be burned. Note: 2,099,891 OVR burned to date (total supply net of burns: 87,793,865).

OVR

20/12/20

OVR

20/12/20

OVR

20/12/20

OVR

20/12/20

OVR

20/12/20

OVR

20/12/20

07

Airdrop Process

Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.

  • (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
  • (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").

(a) Planned but not yet executed airdrop

NO AIRDROPS

Transactions & Market Structures

08

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table: (a) Market maker's name — the market maker's name; (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply; (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable, (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.

Market Maker Name

Token Allocation Committed

Term Duration

Structure Name

NO MARKER MAKER

09

CEX / DEX Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table: (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair); (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply; (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable, (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership. If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.

Exchange Name

Token Allocation Committed

Term Duration

Native Token Listing Fees

Kucoin

None

Gate.io

None

MEXC

None

Uniswap

None

Pancacke Swap

None

Financial Disclosures & Risks

10

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide: (a) Series Name; (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.); (c) Date of sale (at least month & year); (d) Number of tokens sold (or % of total supply); (e) Vesting schedule. If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").

Series Name

Investment Vehicle

Date Of Sale

Number of tokens sold

Vesting Schedule

Seed

Safe + Token Vehicle

September 2020

4250000

72 months Linear

Pre-Sale

SAFT

November 2020

3168000

0-12 Months Linear

11

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

  • (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
  • (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
  • (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
  • (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
  • (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
  • (f) References (optional) — Link(s) to post-mortem/advisory/PR.

(a) Date & component affected

No exploits effecting Token Holders of Protocol Funds as of 13/07/2026

12

Material Risk Factors (Regulation, Technology, Token Economics)

Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.

  • (a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
  • Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
  • Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
  • Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
  • Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
  • (b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
  • Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
  • Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
  • (c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
  • Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
  • Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?

(a) Regulatory, Legal & Tax Risks

Impact of regulatory change on TGE and listings. OVR completed its token generation and price discovery via an Initial Bonding Curve Offering that ran from December 2020 to its governance-mandated closure in 2023; there is therefore no pending or future TGE that could be blocked by regulatory change. The residual risk is to ongoing listings rather than issuance. OVR is currently traded on both centralized venues (KuCoin, Gate.io, MEXC) and decentralized pools (Uniswap, PancakeSwap). Evolving classification regimes — most materially the EU's Markets in Crypto-Assets Regulation (MiCA), under which the issuer's home base falls, and discretionary delisting decisions by individual exchanges — could restrict or remove access to specific trading venues in certain jurisdictions. Because no market maker or exchange holds a token allocation or lockup tied to a listing (see Sections 8 and 9), the project has limited contractual control over whether any given centralized venue continues to support the pair. Entity-level regulatory impact. The project's control surface is concentrated in two existing legal entities: Over Holding S.r.l. (Italian limited company, the DevCo) and its wholly-owned Estonian subsidiary Over Global OÜ, which holds the IP and treasury tokens. There is no Foundation and no active DAO, so regulatory exposure runs through ordinary corporate entities subject to Italian and Estonian law and to EU-level frameworks (MiCA, AML/KYC obligations, data-protection rules applicable to the underlying mapping/imagery dataset). Future enforcement actions, licensing requirements (e.g., classification of any element of the platform as a regulated service), or changes that compel a restructuring of the DevCo/subsidiary arrangement could increase operating costs or require changes to how the token's utility functions are offered. The contemplated future migration of IP to a MetaDAO-style futarchy entity (described in Section 1e) is not yet implemented and would itself raise novel and untested regulatory questions if pursued. Tokenholder tax treatment. Tax treatment of acquiring, holding, staking, earning (via map2earn, Play2Earn, or the OVR-to-UOMI staking program), or disposing of OVR is uncertain and varies by jurisdiction and by the holder's individual circumstances. Rewards earned through mapping or staking may be treated as ordinary income in some jurisdictions and as something else in others. The project does not provide tax advice. Each tokenholder is solely responsible for determining and meeting their own tax obligations and should consult a qualified professional. Jurisdictional and user-access restrictions. The project applies a single category of access restriction: OVER does not distribute rewards to, nor accept payments from, persons or citizens of jurisdictions subject to OFAC sanctions. This restriction is enforced through third-party KYC providers, which screen users against sanctions criteria. There are no other jurisdictional gates — the project does not otherwise restrict U.S. persons or apply retail-versus-professional gating. The associated risks are twofold. First, KYC and sanctions screening, while reducing exposure, are not infallible; in a decentralized, crowdsourced mapping economy there remains residual risk that a restricted person could interact with the token or platform despite these controls, and the project relies on the accuracy and continued operation of its third-party KYC providers. Second, because no broader jurisdictional restrictions are imposed, OVR may be accessible to users in jurisdictions where its offering or specific utility functions are not permitted, creating regulatory exposure for both those users and the project should local rules tighten.

(b) Protocol, Technology & Security Risks

Bugs and design flaws. OVR's on-chain footprint consists of the original Aragon-framework IBCO contracts (now permanently halted), the ERC-20 token contract, the burn contract holding ~2.1M OVR, and a set of vesting contracts, the majority of which have completed their schedules. Because issuance is closed and supply is fixed at 89,893,756 OVR, the most severe smart-contract risk class — unauthorized minting or supply inflation — is structurally constrained, as no active minting authority remains. Residual technical risk concentrates in: (i) the token and vesting contracts (any latent flaw could affect transfers or remaining locked balances); (ii) the Uniswap V3 OVR/ETH pool seeded at IBCO closure and other DEX liquidity, which is subject to standard AMM and smart-contract risk; and (iii) off-chain and adjacent infrastructure — the VPS/Camera Pose Estimation API, the OVRLand/OVRMap NFT layer, and the marketplace — whose failure would not alter token balances but could disrupt the utility that underpins token demand. Security measures and their limitations. Rather than deploying bespoke contract code, OVER relied on battle-tested, independently audited frameworks from Aragon Black for its core on-chain components — the IBCO bonding-curve and collateral-management contracts (built on the Aragon DAO framework and the Bancor protocol) and the associated governance mechanics. Using widely-deployed, audited frameworks reduces the likelihood of novel implementation errors relative to custom code, and the vesting contracts are immutable once deployed, removing upgrade-key risk for locked balances. These measures nonetheless have limits. Reliance on third-party frameworks does not guarantee the absence of undiscovered vulnerabilities, and it transfers a degree of dependence onto the security and continued correctness of those external codebases. Audits reflect a point in time and cannot anticipate every interaction or future condition. Furthermore, these protections do not extend to third-party dependencies outside OVER's contract perimeter — the DEX protocols hosting OVR liquidity, the bridges with Base, and Polygon — nor to user-side custody failures.

(c) Token Economics, Unlocks & Incentive Risks

Critical economic assumptions. OVR's long-term model rests on the assumption that demand-driven, off-chain and on-chin revenues — licensing 3D-map data to AI labs for world-model and machine-perception training, VPS API usage, vertical applications such as indoor navigation and OVRLand sales — will scale and feed the buyback-and-burn mechanism described in Section 1b. The token's value-accrual thesis depends on that commercial revenue materializing at sufficient scale; if data-licensing and VPS adoption do not grow as projected, the buyback-from-revenue loop weakens, removing the primary non-speculative source of token demand. A second assumption is that map2earn and other earn incentives continue to attract mapping contributors at a cost sustainable from Foundation-allocated reserves; those reserves are finite and capped at a hardcoded 72-month linear release, so incentive emissions are time-bounded and cannot be indefinitely extended without new revenue. Failure of either assumption would impair the flywheel that links dataset growth to token demand. Supply, unlocks, and deflation. Supply is fixed at 89,893,756 OVR with no active inflation; the majority of insider and contributor vesting (Equity Subscribers, Team, Advisors, both Foundation buckets) has completed, so the historically significant unlock-driven sell pressure has largely passed and the holder base is correspondingly wide. The remaining supply-side variable is the Foundation Community-Rewards and Ecosystem allocations, which release linearly up to the 72-month cap; continued distribution of these can add circulating supply over their remaining schedule. On the deflationary side, ~2.1M OVR sits in the burn contract and revenue-funded buybacks are designed to burn further tokens, but the magnitude of future burns is contingent on the revenue assumptions above and is not guaranteed. Governance control over monetary policy and rewards. Governance powers are presently narrow. Total supply is fixed and not adjustable by governance, and the IBCO is permanently closed — so monetary policy in the inflationary sense is effectively immutable. The principal governance-related risk is therefore not runaway inflation but the contemplated future migration to MetaDAO-style futarchy (Section 1e): if adopted, decision-making over the IP and protocol parameters would shift to market-based mechanisms that are novel and not yet live for OVER, introducing execution, legal, and governance-design uncertainty whose effect on tokenholders cannot yet be assessed.

This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. Ovr is solely responsible for the content, accuracy, and legality of its disclosures.

The daily brief, in your inbox

Markets, protocols, and policy, read by 200K+ professionals.

Blockworks Inc.133 W 19th St., New York, NY 10011

Solutions

InvestorsExchangesEnterprisesOnchain Businesses

© 2026 Blockworks Inc.

TermsPrivacy PolicyPrivacy CenterNews Archive