1. Legal Disclaimer & Availability Notice

This white paper is provided for informational purposes only and does not constitute an offer to sell, a solicitation of an offer to buy, or a recommendation for any token, security, or other financial instrument, and it should not be relied upon for any investment decision. Any token or NFT referenced herein—if launched—is intended solely for consumptive/utility use within the Defibillboards ecosystem (e.g., access rights, credits, in-experience items) and is not intended or marketed as an investment; readers should not expect profit, income, dividends, yield, or price appreciation arising from the efforts of Defibillboards or others. New York notice: Defibillboards is not licensed by the New York State Department of Financial Services to engage in “virtual currency business activity.” Defibillboards does not offer, sell, exchange, transmit, or provide staking/yield/revenue-sharing programs to residents of New York State unless and until all required approvals or exemptions are obtained. This document may include forward-looking statements regarding planned features and milestones that are uncertain and subject to change; product features, access rights, technical parameters, program eligibility, and availability may be modified, delayed, or discontinued without notice. Use of digital assets involves significant risks, including loss of value, technology failures, cyberattacks, smart-contract bugs, bridge or custody risks, market illiquidity, regulatory actions, and the suspension or termination of third-party services (exchanges, wallets, networks). Nothing herein implies any exchange listing, regulatory approval, endorsement, or availability in any jurisdiction; participation may be restricted by local law and platform policy. Each reader is solely responsible for understanding and complying with applicable laws and should seek independent legal and tax advice.

2. Abstract

Defibillboards is a metaverse marketing and coordination layer for owners of digital land, digital assets, and brand creators. Today, virtual parcels are fragmented and underutilized, limiting discoverability and cross-experience activation. Our approach combines high-visibility parcels near points of interest with a decentralized application (dApp) that standardizes campaigns, gates experiences, and links adjacent spaces into traversable hubs. Core components include parcel-anchored placements, creator/brand tooling, interoperable content standards, and workflows for interactive commerce and measurement across networks and devices. We describe the system architecture, ecosystem roles (landowners, creators, brands, participants), and operational model for programmable, measurable placements. Defibillboards NFTs function as access credentials to ecosystem features (e.g., creator tools, gated experiences, campaign participation). Where permitted, engagement-based programs may be offered; any rewards are consumptive utilities within the environment (e.g., credits, access rights, in-experience items). The scope includes current capabilities and planned extensions; availability varies by platform and jurisdiction. This paper outlines the design rationale, technical foundations, and go-to-market considerations for activating underused virtual land into coordinated, user-facing experiences. See Legal Disclaimer & Availability Notice for limitations.

3. Introduction

The metaverse is evolving from isolated 3D scenes into connected environments where people gather, create, and transact. Yet most virtual parcels remain fragmented and underutilized, making it hard for brands and creators to launch discoverable, interoperable experiences. Defibillboards addresses this gap by operating high-visibility parcels near primary spawn points and notable landmarks across leading decentralized platforms, and by providing a coordination layer that turns land into programmable canvases for marketing, commerce, and participation. Our model is rooted in a core human driver—social connection. From in-person venues to immersive worlds, audiences seek places to engage and belong; we harness that instinct through visually striking placements, creator tools, and standards that make experiences easier to deploy, measure, and scale.

Practically, Defibillboards combines (1) parcel-anchored inventory, (2) a dApp that standardizes activations and links adjacent spaces into cohesive hubs, and (3) an access model in which Defibillboards NFTs function as credentials to ecosystem features (e.g., creator tools, gated experiences, campaign participation). Each parcel in our network is represented on Ethereum via non-fungible tokens, and serves as the substrate for content ranging from interactive storefronts to event spaces. By aligning placement, tooling, and interoperability, we enable campaigns that are discoverable by design and extensible across networks and devices. Throughout, references to reach, engagement, or participation describe functionality and access—not financial promises. Subsequent sections detail the problem context, solution architecture, products and services, token utilities, and governance needed to activate underused virtual land into coordinated, user-facing experiences.

4. Problem & Context

Despite years of interest and investment, much of the metaverse remains a patchwork of idle or underused parcels. Ownership is widespread, but the ability to build compelling destinations is not. Turning a blank plot into a living experience requires skills most holders don’t have—3D modeling, interaction design, optimization, scripting, wallet flows, and ongoing maintenance. Even motivated owners face platform constraints (asset limits, performance budgets), fragmented tools, and the burden of hosting and updates. The result is a long tail of parcels that display static art—or nothing at all—while a small number of sophisticated operators concentrate attention.

This fragmentation creates systemic issues for brands and creators:

• Low discoverability: Experiences are scattered and hard to find; traffic rarely flows across adjacent spaces without deliberate routing.
• Inconsistent quality & standards: Creative varies widely; there’s no common workflow for campaigns, analytics, or interoperability.
• High activation costs: Standalone builds are expensive, slow to launch, and fragile to platform changes.
• Unclear measurement: Without shared instrumentation, it’s difficult to compare engagement or iterate effectively across platforms.

The idle land problem is not merely aesthetic—it suppresses network effects. Empty parcels reduce the incentive to explore; low exploration depresses creator and brand interest; weak demand lowers the likelihood that small landholders will invest in development. Breaking this cycle requires (1) coordinated placement near high-traffic points, (2) a standardized activation layer that lowers the build/operate burden, and (3) interoperable tooling so content, access, and measurement work across networks and devices. The following sections describe how Defibillboards addresses these constraints with parcel-anchored inventory, a dApp coordination layer, and a utility-first access model. (See Legal Disclaimer & Availability Notice.)

5. Solution Overview (Defibillboards approach & differentiation)

Approach. Defibillboards turns underused virtual land into coordinated, user-facing experiences by combining (1) parcel-anchored inventory in high-visibility locations, (2) a dApp coordination layer that standardizes campaigns and links adjacent spaces into traversable hubs, and (3) an access model in which Defibillboards NFTs function as credentials for creator tools, gated experiences, and campaign participation. The platform provides turnkey workflows—from creative intake and asset publishing to routing, measurement, and iteration—so brands, creators, and landholders can launch faster with consistent quality. References to participation and engagement describe functionality and access, not financial returns. (See Legal Disclaimer & Availability Notice.)

How it works (end-to-end).

• Place: Deploy programmable placements on parcels near spawn points/POIs to maximize organic discovery.
• Activate: Use the dApp to configure scenes, schedule campaigns, and connect neighboring parcels into cohesive hubs.
• Measure: Instrument experiences with common events and dashboards to compare performance across platforms.
• Iterate: Swap assets, update logic, and re-route traffic without rebuilding from scratch.

What differentiates Defibillboards.

• Traffic by design: Inventory clustered around high-flow coordinates to improve baseline discoverability.
• Standardized activations: Reusable scene modules, asset schemas, and campaign playbooks reduce build/operate time.
• Interoperable tooling: Content, access rights, and measurement work across networks and devices.
• Creator/brand UX: Self-serve workflows for uploads, approvals, scheduling, and analytics—no 3D or scripting expertise required.
• Governable & auditable: On-chain representation of parcels and program states; clear operator permissions and revocation paths.
• Compliance-aware: Jurisdictional gating and feature flags to align availability with platform policy and local law.

Outcome. By aligning placement, tooling, and standards, Defibillboards reduces activation cost and variance, increases cross-experience traffic, and makes metaverse campaigns deployable, measurable, and repeatable—without positioning participation as a financial product.

6. Architecture

Defibillboards is built as a layered system that turns virtual parcels into programmable, measurable campaign surfaces while keeping ownership and permissions transparent on-chain. At a high level, four layers work together:

(A) Experience Layer (Metaverse Surfaces)
Scene files, 3D assets, and interactive logic render inside supported worlds (e.g., Decentraland and other platforms). Parcels act as placement surfaces for branded scenes, interactive units, and event spaces. Content modules are reusable and optimized for platform limits (mesh/poly budgets, scripts, asset streaming).

(B) Coordination Layer (dApp & Services)
A web dApp orchestrates campaigns across parcels: upload/approve assets, schedule activations, configure routing between adjacent parcels, and manage feature-gated experiences. Standard campaign schemas and event vocabularies ensure consistent setup and measurement across worlds and devices. Operator permissions are explicit and revocable.

(C) On-Chain Layer (Ownership, Access, References)

• Parcel Representation: Non-fungible tokens (NFTs) record parcel identities/rights on Ethereum; operator roles can be delegated by landowners using native platform controls.
• Access Credentials: Defibillboards NFTs function as credentials for creator tools, gated experiences, and campaign participation (non-financial utilities).
• Token Contracts (DBB): ERC-20 contracts provide on-platform utilities (e.g., credits, access rights, in-experience items). Contract addresses are publicly verifiable; bridging and liquidity design are covered in Section 8.
  All on-chain references are kept minimal and composable so scenes can be updated without redeploying contracts.

(D) Data & Observability Layer (Non-PII by design)
Unified client/server events (impressions, interactions, traversal, session markers) feed dashboards for comparative measurement. Data collection emphasizes minimalism and pseudonymous wallet context where relevant, with jurisdictional feature flags. Outputs power campaign reporting and iterative optimization—not financial projections.

Content Pipeline & Standards
Assets move through a pipeline: design intake → validation (format/Lint) → staging preview → publish. Interoperable asset schemas (naming, LODs, collider rules) and scene templates reduce variance and rework. Rollbacks and hot-swaps allow safe, fast iterations during live campaigns.

Security & Safety Controls

• Contract verification and explicit operator permissions; least-privilege keys for deployment.
• Asset signing and allowlists to prevent spoofed creatives.
• Runtime guards (rate limits, beacon checks) to protect scenes from abuse.
• Jurisdictional and platform feature flags to disable gated features where not permitted.
  Security posture favors transparency (auditable addresses, reproducible builds) and graceful degradation if a third-party service is unavailable.

Interoperability & Extensibility
The system exposes stable interfaces for: (1) asset ingestion, (2) campaign configuration, (3) metrics export, and (4) access checks. Partners can integrate via SDKs/webhooks without modifying core contracts. This keeps the platform extensible while preserving a consistent user and operator experience.

(References to access, credentials, or rewards describe functionality and in-platform utilities only. Availability varies by platform and jurisdiction; see Legal Disclaimer & Availability Notice.)

6.1 Parcel Representation (NFTs)

Each parcel in the Defibillboards network is represented as a non-fungible token (NFT) recorded on Ethereum to provide a durable, auditable reference for parcel identity and associated permissions. The NFT is not a promise of returns; it functions as a registry pointer and access primitive for coordinating experiences across supported metaverse platforms.

Scope of the NFT record.

• Identity & provenance: A unique token ID links to canonical parcel metadata (coordinates, platform, links to scene manifests, and operator status).
• Metadata & manifests: Off-chain URIs (e.g., IPFS/Arweave/HTTPS) reference scene descriptors, allowed asset bundles (GLB/GLTF), and campaign configuration schemas. Metadata is versioned to support rollbacks and hot-swaps during live campaigns.
• Operator delegation: Landowners retain ownership but can delegate operator rights to Defibillboards (or revoke them at any time) using native platform controls (e.g., Decentraland operator settings). Operator actions are constrained to publishing/updating allowed assets per policy.
• Access hooks: NFTs expose read-only hooks for the coordination layer to verify parcel status, ownership, and feature flags (e.g., whether gated experiences are enabled in a given jurisdiction).
• Composability: Parcel NFTs interoperate with creator tools and routing logic without requiring contract redeployments; scene updates occur at the manifest level, not the token contract.

Governance & safety.

• Least-privilege: Operator keys are scoped to asset publish/update and cannot transfer ownership.
• Auditability: Contract source is verified; changes to parcel metadata and operator assignments are logged and reviewable.
• Jurisdictional flags: Fields in metadata (or in the coordination layer) can disable gated features where not permitted by platform policy or law.

This representation keeps ownership clear, permissions explicit, and updates lightweight, enabling fast, reversible content deployment while preserving on-chain provenance and off-chain performance. (See Legal Disclaimer & Availability Notice.)

6.2 dApp Coordination Layer

The dApp is the orchestration plane that turns parcels into programmable campaign surfaces without requiring 3D or scripting expertise. It provides operator-grade workflows for asset intake, approval, scheduling, routing, and measurement, with explicit permissions and jurisdictional feature flags.

Core modules

• Asset Intake & Validation: Upload creatives (GLB/GLTF, textures, video), run automated checks (poly/tri counts, texture sizes, collider rules, script budgets), and preview scenes in a staging viewer. Validation reports block unsafe or non-compliant assets before publication.
• Campaign Composer: Define placements (which parcels), timings (start/stop, time windows), rotations (A/B or multi-variant), and triggers (on proximity, interaction, quest state). Campaigns are versioned and roll back safely.
• Parcel Routing & Hubs: Link adjacent parcels into cohesive hubs with guided paths, teleports, or POI beacons. Routing graphs can be edited visually and exported as manifests that scenes read at runtime.
• Access & Gating: Check wallet/NFT credentials to unlock creator tools, gated experiences, or participation features. Gating is utility-only (e.g., access rights, credits, in-experience items) and is disabled by policy where not permitted.
• Observability: Standardized event vocabulary (impressions, dwell, interactions, traversal) streams to dashboards for cross-platform comparison. Data is minimal, pseudonymous, and exportable for audits; no financial projections.
• Change Management: Draft → review → approve → publish workflow with roles (owner, operator, reviewer). Every publish creates an immutable release record; rollbacks and hot-swaps are first-class.
• Feature Flags & Jurisdictions: Toggle features by platform, geography, and policy (e.g., disable certain programs for New York State). Flags propagate to both UI and runtime manifests to prevent accidental exposure.

Permissions & safety

• Role-based access control (RBAC): Landowners grant or revoke operator rights. Within the dApp, fine-grained roles control who can upload, schedule, route, or publish.
• Least-privilege keys: On-chain interactions (operator assignment, metadata updates) use scoped signers; sensitive actions require multi-step confirmation.
• Content safeguards: Allowlists for domains/assets, signature verification for bundles, and integrity hashes embedded in manifests.

APIs & extensibility

• Manifests & Webhooks: Scenes consume signed manifests for placements/routing; partners subscribe to webhooks for campaign lifecycle events.
• SDKs: Lightweight clients for reading access state, logging events, and fetching scene configs across engines/frameworks.

Failure handling

• Graceful degradation if a third-party service is down (fallback assets, cached manifests).
• Automatic reverts on broken validation; alerting for expired schedules or missing dependencies.

The coordination layer standardizes how campaigns are built, launched, and measured across worlds and devices—reducing cost and variance while keeping ownership, permissions, and availability transparent and controllable. (See Legal Disclaimer & Availability Notice.)

6.3 Access & Controls (NFT features)

Defibillboards uses NFTs as credentials—not as financial instruments—to unlock utility-only features across the ecosystem. Access is enforced via wallet checks, role assignments, and jurisdictional feature flags that enable/disable capabilities by platform or geography.

Credential types (examples)

• Creator Pass (NFT): Grants access to creator tooling (asset upload, scene modules, staging sandboxes). Optional tiers (e.g., Standard/Pro) map to higher asset budgets, scheduling priority, or additional templates.
• Campaign Pass (NFT or allowlist): Permits brands/partners to configure placements, request routes, and view campaign dashboards for their allocations.
• Experience Badges (NFT/Soulbound): Non-transferable badges that unlock in-experience items, credits, or allowlisted activations. Badges can expire, downgrade, or be revoked for policy violations.
• Visitor Tokens (ephemeral): Short-lived proofs used to gate micro-features (e.g., teleport pads, quest steps) without creating permanent records.

What access can unlock (utility only)

• Tools: Creator dashboards, staging viewers, validation reports.
• Features: Gated experiences, scene variants, traversal shortcuts.
• Allowances: In-experience credits (e.g., ad-preview slots, asset bandwidth), campaign voucher usage, support tickets.
• Priority: Queue priority for reviews, scheduled publish windows, analytics refresh cadence.

Interaction-Earned Credits (Utility Only)

Certain NFTs may include digital assets that, when interacted with in supported virtual scenes, generate DBB “credits” for the holder or participant. These credits are consumptive utilities usable only within the Defibillboards environment (e.g., access rights, in-experience items, or campaign voucher allowances). They are not cash, are not redeemable for fiat or equivalents, and do not represent income, yield, dividends, or price appreciation. Availability varies by platform and jurisdiction; features are disabled where not permitted (e.g., for New York State residents). See Legal Disclaimer & Availability Notice.

How it works (policy & controls)

• Trigger: On-scene interactions (e.g., proximity, click, quest completion) emit a signed event.
• Eligibility: The dApp verifies credential status (NFT/badge/allowlist), jurisdiction flags, rate limits, and abuse heuristics.
• Issuance: If permitted, a non-transferable credit balance is incremented for the wallet.
• Use: Credits may be consumed for in-platform utilities (access, items, allocation vouchers).
• Limits & Safety: Per-wallet caps, cooldowns, anti-bot checks; credits may expire or be revoked for policy violations.

Key safeguards

• Jurisdictional gating: Features are off by default in restricted regions (e.g., NYS).
• Non-financial framing: Credits ≠ money; no promises of returns or appreciation.
• Abuse prevention: Cooldowns, proof-of-interaction checks, manifest integrity hashes, and allowlists.
• Transparency: Contract sources verified; credit rules published; audit trail for grants/redemptions.

Controls & governance

• RBAC + Policy Layers: NFT possession → base role (viewer/creator/brand). Fine-grained policy attaches limits (asset budgets, frequency caps, geography).
• Jurisdiction Flags: Feature availability toggled by location (e.g., disable certain programs in New York State). Flags propagate to UI and runtime manifests to prevent accidental exposure.
• Revocation / Expiry: Time-boxed entitlements; emergency revocation lists for compromised wallets or policy violations.
• Delegation: Optional, scoped delegation (e.g., an agency manages uploads for a brand) with explicit caps and expirations.
• Transparency: On-chain verification for contract sources; off-chain manifest signatures and integrity hashes for content bundles.

Safety & integrity

• Sybil/Abuse Mitigation: Rate limits, device/wallet heuristics, optional proof-of-humanity checks for high-value actions; challenge flows for suspicious behavior.
• Anti-Bot Claims: Cooldowns, allowlists, and per-wallet caps on credit/item redemptions.
• Privacy-respecting: Minimal, pseudonymous event logging; no unnecessary personal data; opt-out controls where platform policy allows.

Lifecycle

1. Issue → Mint/assign credential (NFT/badge/allowlist) to a wallet.
2. Check → Scenes/dApp verify entitlement via read-only calls or signed manifests.
3. Act → User consumes utilities (credits, feature access) within quota/policy.
4. Update → Usage counters and expirations sync to the coordination layer.
5. Revoke/Expire → Automatic sunset or manual revocation; audit trail preserved.

This access model keeps ownership with the user, makes permissions auditable and revocable, and ensures gated features remain utility-focused and compliance-aware across platforms and jurisdictions.

6.4 Security & Verification (contract addresses)

Security is enforced through transparent, verifiable contracts, least-privilege operations, and clear user-side verification steps. Contract references are provided for auditability only and do not imply listings, price outcomes, or availability in any jurisdiction. (See Legal Disclaimer & Availability Notice.)

Official contract addresses (verify before use)

• Ethereum (L1) — DBB Token (liquidity side)
  Address: 0x1c6a09d955033f4762ecf37f9c74ddf99cd1693c
  Deployment date: September 24, 2025
  Role: Canonical L1 token used for DBB/ETH liquidity and bridging to L2 for utility.
• Base (L2) — DBB Token (utility side)
  Address: 0x08ad71edd154a4150a1352d0e874dd3be3c0d671
  Role: On-platform utilities on Base (e.g., access credits, in-experience items, feature gating).

Always validate these addresses on the relevant explorers (Etherscan/BaseScan) and by checking the verified source code, compiler settings, and contract metadata. Do not rely on screenshots or third-party links.

Recommended user verification steps

1. Copy addresses from this document, not from DMs/social replies.
2. Open the explorer (Etherscan for L1, BaseScan for L2) and paste the address.
3. Confirm:
   • Contract (not EOA) status and Verified source-code badge.
   • Name/Symbol/Decimals match the docs.
   • Read/Write tabs expose expected ERC-20 functions only (plus any disclosed extensions).
4. If adding the token to a wallet, paste the address (don’t search by name) and cross-check the checksum.

Operational security & permissions

• Least-privilege keys: Deployment and operator keys are scoped; no unnecessary admin powers.
• Revocability: Operator permissions (e.g., for parcel publishing) are explicit and revocable by owners.
• Change management: Any contract upgrades (if applicable) or parameter changes are disclosed in release notes and signed announcements.
• Bridging parity: Bridging follows the canonical mechanism; supply on L2 reflects L1 movements as designed. Parameters (e.g., windows/fees) are determined by the bridge and may change.

Abuse & phishing safeguards

• We do not distribute tokens via unsolicited DMs, Telegram groups, or reply-thread links.
• Be cautious of “support” accounts requesting seed phrases or signing blind transactions.
• Only interact with interfaces you trust; when in doubt, use the explorer’s Write functions with a hardware wallet.

Responsible disclosure

Security researchers can report vulnerabilities through our published contact channels. Good-faith reports will be reviewed and acknowledged; do not publish exploit details before coordinated remediation.

This section describes how to verify and interact safely. It does not constitute an endorsement of any particular interface or guarantee of performance or availability.

7. Products & Services

Defibillboards provides an end-to-end stack for launching discoverable, measurable experiences in the metaverse—combining high-visibility parcel inventory with creative production and standardized campaign operations. Offerings are organized into three pillars:

• Billboard Network & Land Activation (Section 7.1): We operate a curated network of parcels—clustered near spawn points and POIs—and provide a hands-on activation service that turns idle plots into live scenes and campaign surfaces. Landowners retain ownership and can delegate/revoke operator rights at any time. “Land Farming” refers to coordinated setup, content updates, and routing across adjacent parcels to form cohesive hubs; it does not imply financial returns.
• Creative & Technical Services (Section 7.2): An in-house studio delivers the assets and logic required for immersive placements: brand design, 3D models (GLB/GLTF), scene modules, interaction scripts, and performance optimization. Deliverables pass through a validation pipeline (budgets, LODs, colliders, texture rules) and preview staging to ensure quality and portability across platforms.
• Campaign Workflows & Analytics (Section 7.3): A dApp coordinates uploads, approvals, schedules, rotations, parcel routing, and de-publishes; it also standardizes event vocabularies (impressions, dwell, interactions, traversal) for cross-platform reporting. Feature flags and policy controls manage jurisdictional availability and platform-specific differences. Dashboards are designed for iterative optimization—not financial projections.

What this enables. Brands and creators can launch faster with consistent quality; landowners can keep parcels active without learning 3D pipelines; and participants encounter experiences that are discoverable by design. All gated features unlocked by credentials (e.g., Creator Pass) are utility-only (access, credits, in-experience items). Availability and specifics vary by platform and jurisdiction; see Legal Disclaimer & Availability Notice.

7.1 Billboard Network & Land Activation (“Land Farming”)

Purpose. Turn idle or underused parcels into live, discoverable experiences by clustering placements near spawn points/POIs and coordinating content across adjacent parcels into cohesive hubs. “Land Farming” refers to the coordinated setup, publishing, routing, upkeep, and measurement of scenes on participating land—not to financial farming or yield programs. (See Legal Disclaimer & Availability Notice.)

What landowners get (utility-only)

• Operator service (revocable): You retain ownership and delegate operator rights to Defibillboards via native platform controls. Permission can be revoked at any time.
• Managed placements: We deploy scene modules (billboards, interactive units, event spaces) and keep them updated against platform limits (poly budgets, scripts, LODs).
• Traffic routing: Parcels are linked with guided paths/teleports to form local hubs; routing graphs can be adjusted seasonally or per campaign.
• Quality & compliance: All assets pass validation (formats, sizes, colliders, performance). Jurisdictional feature flags prevent disallowed functionality from appearing.
• Reporting: Standard dashboards (impressions, dwell, interactions, traversal) for comparative performance—no financial projections.

What we need from landowners

• Operator delegation: Add Defibillboards as operator (not owner).
• Parcel basics: Coordinates, platform, any scene constraints (height, collisions, reserved areas).
• Policy alignment: Agreement to content standards and takedown policy; acknowledgement of jurisdictional gating (e.g., NY restrictions).

Activation flow

1. Enroll → Landowner requests activation and delegates operator rights.
2. Survey → We assess parcel constraints and nearby POIs; assign scene modules.
3. Stage → Assets pass validation; preview in staging viewer for approval.
4. Publish → Go live with signed manifests; routing links to neighboring hubs.
5. Measure & iterate → Metrics inform creative swaps, rotations, and routes.
6. Maintain → Periodic updates for platform changes, events, or partner campaigns.
7. Revoke (optional) → Landowner can revoke operator rights at any time; content is removed gracefully.

Content types we deploy

• Static & animated billboards (image/video) with performance-safe codecs.
• Interactive ad units (click-to-expand, mini-games, quest tie-ins).
• Event modules (stages, pop-ups, info kiosks).
• Wayfinding (beacons, teleports, path signage) to knit parcels into hubs.

Standards & safeguards

• Asset policy: Format (GLB/GLTF), triangle/texture budgets, collider rules, and script budgets; integrity hashes on bundles.
• Change control: Draft → review → approve → publish; every release is versioned and reversible.
• Safety & abuse: Allowlists, rate limits, and content moderation; emergency de-publish switch.
• Jurisdictional gating: Feature flags disable restricted programs by geography (e.g., New York State).

Participation notes

• Non-financial utilities: Any engagement-based allowances (e.g., credits, access rights, in-experience items) are for use within the environment only and are not income, yield, or price promises.
• No custody: We never require private keys; operator actions are limited to publishing scene updates on your parcel.
• Exit-friendly: You can end participation by revoking operator status; no lock-ins.

This managed activation model reduces the time-to-live, raises baseline discoverability, and keeps parcels fresh and policy-aligned—so small landholders can participate alongside sophisticated operators without taking on a full 3D pipeline.

7.2 Creative & Technical Services

Defibillboards provides a full-stack studio that designs, builds, and maintains immersive placements and scenes—so brands and creators can ship high-quality experiences without owning a 3D pipeline. Deliverables are portable across supported platforms and pass a strict validation + QA process before going live.

What we deliver

• Brand & Visual Design: Identity kits, motion assets, billboard creative, campaign systems (layout, typography, color, animation specs).
• 3D Assets & Scenes: Optimized GLB/GLTF models, PBR textures, LODs, lightmaps, collision meshes; modular scene blocks (billboards, kiosks, stages, mini-games).
• Interaction & Game Logic: Proximity triggers, dialogue/quest flows, collectibles, wayfinding; safe script budgets aligned with platform constraints.
• Web & Companion Surfaces: Microsites, QR-to-web flows, claim pages, and dashboards that extend in-world campaigns to mobile/desktop.
• Instrumentation: Standard event hooks (impressions, dwell, interactions, traversal, conversions-to-web) for cross-platform analytics.
• Localization & Accessibility: Copy frameworks, alt text, legibility checks, color-contrast and motion-sensitivity options.

Production pipeline (quality by design)

1. Creative Brief & Scope → goals, KPIs, brand guardrails, target platforms, jurisdictions.
2. Prototyping → graybox scene + interaction map; motion/UX tests.
3. Build → asset creation, retopo/UV, script implementation, LODs, lightmaps.
4. Validation → automated checks (poly/tri counts, texture sizes, collider rules, script limits), integrity hashes, dependency audit.
5. Staging → hosted preview with stakeholder review; performance & UX QA.
6. Publish → signed manifests pushed via the dApp; rollback point created.
7. Monitor & Iterate → dashboards, A/B rotations, hot-swap creatives as needed.

Technical standards (portable + performant)

• Formats: GLB/GLTF (primary), PNG/JPG/WebP textures, MP4/WebM video where supported.
• Budgets: Per-platform triangle/texture/script budgets; target 60 FPS on reference hardware.
• Optimization: LOD chains, occlusion, atlasing, baked lighting where allowed; streaming-friendly sizes.
• Security: Asset signing, domain allowlists, no remote code execution; least-privilege operator keys.
• Interoperability: Content schemas and manifest contracts designed to travel across engines and networks.

Campaign services

• Creative Variants & A/B Testing: Multi-variant rotations with holdouts; statistical readouts for dwell/interaction deltas.
• Seasonal & Event Programming: Timed swaps, limited-run scenes, tie-ins to real-world launches.
• Wayfinding & Hub Design: Beaconing, routing graphs, teleports to knit adjacent parcels.
• Brand Safety & Compliance: Content moderation, rights clearance, takedown workflows, and jurisdictional feature flags (e.g., auto-disable restricted features for New York State).

Handover & ownership

• Source Packages: Final GLB/GLTF, textures, scripts, and manifests delivered in a versioned repo or archive.
• IP & Licensing: Custom work-for-hire or licensing models per SOW; third-party assets documented and licensed.
• Operator Independence: Landowners can revoke Defibillboards operator status at any time; scenes degrade gracefully.

Support & SLAs (examples; finalized per SOW)

• Response/Resolution: Business-hours response with defined severity tiers; optional 24/7 for live events.
• Uptime: Best-effort CDN and preview hosting; clear fallbacks if a third-party service degrades.
• Change Windows: Safe-deploy windows, preflight checklists, instant rollback on critical regressions.

What this is not

• No financial promises. Creative services and scene deployments provide utility and access (discoverability, engagement), not financial returns or price guarantees.
• Availability varies. Features differ by platform and jurisdiction and may change over time. (See Legal Disclaimer & Availability Notice.)

This studio model lets brands and creators ship faster with confidence—high-quality assets, measured outcomes, and repeatable workflows that respect platform limits, security, and compliance.

7.3 Campaign Workflows & Analytics

Defibillboards standardizes how campaigns are planned, launched, measured, and iterated across supported worlds. The workflow is designed to reduce time-to-live, keep quality consistent, and provide comparable metrics—without financial projections. (Availability varies by platform and jurisdiction; see Legal Disclaimer & Availability Notice.)

A. End-to-End Workflow

Brief & Objectives

• Inputs: goals, target audiences, success criteria (e.g., visits, dwell, interactions, click-through to web), platforms, jurisdictions, timelines.
• Outputs: campaign spec, measurement plan, approval matrix.

Creative & Asset Intake

• Upload brand assets (images/video/GLB/GLTF), copy, CTAs.
• Automated validation: tri/texture budgets, collider rules, script limits, file integrity hashes.

Configuration in the dApp

• Placements: select parcels/hubs; proximity to spawn/POIs.
• Scheduling: start/stop, time-of-day windows, calendar overrides.
• Rotation: A/B or multi-variant, frequency caps, pacing.
• Targeting (where supported): world, device class, language.
• Feature flags: enable/disable gated features per jurisdiction (e.g., NY restrictions).

Staging & QA

• Scene preview in staging; performance and UX checks; link/QR tests; accessibility (contrast/motion).
• Sign-off recorded in the release record.

Publish & Monitor

• Signed manifests deployed; canary placements optional.
• Real-time dashboards for impressions, dwell, interactions, traversal, outbound actions.

Optimize & Iterate

• Swap assets, adjust routes, rebalance rotations, or modify schedules; all changes versioned and reversible.

Closeout & Archive

• Export reports, asset/package handover, annotated learnings for future runs.

B. Roles & Approvals

• Brand/Creator: provides assets & goals; reviews staging; owns external links.
• Operator (Defibillboards): configures placements, routing, and schedules; ensures compliance.
• Reviewer: signs off on creative, legal text, and geo policy (especially NY gating).
• Observer (optional): read-only access to dashboards and logs.

RBAC ensures only the right people can upload, schedule, or publish; approvals are timestamped and auditable.

C. Event Taxonomy (standardized, non-PII)

• Impression: asset enters view frustum above visibility threshold.
• Viewable Impression: sustained visibility (e.g., ≥2s).
• Dwell: cumulative time in parcel/scene segment.
• Interaction: clicks, proximity triggers, item pickups, quest steps.
• Traversal: teleports/paths followed to another parcel or hub node.
• Outbound Action: QR/open-link, allowlisted wallet action.
• Error/Guard: blocked loads, rate-limit hits, policy-flagged events.

Events carry: timestamp, world/platform, parcel ID, creative variant ID, session nonce, device class, and jurisdiction flag. Wallet context is optional and pseudonymous (no seed/private data ever collected).

D. KPIs & Reporting

• Reach & Exposure: unique sessions, impressions, viewable impressions.
• Quality of Attention: average dwell, attention rate (viewable/total), interaction rate.
• Pathing: traversal flows between parcels/hubs; drop-off analysis.
• Engagement Outcomes: interaction completions, allowlisted claims, outbound actions.
• Operational Health: asset load failures, FPS buckets, guardrail triggers.

Dashboards highlight deltas between creative variants, parcels, and time windows; exports (CSV/JSON) support deeper analysis.

E. A/B & Multi-Variant Testing

• Design: define control vs. variants, exposure weights, and minimum sample thresholds.
• Execution: rotation rules ensure even delivery; holdouts protect baseline.
• Readout: report effect sizes on dwell/interaction/outbound actions with confidence bands; auto-promote winners or continue exploration.

F. Frequency, Pacing & Fairness

• Frequency caps per session/device/wallet to avoid fatigue.
• Pacing (even or front-loaded) over campaign dates.
• Priority rules for critical campaigns; back-pressure if resource budgets are reached.

G. Jurisdictional Controls

• Feature flags disable gated or sensitive features where not permitted (e.g., New York State).
• Geo signage: optional inline “Availability Notice” overlay when features are disabled.
• All geo decisions are logged with reasons in the release record.

H. Data Handling & Privacy

• Minimal collection: no personal data beyond pseudonymous session/wallet context; no seed phrases, no custody.
• Retention: configurable retention windows; aggregation for long-term benchmarking.
• Access: role-based; signed exports; API keys scoped and revocable.

I. Integrity & Safety

• Signed manifests and integrity hashes for asset bundles.
• Allowlist of domains and third-party endpoints; no remote code execution.
• Abuse protection: rate limits, bot heuristics, anomaly alerts; emergency de-publish.

J. Deliverables

• Live dashboards (campaign → parcel → creative variant).
• Weekly summaries (or per-milestone) with insights and recommended changes.
• Closeout report: KPI performance, learnings, assets & configuration snapshot, and next-run playbook.

What this is not: Analytics are provided for operational measurement and optimization. Reports do not include financial projections, investment advice, or promises of results. Availability and features vary by platform and jurisdiction; see Legal Disclaimer & Availability Notice.

8. Token (DBB) — Utility & Mechanics

Purpose. DBB is the ecosystem’s utility token used to power on-platform features—such as access credentials, in-experience credits/items, campaign voucher allowances, and configuration rights—in supported metaverse experiences and the Defibillboards dApp. DBB is not positioned or marketed as an investment and does not promise income, yield, dividends, or price appreciation. (See Legal Disclaimer & Availability Notice.)

Design summary.

Two-layer model:

• Ethereum (L1) DBB is the canonical, liquidity-facing side used for market access and bridging.
• Base (L2) DBB is the utility side used for day-to-day ecosystem actions with lower fees and faster confirmations.

Bridging direction & rationale: ETH → Base bridging is emphasized to encourage actual utility usage on L2 and mitigate early-stage volatility on L1. Parameters may evolve as liquidity depth and security posture mature.

Contract transparency: Official addresses are publicly verifiable (see 6.4 Security & Verification and 8.3 Contract Addresses & Verification). Users should always verify addresses on Etherscan/BaseScan before interacting.

What DBB does (utility only).

• Access & Gating: Acts as a credential or balance check to unlock creator tools, scene variants, QA/staging environments, and campaign configuration rights (subject to RBAC and policy).
• In-Experience Credits/Items: Represents consumptive balances used for on-platform actions (e.g., claim a scene slot, redeem an item, use a traversal shortcut, or apply a campaign voucher). Credits/items are not cash and are not redeemable for fiat or equivalents.
• Campaign Operations: Pays metered allowances (e.g., asset bandwidth, preview rotations) or deposits for limited resources (e.g., high-traffic placement windows), refundable/consumptive per policy.
• Interaction-Earned Credits: Certain NFTs can emit DBB credits on user interaction in supported scenes (rate-limited, jurisdiction-gated). Credits are non-transferable utilities for in-platform use only (see 6.3).

What DBB does not do.

• No promise of profits, yield, dividends, or price effects.
• No exchange/listing promise or implied liquidity outcomes.
• No availability in restricted jurisdictions or where platform policy disallows features (e.g., New York State limitations).

Controls & compliance.

• Jurisdictional feature flags: Program availability varies by location and platform; restricted features are disabled by policy (e.g., NY State).
• RBAC & quotas: Role-based access, frequency caps, per-wallet limits, and abuse heuristics protect allocations and prevent exploitation.
• Privacy-respecting telemetry: Only minimal, pseudonymous event data for operational measurement (no seed phrases; no custody).

Security posture.

• Verified contracts & least-privilege keys: Contract sources verified on explorers; deployment/ops keys scoped to essential functions.
• Bridging parity & audits: Supply parity is enforced by the canonical bridge design; any audits, release notes, or parameter changes are published and signed.
• User safeguards: Interact only with official addresses and trusted interfaces; never sign blind transactions.

Where to find specifics.

• 8.1 On-Platform Utilities — concrete utilities and example flows.
• 8.2 Liquidity Design & Bridging (ETH → Base) — rationale, guardrails, and lifecycle.
• 8.3 Contract Addresses & Verification — official addresses and verification steps.
• 8.4 Jurisdictional Notes — availability by region and policy references.

Reference:
Ethereum (L1) — DBB (liquidity side): 0x1c6a09d955033f4762ecf37f9c74ddf99cd1693c (deployed Sept 24, 2025).
Base (L2) — DBB (utility side): 0x08ad71edd154a4150a1352d0e874dd3be3c0d671.
Verify on Etherscan/BaseScan before use. Availability and features vary; see Legal Disclaimer & Availability Notice.

8.1 On-platform Utilities

DBB powers consumptive, in-environment utilities across supported metaverse worlds and the Defibillboards dApp. These utilities unlock access, features, and allowances used to configure, operate, and experience campaigns. They are not cash, are not redeemable for fiat or equivalents, and do not confer income, yield, dividends, or price appreciation. (Availability varies by platform and jurisdiction; see Legal Disclaimer & Availability Notice.)

A. Utility Categories

• Access & Credentials
  • Unlock creator tooling (upload, staging, validation reports).
  • Open scene variants, QA sandboxes, and parcel routing editors.
  • Assign limited configuration rights to collaborators (scoped & time-boxed).
• Operational Allowances
  • Asset allowances: bandwidth/bundle slots for GLB/GLTF, video, textures.
  • Placement allowances: request windows in high-traffic parcels/hubs.
  • Preview/rotation credits: run A/B variants or seasonal swaps within quotas.
  • Support allowances: priority tickets, review fast-track, scheduled publish windows.
• In-Experience Items & Effects
  • Temporary traversal shortcuts, access passes, scene power-ups (non-transferable).
  • Cosmetic items tied to a specific activation (time-limited where applicable).
  • Quest keys or collectibles that unlock subsequent steps/content.
• Campaign Vouchers (Utility Only)
  • Single-use vouchers to claim a scene slot, reserve a billboard template, or redeem a creative review cycle.
  • Vouchers burn on use; no secondary market obligation.
• Interaction-Earned Credits (see §6.3)
  • Certain NFTs include interactive assets; when users engage in supported scenes, DBB credits can accrue (rate-limited, jurisdiction-gated).
  • Credits are non-transferable balances consumed for utilities above (e.g., placement vouchers, preview rotations, access to a scene variant).

B. Example Flows

For a Brand

1. Acquire a Campaign Pass (credential).
2. Spend DBB to allocate placement allowances in a POI hub and mint vouchers for a 4-week rotation.
3. Use DBB for preview credits to run two creative variants.
4. Review dashboards; swap the winning asset using remaining allowances.

For a Creator

1. Hold a Creator Pass to unlock the upload & staging toolchain.
2. Use DBB to purchase asset allowances (extra bundle slots, higher LOD budgets within limits).
3. Redeem a support allowance to fast-track approval ahead of an event.

For a Landowner

1. Delegate operator rights to Defibillboards (ownership retained).
2. Receive vouchers/credits earmarked for wayfinding beacons and scene upkeep.
3. Use DBB to request routing updates that link to a neighbor’s event hub.

For a Participant

1. Interact with an approved in-scene object; system mints interaction-earned credits to the wallet (if permitted).
2. Spend credits for a time-limited teleport pass or access to a variant scene during the campaign window.

C. Controls, Limits, and Safety

• RBAC & Scopes: Utilities are gated by role (viewer/creator/brand/operator) and scoped (which parcels, which dates, how many uses).
• Quotas & Caps: Per-wallet limits, cooldowns, and frequency caps prevent spam and ensure fair access.
• Expiry: Credits, vouchers, and items may expire; unspent balances can be reclaimed by policy (posted in dApp docs).
• Jurisdictional Flags: Certain utilities (e.g., interaction-earned credits) are disabled where not permitted (e.g., New York State).
• Auditability: Every grant/spend creates a signed ledger entry tied to a release/campaign record.

D. What Utilities Do Not Imply

• No promise of revenue share, “APY,” or price effects.
• No guarantee of listings or market liquidity.
• No availability in restricted geographies or where platform policy disallows features.

E. Developer Notes (Interoperability)

• Read APIs: Check wallet entitlements, quotas, and feature flags; retrieve signed scene manifests.
• Write APIs (scoped): Consume a voucher, decrement credits, request a rotation; all writes require signed intents and pass rate-limit checks.
• SDKs: Lightweight clients for engines/frameworks to fetch placements, log events, and honor feature flags.

In summary, DBB functions as the operational fuel for access, allowances, and in-experience utilities that make campaigns deployable and measurable—without conferring financial rights or expectations.

8.2 Liquidity Design (Kernel) & Bridging (ETH → Base)

Purpose. Separate market-facing liquidity from low-cost utility so DBB is easy to use in-world (L2) while remaining transparently tradable on a major settlement layer (L1). This section describes system functionality only and does not imply price effects, returns, listings, or availability in any jurisdiction. (See Legal Disclaimer & Availability Notice.)

A. Two-Layer Model

L1 (Ethereum) — Liquidity Side (“Kernel”)
The Ethereum DBB contract serves as the canonical market interface and supports an L1 liquidity pool (e.g., DBB/ETH). Hosting primary liquidity on L1 provides broad tool/exchange compatibility and an auditable source of truth for total supply and transfers.

L2 (Base) — Utility Side
The Base DBB contract is optimized for day-to-day utilities—access checks, in-experience credits/items, campaign vouchers, and dApp allowances—benefiting from lower fees and faster confirmations.

Official contract addresses (verify before use):

• Ethereum (L1) — DBB (liquidity): 0x1c6a09d955033f4762ecf37f9c74ddf99cd1693c (deployed Sep 24, 2025)
• Base (L2) — DBB (utility): 0x08ad71edd154a4150a1352d0e874dd3be3c0d671

(Also listed in §6.4 and §8.3. Always verify on Etherscan/BaseScan.)

B. Bridging Direction & Rationale

Primary flow: ETH → Base.
Users acquire DBB on Ethereum and bridge to Base to use utilities with lower fees. Emphasizing L1→L2 flow helps mitigate early-stage volatility, discourage short-term speculation, and encourage real in-world usage.

Supply parity & accounting.
The bridge enforces a burn/mint or lock/mint mechanism so circulating supply remains coherent across layers. Bridge parameters (windows, fees, minimums) follow the underlying canonical bridge and may change over time.

Adjustable posture.
Bridging directions, rate limits, and allowlists/denylists may be tuned as liquidity depth, security reviews, and platform policies evolve. Any material changes will be documented in signed release notes.

C. Kernel Operations (L1 Liquidity)

• Pool composition. DBB paired with ETH (or a major stable/ETH pair, per venue) enables transparent price discovery.
• Risk controls. Liquidity management is discretionary and may be adjusted; no price guarantees, floors, or backstops are promised.
• Separation of concerns. L1 liquidity operations are logically separate from L2 utility functions. No utility entitlement depends on market price.

D. User Flow (Illustrative)

1. Acquire DBB on L1 via a venue of the user’s choice (if available in their jurisdiction).
2. Bridge to L2 (Base) using the supported bridge.
3. Use utilities on L2: access credentials, allowances, vouchers, and in-experience items.
4. Optional: Bridge back to L1 per bridge policy (if/when enabled).

E. Guardrails & Disclosures

• No financial promises. Liquidity design does not constitute an offer, listing, or price commitment.
• Jurisdiction gating. Bridging and certain utilities may be disabled or restricted (e.g., New York State).
• Verification first. Interact only with the official addresses above; never rely on screenshots or third-party links.
• Security posture. Contracts are verified; operational keys are least-privilege. Changes to bridge or pool parameters are announced via signed releases.

This architecture keeps trading and usage concerns cleanly separated: L1 for transparent liquidity and L2 for practical, low-cost participation in the Defibillboards ecosystem.

8.3 Contract Addresses & Verification

The following smart contracts are the only official DBB contracts referenced by this white paper. They are provided for transparency and auditability and do not imply exchange listings, price outcomes, or availability in any jurisdiction. Always verify on-chain details yourself. (See Legal Disclaimer & Availability Notice.)

Official addresses (verify before use)

• Ethereum (L1) — DBB Token (liquidity side / “Kernel”)
  0x1c6a09d955033f4762ecf37f9c74ddf99cd1693c
  Deployed: September 24, 2025
  Role: Canonical L1 token used for DBB/ETH liquidity and bridging to Base for utility.
• Base (L2) — DBB Token (utility side)
  0x08ad71edd154a4150a1352d0e874dd3be3c0d671
  Role: On-platform utilities on Base (e.g., access credits, in-experience items, feature gating).

Tip: Copy/paste addresses from this document. Do not rely on search-by-name in wallets or on social media posts.

How to verify (recommended steps)

1. Open the explorer
   • L1: Etherscan (Ethereum)
   • L2: BaseScan (Base)
2. Paste the address and confirm:
   • The page shows a Contract (not an EOA).
   • Source code is Verified (badge visible).
   • Name/Symbol/Decimals match documentation.
   • Read/Write tabs expose standard ERC-20 functions only (plus any disclosed extensions).
3. Check metadata
   • Compiler settings and contract metadata are published.
   • If a proxy pattern is used (not expected here), the implementation address is visible and verified.
4. Add to wallet (optional)
   • Add by contract address (never by name), then cross-check the checksum.

Integrity & change management

• Release notes: Any material change (e.g., bridge parameters, pool venue) will be documented in signed release notes.
• Least-privilege keys: Deployment/ops keys are scoped; no unnecessary admin powers.
• Bridging parity: Bridging is designed to keep supply coherent across L1/L2; parameters follow the underlying canonical bridge.

Phishing & scam safeguards

• We do not distribute tokens or bridge links via unsolicited DMs, reply threads, or unofficial groups.
• Never share seed phrases or sign unreadable transactions.
• When in doubt, interact via the explorer’s Read/Write as Proxy interfaces using a hardware wallet.

For convenience, these addresses are also listed in §6.4 Security & Verification and compiled with explorer references in Appendix C: Contract Links & Proofs.

8.4 Jurisdictional Notes (pointer to Legal)

Availability varies by platform and jurisdiction. Certain utilities, credentials, interaction-earned credits, and bridging flows may be limited, modified, or disabled based on local law, platform policy, or partner requirements. Features described in this paper are functional utilities (e.g., access rights, in-experience items, vouchers, operational allowances) and are not financial products.

New York State. Defibillboards is not licensed by the New York State Department of Financial Services to conduct “virtual currency business activity.” Accordingly, Defibillboards does not offer, sell, exchange, transmit, or provide staking, yield, revenue-sharing, or similar programs to New York State residents. Where necessary, gated features (including interaction-earned credits) are disabled by default for NYS users.

General gating policy. The dApp enforces feature flags by geography and platform. If a feature is restricted in your region, the UI and scene manifests will reflect that status and prevent access. Parameters, eligible users, and supported venues may change without notice.

User responsibility. Participants are responsible for understanding and complying with applicable laws and platform policies in their jurisdiction, including tax obligations arising from digital asset use. Nothing herein is legal, financial, or tax advice.

For the full statement, definitions, and risk disclosures, see the “Legal Disclaimer & Availability Notice” at the front of this document.

9. Participation Programs (Non-Financial; jurisdiction-gated)

Purpose. Participation programs encourage creation, curation, and exploration across the Defibillboards ecosystem using utility-only entitlements (access, credits, vouchers, items). These programs are not financial products and do not provide income, yield, dividends, or price appreciation. Availability varies by platform and jurisdiction; restricted features are disabled by policy (e.g., New York State). (See Legal Disclaimer & Availability Notice.)

9.1 Program Types (utility only)

• Creator Tools Access
  Credentialed creators (e.g., Creator Pass) unlock upload pipelines, staging viewers, validation reports, and scene templates. Higher tiers may map to expanded asset budgets or priority review windows.
• Campaign Vouchers & Operational Credits
  Single-use vouchers and operational credits allocate scarce resources (e.g., high-traffic placement windows, extra preview rotations, bandwidth/asset slots). Vouchers burn on use; balances may expire per policy.
• Interaction-Earned Credits (see §6.3, §8.1)
  Certain approved in-scene assets emit DBB credits on user interaction (e.g., proximity, quest completion). Credits are non-transferable and redeemable only for in-platform utilities (access rights, items, routing allowances). Jurisdictional and rate-limit safeguards apply.
• Access Badges (Soulbound/Non-transferable)
  Badges unlock gated experiences, quests, or creator tools. Badges may expire, downgrade, or be revoked for policy violations or abuse.
• Allowlisted Activations
  Time-boxed allowlists grant priority entry to limited-capacity scenes, demos, or creator showcases. Slots are managed via vouchers and feature flags.

9.2 Eligibility & Gating

• Credentials: Participation requires a compatible wallet and, where applicable, a Defibillboards credential (e.g., Creator Pass, Campaign Pass, Badge).
• Jurisdiction: Feature flags enforce geography-based policies; NYS-restricted features remain off by default.
• Platform/Partner Rules: Some utilities are only available on specific worlds or venues per partner policy.

9.3 Issuance & Consumption (mechanics)

1. Grant — User receives a voucher/credit/badge via the dApp or in-scene action (subject to allowlists, cool-downs, and abuse heuristics).
2. Verify — Scenes and services check wallet credentials, jurisdiction flags, quotas, and integrity hashes.
3. Consume — User redeems the utility (e.g., claim a placement slot, open a variant scene, use a traversal shortcut).
4. Record — A signed ledger entry updates balances and campaign records.
5. Expire/Revoke — Utilities may auto-expire; violations trigger revocation with an audit trail.

9.4 Safeguards & Fair-Use

• Rate Limits & Caps: Per-wallet/session limits, cool-downs, and frequency caps prevent spam and hoarding.
• Anti-Bot & Abuse Controls: Interaction proofs, anomaly detection, and challenge flows for suspicious activity.
• Privacy: Minimal, pseudonymous telemetry; no seed phrases or custody; opt-outs where platform policy allows.
• Content & Conduct: Brand-safety and community guidelines govern eligibility; violations may suspend or revoke access.

9.5 Transparency & Governance

• Published Rules: Program parameters (eligibility, quotas, expiry windows) are documented in the dApp and may change with release notes.
• Auditability: All grants, redemptions, and revocations are logged and exportable for review.
• No Financial Promises: Programs are designed for consumptive use only and do not imply returns, price effects, or listings.

9.6 Examples (illustrative)

• A brand redeems campaign vouchers to schedule a 4-week rotation in a POI hub and uses preview credits for A/B testing.
• A creator unlocks the staging toolchain, uses operational credits for extra bundle slots, and receives a badge granting event-week priority publishing.
• A participant completes a quest, earns interaction-based credits, and spends them on a time-limited teleport pass to a showcase scene (if permitted in their jurisdiction).

These programs convert engagement into usable access and capabilities—not financial rewards—so stakeholders can build, explore, and iterate responsibly within the Defibillboards ecosystem.

10. Marketing Strategy & Go-To-Market (GTM)

Positioning. Defibillboards is the coordination layer for metaverse activations—turning fragmented parcels into discoverable, measurable hubs for brands and creators. We sell operational outcomes (fast launch, consistent quality, comparable metrics), not speculation or financial instruments.

10.1 Audiences & Value Props

• Brands & Agencies: Rapid launch of immersive campaigns with standardized workflows, analytics, and brand-safety controls.
• Creators & Studios: Tools, templates, and distribution (near POIs) to showcase work and collaborate with brands.
• Landowners: Hands-off parcel activation via operator delegation; scenes stay live and policy-aligned.
• Platform/Infra Partners: Interoperable content standards, SDKs, and routing that increase world-level engagement.

10.2 Channels

• Direct: Account-based outreach to brands/AGencies; solution workshops and pilot briefs.
• Creator Partnerships: Onboard 3D artists and micro-studios with a Creator Pass path and published templates.
• Ecosystem Alliances: Platform and infra partners (engines, wallets, analytics) for co-marketing and technical distribution.
• Content & Proof: Case studies, walkthrough videos, and public staging links that show live activations (no proprietary media needed).
• Community: Dev talks, office hours, and template drops timed to platform events.

10.3 Offer Structure

• Starter Pilots (Playbooks): Fixed-scope packages (e.g., “Billboard + Wayfinding,” 4-week rotation, two creative variants) with clear inputs/outputs.
• Managed Activations: End-to-end production and operations for seasonal or event-driven campaigns.
• Creator Studio: Asset commissions and white-label scene modules built against our validation pipeline.
• Self-Serve (Roadmap): dApp access for credentialed partners to configure placements, rotations, and reports within quotas.

Pricing and availability vary by platform and jurisdiction; programs deliver utilities and services (access, assets, operations), not financial returns. See Legal Disclaimer & Availability Notice.

10.4 Growth Loops

• Discovery Loop: POI-adjacent placements → higher baseline traffic → better campaign outcomes → more brand demand → more active parcels.
• Creator Loop: Templates + distribution → faster launches → more showcases → brand collaborations.
• Standards Loop: Shared schemas + dashboards → comparable results → repeatable playbooks → lower activation friction.

10.5 Signature Campaigns (Illustrative)

• Scavenger Hub: Multi-parcel quest linking brand scenes; participants earn interaction-based credits (utility only) redeemable for access/items.
• Launch Takeover: 30-day POI hub rotation with A/B creative, wayfinding beacons, and a microsite tie-in.
• Creator Spotlight: Time-boxed showcases curated from Creator Pass submissions; brand sponsorship optional.

10.6 KPIs & Measurement (operational, not financial)

• Activation Velocity: Time from brief → staging → publish.
• Discoverability: Unique sessions, viewable impressions, traversal into hub nodes.
• Quality of Attention: Dwell time, interaction rate, completion rate for quest steps.
• Creative Efficacy: Variant deltas (A/B) on dwell/interaction/outbound actions.
• Reliability: Scene performance (FPS buckets), asset failure rate, guardrail triggers.
• Adoption: # active parcels, creators onboarded, repeat campaigns.

10.7 GTM Phases

• Phase 1 — Proof & Playbooks: Ship 3–5 reference activations; publish public staging links and postmortems; refine templates and validation rules.
• Phase 2 — Scale Inventory: Expand POI-adjacent placements; open Creator Pass intake; introduce self-serve scheduling within quotas.
• Phase 3 — Partner Multipliers: Co-marketing with platforms/integrations; SDK distribution; standardized procurement artifacts (SOW templates, security brief).

10.8 Brand Safety, Policy, and NY Gating

• Pre-flight creative review, content standards, takedown workflow.
• Jurisdictional feature flags to disable restricted utilities (e.g., certain programs in New York State).
• Public contract addresses + verification guidance; no token distribution via unsolicited channels.

10.9 Risks & Mitigations (marketing context)

• Platform Fragmentation → Template library + validation pipeline; multi-engine SDKs.
• Low Traffic Variance → Cluster near POIs; design hub traversal; rotate creative with A/B.
• Complex Onboarding → Creator Pass, playbooks, and white-glove pilots.
• Compliance Drift → Centralized Legal notice; policy flags in dApp; periodic reviews.

10.10 Narrative Promise

Defibillboards makes immersive campaigns deployable, measurable, and repeatable. The story we tell—and prove—is simple: discoverability by design, standards that travel, and operations you can trust.

11. Roadmap

This roadmap outlines capability milestones and operational themes rather than financial targets. Timelines are directional and may change with platform policy, partner dependencies, and security reviews. (See Legal Disclaimer & Availability Notice.)

11.1 Near-Term (Q4 2025)

Experience & Inventory

• Expand POI-adjacent parcel clusters; publish “Hub v1” scene templates (billboards, kiosks, wayfinding).
• Launch Creator Pass intake with tiered validation budgets and a curated template library.

dApp & Ops

• GA of Campaign Composer (placements, schedules, rotations) and Staging Viewer with integrity checks.
• Event taxonomy v1 (impressions, viewable, dwell, interactions, traversal) and baseline dashboards.

Token & Security

• Publicly verify DBB contracts (L1 liquidity / L2 utility) on explorers; publish signed release notes.
• ETH → Base bridging flow documented with user verification steps; feature flags wired for jurisdiction gating.

Compliance & Safety

• Content standards v1; takedown + emergency de-publish workflow.
• Jurisdictional feature flags enabled (e.g., NYS restrictions by default).

11.2 Mid-Term (H1 2026)

Experience & Interop

• Hub v2: multi-parcel routing graphs with guided traversal and beaconing; quest/collectible modules.
• Cross-scene A/B rotation with auto-promote; seasonal programming playbooks.

dApp & APIs

• Partner SDKs for scene runtime (manifest fetch, access checks, event logging).
• Webhooks for campaign lifecycle events; signed exports for third-party BI.

Utilities & Programs

• Operational allowances (placement/voucher/preview credits) with quotas, expiry, and audit logs.
• Interaction-earned credits (utility only) expanded to additional scene types; abuse heuristics v1.5.

Governance & Ops

• Role-based request queueing; reviewer escalation and change-window scheduling.
• Incident response runbooks; quarterly policy reviews with signed changelogs.

11.3 Longer-Term (H2 2026 and beyond)

Scale & Reliability

• Inventory expansion across additional worlds/venues; per-platform optimization profiles.
• CDN/edge caching for manifests and asset bundles; graceful degradation paths.

Analytics & Optimization

• Cohort and pathing analytics (hub inflow/outflow, drop-offs); creative effectiveness scoring.
• Experimentation framework with guardrails (minimum sample sizes, confidence bands).

Ecosystem

• Curated Creator Spotlight cycles; allowlisted showcases with brand sponsorship options.
• Additional credential types (non-transferable badges for operations, QA, events).

Security & Verification

• Optional third-party assessments (contract/infra); public disclosure of findings where applicable.
• Expanded anomaly detection: bot heuristics, rate-limit analytics, scene health monitors.

11.4 Dependencies & Risks (selected)

• Platform constraints: Asset/script limits, engine/runtime changes may require refactors.
• Partner policies: Wallet/bridge/exchange policy shifts can alter user flows.
• Jurisdictional changes: New or updated regulations may trigger feature gating or re-scoping.
• Traffic variance: POI changes and world adoption can affect baseline discoverability.

11.5 Change Management

All material changes (contracts, bridge parameters, policy toggles) will be documented in signed release notes and reflected in the dApp’s status page.

Backwards-compatible migrations preferred; breaking changes include a deprecation window and fallback path.

This roadmap is a planning instrument. It describes intended capabilities and sequencing, not promises of delivery dates, listings, price outcomes, or program availability in any jurisdiction.

12. Governance & Operations

Defibillboards is operated to be transparent, auditable, and reversible—prioritizing safety, policy compliance, and predictable execution over speculation. Governance focuses on product and operations (what gets built, how it is run, and how changes roll out), not on financial distributions. (See Legal Disclaimer & Availability Notice.)

12.1 Roles & Decision Rights

• Landowner — Retains parcel ownership; may delegate/revoke operator rights at any time via native platform controls.
• Operator (Defibillboards) — Publishes scene updates, configures campaigns, manages routing, and enforces policy/feature flags. No custody of user funds; least-privilege keys.
• Brand/Creator — Provides assets and goals; accesses creator/campaign tools when credentialed.
• Reviewer — Approves creative/legal copy, accessibility, and jurisdictional gating (e.g., NYS).
• Observer — Read-only analytics/audits for partners or platform stakeholders.

Decision rights (examples):

• Parcel content / publish window → Operator + Reviewer; Landowner can veto by revoking operator.
• Policy & standards updates → Governance Working Group (see 12.5), with public changelog.
• Security/incident decisions → Security Lead under incident runbook (12.6).

12.2 Policies & Standards

• Content Standards: Prohibit illegal/infringing content; brand-safety and conduct guidelines published in docs.
• Technical Standards: Asset schemas (GLB/GLTF), budgets (tri/texture/script), validation gates, integrity hashes.
• Accessibility: Contrast, motion, legibility, and input-method considerations; review checklist in staging.
• Jurisdictional Gating: Feature flags by geography/platform; restricted features disabled by default for sensitive regions (e.g., New York State).
• Data Minimization: Pseudonymous event logging only; no seed phrases, no custody.

12.3 Operational Processes

• Change Management: Draft → review → approve → publish; every release creates a signed, immutable record with diffs and rollback points.
• Campaign Lifecycle: Brief/spec → asset intake/validation → staging QA → publish → monitor → iterate → closeout archive.
• Routing & Hubs: Edits to traversal graphs require reviewer sign-off; safety checks prevent broken links or dead ends.
• Depublish & Rollback: Any parcel can be reverted to the last known-good release in one step; emergency “kill switch” for policy or safety violations.

12.4 Permissions & Key Management

• RBAC: Roles scoped to actions (upload, schedule, route, publish, revoke).
• Least-Privilege Keys: Separate deployment, operator, and analytics keys; hardware-backed storage where feasible.
• Audit Trails: All sensitive actions (publish, revoke, flag changes) are timestamped, signed, and exportable.

12.5 Governance Working Group (Process, not payouts)

A cross-functional group (product, security, legal/policy, creator liaison) maintains standards and approves material changes to:

• Asset/scene policies (budgets, formats, safety rules)
• Event taxonomy & analytics definitions
• Jurisdictional feature flags & legal copy
• Release cadence & deprecation schedules

Input channels: public docs, issue tracker, creator office hours, partner feedback. Outputs: versioned standards and signed release notes. This group does not administer financial distributions.

12.6 Incident Response & Risk

• Triggers: Security alerts, policy violations, abusive content, performance regressions, bridge/explorer anomalies.
• Runbook: Identify → contain (depublish/flag off) → remediate (asset fix, config change) → postmortem with actions.
• SLAs: Severity tiers define response/restore targets (published in ops docs).
• Dependencies: Known-good fallbacks if third-party services degrade (CDN, explorer, wallet APIs).

12.7 Compliance & Jurisdictions

• Legal Notice enforcement: Policy strings surfaced in UI; gating honored at runtime (manifests reflect flags).
• Regional Rules: Programs that are restricted in certain jurisdictions (e.g., NYS) are disabled and labeled.
• Records: Keep evidence of gating decisions and approvals in the release record for audit.

12.8 Transparency & External Verification

• Contract Verification: Official addresses listed in §§6.4, 8.3; sources verified on explorers.
• Changelogs: Public, signed release notes for material updates (contracts, bridge posture, policy toggles).
• Optional Assessments: Third-party reviews (security/infra) may be commissioned; summaries published where appropriate.

12.9 Vendor & Partner Management

• Due Diligence: Wallets/bridges/CDNs/analytics vendors evaluated for security posture and uptime.
• Termination & Substitution: Partners can be rotated; manifests and SDKs abstract vendor specifics to keep scenes portable.
• Data Handling: Only minimal, scoped data flows to vendors; keys and webhooks are revocable.

12.10 Community Participation (Non-Financial)

• Creator Pass & Badges: Govern access to tools and showcases; criteria published.
• RFP/Template Calls: Open calls for scene templates, with attribution and SOW-based compensation where applicable.
• Feedback Loops: Roadmap input via public channels; adoption metrics shared at milestones.

What this section is not: It does not establish tokenholder voting for financial distributions or promise returns. Governance here is about how the product operates safely and predictably, under clear standards and with reversible changes. Availability and policies vary by platform and jurisdiction; see Legal Disclaimer & Availability Notice.

13. Risks & Limitations

This section outlines material risks and constraints that could affect features, timelines, and outcomes. It is not exhaustive and does not include financial projections. Availability varies by platform and jurisdiction. (See Legal Disclaimer & Availability Notice.)

13.1 Platform & Ecosystem Risks

• Runtime/Engine Changes. Metaverse platforms may change asset limits, scripting models, or rendering pipelines, breaking scenes or requiring refactors.
• POI Volatility. Spawn points and traffic patterns can shift, reducing baseline discoverability despite parcel placement.
• Third-Party Dependencies. Wallets, bridges, CDNs, analytics, and hosting providers may degrade or suspend service.

Mitigations: Modular scene templates, validation pipelines, versioned manifests, fallbacks/caching, vendor substitution paths.

13.2 Technical & Security Risks

• Smart-Contract Bugs. Undiscovered defects could affect token behavior or access checks.
• Bridge/Interop Risks. Cross-layer supply accounting depends on bridge correctness and chain liveness.
• Abuse/Bot Activity. Sybil attacks or scripted interactions could distort metrics or farm utilities.
• Content Integrity. Malicious or non-compliant assets could be submitted by external parties.

Mitigations: Contract verification, least-privilege keys, signed manifests, allowlists, rate limits, anomaly detection, emergency de-publish and rollback.

13.3 Compliance & Jurisdiction Risks

• Regulatory Changes. Evolving laws (e.g., virtual currency rules, marketing disclosures, data handling) may require feature gating or removal.
• Regional Restrictions. Certain programs are disabled in specific jurisdictions (e.g., New York State) and may expand to others.
• Marketing/Claims Constraints. Language and placement may require adjustments for platform or legal policy.

Mitigations: Centralized Legal notice, jurisdictional feature flags, periodic policy reviews, documented approvals.

13.4 Operational Risks

• Change Management Errors. Misconfigured releases can break scenes or routes.
• Capacity & SLA Limits. Spikes in demand may exceed review, support, or publishing capacity.
• Creative/Asset Delays. Brand approvals or third-party deliverables can stall timelines.

Mitigations: RBAC with approvals, scheduled change windows, rollbacks, severity-based SLAs, playbooks and queues.

13.5 Adoption & Market Risks

• Low or Uneven Traffic. World activity can be cyclical; not all campaigns achieve the same exposure.
• Creator/Brand Churn. Participation may drop if outcomes don’t meet expectations or if platform meta shifts.
• Fragmented Standards. Cross-world portability is imperfect; some features won’t map 1:1.

Mitigations: POI clustering, hub traversal design, A/B rotation, public playbooks, SDKs to normalize core flows.

13.6 Measurement & Data Limitations

• Attribution Gaps. Linking in-world interactions to off-world conversions is imperfect and sometimes infeasible.
• Sampling Variance. Small sample sizes can produce noisy A/B reads.
• Privacy & Data Minimization. By design we log minimal, pseudonymous data; some analyses won’t be possible.

Mitigations: Standard event taxonomy, guardrails on experiment design, confidence bands in reports, explicit data boundaries.

13.7 Token & Utility Constraints

• No Financial Rights. DBB utilities (access, credits/items, vouchers, allowances) are consumptive and not financial products; programs are jurisdiction-gated.
• Liquidity/Bridge Posture. L1/L2 design and parameters may change; there are no price guarantees, floors, or listing commitments.
• Contract Finality. Addresses are fixed; mistaken transfers or interactions may be irreversible.

Mitigations: Clear verification steps, signed release notes for material changes, conservative defaults on restricted features.

13.8 Content & Community Risks

• Brand Safety. User-generated or partner content can conflict with standards.
• IP/License Issues. Asset rights and third-party materials require careful handling.
• Conduct & Moderation. Abuse or harassment can occur in open spaces.

Mitigations: Content standards, takedown workflows, rights documentation, moderation hooks, and scene guardrails.

13.9 Financial & Expectation Boundaries

• No Performance Guarantees. Discoverability, engagement, or adoption outcomes are not guaranteed.
• No Investment Advice. Materials herein are operational and technical; they are not investment guidance.
• Cost Variability. Platform fees, vendor pricing, and operational costs can change.

Summary. Defibillboards is engineered for reversibility, auditability, and policy alignment. Even so, external dependencies, policy shifts, and technical unknowns introduce risk. We address these with standards, feature flags, conservative assumptions, and transparent change management—but not with financial assurances or promises of results. See Legal Disclaimer & Availability Notice for full context.

14. Conclusion

The metaverse’s central challenge is fragmentation: valuable parcels sit idle, standards are inconsistent, and launching measurable experiences is harder than it should be. Defibillboards addresses this by aligning where experiences live (POI-adjacent parcels), how they’re operated (a dApp for standardized activations, routing, and QA), and how they’re measured (a common event vocabulary and dashboards). The result is a coordination layer that makes campaigns deployable, discoverable, and repeatable—without framing participation as a financial product.

Our approach is intentionally practical: parcel-anchored placements, reusable scene modules, creator/brand tooling, and clear governance with reversible changes. Access is handled through utility-only credentials and credits, with jurisdictional feature flags ensuring policy alignment across platforms and regions. The DBB token powers on-platform utilities (access, allowances, in-experience items) while separating L1 liquidity from L2 utility for operational efficiency and transparency.

From here, progress will be measured by activation velocity, quality of attention, and the growth of cohesive hubs—not by speculative signals. We will continue to expand inventory near high-traffic points, refine standards and SDKs, and ship playbooks that any brand or creator can adopt. Landowners keep ownership and can revoke operator rights at any time; creators bring ideas; brands bring stories; our role is to provide the infrastructure and discipline that turn those inputs into live, policy-aligned experiences.

If you are a landowner with idle parcels, a creator seeking distribution, or a brand exploring immersive campaigns, the next sections outline how to engage through products, programs, and governance. Availability varies by platform and jurisdiction; see the Legal Disclaimer & Availability Notice for definitions and restrictions.

15. Glossary

• Access & Gating — Wallet/NFT–based checks that unlock utility-only features (tools, credits, items). Not financial rights.
• A/B (Multi-Variant) Rotation — Running two or more creative versions under controlled delivery rules to compare operational KPIs (e.g., dwell, interactions).
• Allowlist — Approved set of assets, domains, wallets, or contracts permitted to interact with scenes or the dApp.
• Baseline Discoverability — Organic traffic attributable to parcel placement near spawn points/POIs before paid or programmed routing.
• Badge (Soulbound) — Non-transferable credential that unlocks utilities (access, items, allowances). May expire or be revoked.
• Base (L2) — Layer-2 network used for low-fee, fast utility operations (credits, items, vouchers, access checks).
• Bridging (ETH → Base) — Moving DBB from Ethereum (L1) to Base (L2) for utility use. Parameters follow the canonical bridge and may change.
• Campaign Composer — dApp module to configure placements, schedules, rotations, and feature flags.
• Campaign Voucher — Single-use utility token that reserves an operational action (e.g., placement slot, preview rotation). Burns on use.
• Cohesive Hub — A cluster of adjacent parcels linked by routing, wayfinding, and scenes to behave as one experience.
• Creator Pass — NFT credential that unlocks creator tools (upload, staging, validation) within policy limits.
• DBB (Token) — Utility token for on-platform functions (access, credits/items, vouchers, allowances). Not an investment; no yield, dividends, or price promises.
• dApp (Coordination Layer) — Web application and services that orchestrate assets, campaigns, routing, access, and analytics.
• Decentraland Operator (Example) — A delegated role allowing scene updates on a parcel; ownership remains with the landowner.
• Dwell — Aggregate time a session spends within a parcel/scene segment that meets viewability thresholds.
• Event Taxonomy — Standard set of events (impression, viewable impression, dwell, interaction, traversal, outbound action) used for comparable reporting.
• ETH (Ethereum, L1) — Settlement layer used for liquidity (market-facing) side of DBB and canonical supply accounting.
• Feature Flags — Configuration that enables/disables features by platform, geography, or policy (e.g., NYS restrictions).
• Integrity Hash — Content fingerprint embedded in manifests to detect tampering or mismatched assets.
• Interaction-Earned Credits — Non-transferable, in-platform credits granted on permitted user interactions with approved scene objects; redeemable only for utilities (access, items, vouchers).
• Jurisdictional Gating — Enforcing regional availability rules (e.g., disabling certain programs for New York State residents).
• Kernel (Liquidity Side) — The L1 liquidity posture for DBB (e.g., DBB/ETH pool) separated from L2 utility functions.
• Land Farming (Activation) — Coordinated setup, publishing, routing, upkeep, and measurement of scenes across parcels. Non-financial.
• Landowner — Parcel owner who can delegate/revoke operator rights; retains ownership at all times.
• LOD (Level of Detail) — Multiple mesh/texture versions used to optimize performance across device capabilities.
• Manifest (Signed) — Configuration document fetched by scenes that specifies placements, routing, assets, flags, and integrity hashes.
• Operator — Authorized party (e.g., Defibillboards) with limited rights to publish/update scenes; revocable by the landowner.
• Parcel-Anchored Placement — A campaign surface bound to a specific parcel (billboard, kiosk, event module, interactive unit).
• POI (Point of Interest) — High-traffic world landmarks/spawn areas used to cluster placements for baseline discoverability.
• RBAC (Role-Based Access Control) — Permission model mapping roles (viewer/creator/brand/operator/reviewer) to allowed actions.
• Rollback / Hot-Swap — Safe revert to a prior release or immediate asset swap without full scene rebuild.
• Routing Graph — Wayfinding/teleport structure that connects parcels into a hub and defines traversal paths.
• Signed Release Record — Immutable, timestamped snapshot of what was published, by whom, and when; used for audits and rollbacks.
• Staging Viewer — Preview environment to test scenes, performance, and accessibility before publish.
• Telemetry (Pseudonymous) — Minimal, non-PII event logging for operational measurement (no seed phrases, no custody).
• Validation Pipeline — Automated checks (format, tri/texture budgets, collider/script limits) that gate publishability.
• Viewable Impression — Impression meeting a sustained visibility threshold (e.g., on-screen ≥2s) as defined in the event taxonomy.
• Visitor Token (Ephemeral) — Short-lived proof used to unlock micro-features without creating permanent credentials.

16. Appendix A: Pros & Challenges

This appendix aggregates common advantages of running campaigns through Defibillboards and the challenges brands/creators face when operating alone. Items are operational—not financial promises. Availability varies by platform and jurisdiction; see Legal Disclaimer & Availability Notice.

A. Pros (Using Defibillboards)

Discoverability & Scale

• POI-adjacent placements that raise baseline traffic without paid boosts.
• Hub routing (beacons/teleports) to knit parcels into cohesive experiences.

Speed & Quality

• Templates + validation pipeline reduce time-to-live and prevent broken scenes.
• In-house creative + engineering for optimized GLB/GLTF assets and safe script budgets.

Consistency & Measurement

• Standard campaign schemas and event taxonomy (impressions, dwell, interactions, traversal).
• A/B and multi-variant rotations with comparable, exportable reports.

Interoperability

• Content schemas and manifests designed to travel across engines/worlds.
• SDKs/webhooks for partner integrations (runtime configs, event logging).

Governance, Safety & Compliance

• RBAC, operator delegation (revocable), signed releases, and rollbacks.
• Feature flags for jurisdictional gating (e.g., NYS restrictions) and platform policy alignment.

Creator/Brand UX

• Self-serve dApp for scheduling, routing, and approvals within quotas.
• Support workflows, accessibility checks, and content standards built in.

B. Challenges (Operating Alone)

Traffic & Visibility

• Parcels distant from POIs see low organic flow; discovery relies on external promotion.
• No shared routing → fragmented footpaths and short session lengths.

Technical Burden

• 3D modeling, optimization, scripting, and hosting require specialized skills.
• Platform limits (tri/textures/scripts) and updates can break scenes.

Operational Friction

• No standardized intake → validation → staging → publish lifecycle.
• Change control is ad hoc; limited ability to rollback or hot-swap assets.

Inconsistent Measurement

• Mixed event definitions make results non-comparable across campaigns/worlds.
• Limited A/B infrastructure; noisy reads from small samples.

Cost Variance

• Solo builds and bespoke pipelines increase time/cost risk and maintenance overhead.
• Vendor sprawl (wallets/bridges/CDNs/analytics) adds complexity.

Policy & Safety

• Hard to maintain brand-safe content, rights clearance, and takedown workflows.
• Jurisdictional rules (e.g., NYS) are easy to miss without feature-flag enforcement.

How to use this appendix:

• In proposals, pair two or three Pros with matching Challenges to show before/after outcomes.
• Reference main sections for proof points: §7.1–7.3 (operations), §6.2–6.4 (controls), §9 (programs), and §13 (risks).

17. Appendix B: Images/Diagrams (ecosystem, token flow)

Here are two clear diagrams Experience Flow and User flow

Downloads

• Ecosystem Overview Diagram
• Token Flow: Liquidity (L1) & Utility (L2)

Figure B1. Ecosystem Overview

What it shows

• Experience Layer on top (metaverse scenes, 3D assets, interactive units, wayfinding near POIs).
• Coordination Layer (dApp) in the middle (asset intake, campaign composer, routing/hubs, feature flags, observability).
• On-Chain Layer (parcel NFTs, access credentials, DBB token) ensuring ownership, permissions, and minimal on-chain references.
• Data & Observability at the bottom (standard event taxonomy, non-PII dashboards).
• Stakeholders—Landowners, Creators/Studios, Brands/Agencies—feeding the Experience Layer.
• Vertical arrows depict the flow from content to coordination to on-chain references to analytics.

How to read it

• Top→down shows how live scenes are published and measured.
• Left annotations highlight policy controls; right annotations call out verification and data boundaries.
• It visually reinforces reversibility, auditability, and jurisdictional gating.

Figure B2. Token Flow: Liquidity (L1) & Utility (L2)

What it shows

• Ethereum (L1) box for the DBB liquidity side (“Kernel”: DBB/ETH pool; address shown).
• Base (L2) box for the DBB utility side (access, credits, items, vouchers; address shown).
• A Bridge (ETH → Base) box describing supply parity (canonical bridge parameters).
• A User Flow box summarizing: acquire on L1 → bridge to L2 → use utilities in dApp/scenes → optional bridge back per policy.
• A small Utilities (§8.1) box connected to L2 to emphasize where DBB is actually consumed.

How to read it

• The horizontal arrow and stepped arrows emphasize the primary flow from L1 to L2 for practical usage.
• Notes at the top and bottom reiterate that the design separates market-facing liquidity from low-cost utility, that availability varies by jurisdiction, and you should verify addresses.

18. Appendix C: Contract Links & Proofs

This appendix centralizes the official DBB contracts, explorer links, and a verification checklist you (and readers) can use before interacting with anything on-chain. These references are for transparency and auditability and do not imply listings, price outcomes, or availability in any jurisdiction. See Legal Disclaimer & Availability Notice.

C.1 Official Contracts (copy/paste)

Ethereum (L1) — DBB Token (liquidity side / “Kernel”)
0x1c6a09d955033f4762ecf37f9c74ddf99cd1693c
Deployed: September 24, 2025
Role: Canonical L1 token used for DBB/ETH liquidity and bridging to Base for utility.

Base (L2) — DBB Token (utility side)
0x08ad71edd154a4150a1352d0e874dd3be3c0d671
Role: On-platform utilities on Base (e.g., access credits, in-experience items, vouchers, feature gating).

Tip: Always copy addresses from this appendix (or your official website) rather than social media posts or DMs.

C.2 Explorer Links (verify before use)

• Etherscan (Ethereum L1) — paste: 0x1c6a09d955033f4762ecf37f9c74ddf99cd1693c
• BaseScan (Base L2) — paste: 0x08ad71edd154a4150a1352d0e874dd3be3c0d671

How to use the explorers

1. Open the relevant explorer (Etherscan for L1, BaseScan for L2).
2. Paste the address into the search bar.
3. Confirm you’re on a Contract page (not an EOA), and that source code is Verified.

C.3 Verification Checklist (do this every time)

Identity & code

• ✅ Page shows Contract (not “Externally Owned Account”).
• ✅ Verified source code badge is visible.
• ✅ Name / Symbol / Decimals match the white paper.
• ✅ Read/Write tabs expose the expected ERC-20 functions (plus any disclosed extensions).

Metadata & config

• ✅ Compiler settings and metadata are published.
• ✅ If a proxy is used (not expected), the implementation contract is visible and verified.

Supply & movements

• ✅ Total supply is consistent with documentation.
• ✅ Token movements align with your bridging posture (ETH → Base for utility).
• ✅ No suspicious minting or admin activity in recent transactions.

Wallet add

• ✅ Add the token by contract address (never by name search).
• ✅ Cross-check the checksum after adding.

C.4 Verifiable Screenshots

• Etherscan contract overview with “Contract” and “Verified” visible.
• BaseScan contract overview with “Contract” and “Verified” visible.
• DBB on Ethereum Network
• DBB on Base Network

C.5 Responsible Disclosure & Support

Security contact: hello@defibillboards.com

Responsible disclosure: Please report vulnerabilities privately; we will acknowledge good-faith reports and coordinate remediation before public disclosure.

Impersonation warning: We never share private keys, ask for seed phrases, or distribute bridge links via unsolicited DMs. Verify addresses here or on your official site only.

Important Reminders
These contracts and links are provided for verification and safe usage of utilities in the Defibillboards ecosystem.
Nothing herein constitutes an offer, an exchange listing, or a guarantee of price or availability.
Jurisdictional controls apply; certain features may be disabled (e.g., for New York State residents). See the Legal Disclaimer & Availability Notice.