Why MAC-authenticated mesh.

The core vulnerability in DHCP-based networks is that IP addresses (and related routing information) are assigned dynamically by a central server. Attackers can exploit this through:

  • Rogue DHCP Servers: An attacker spins up a fake DHCP service that responds faster than the legitimate one, handing out malicious gateway/DNS settings. Once devices accept those, all traffic—wallet transactions included—can be routed through a hostile intermediary.
  • DHCP Spoofing and Man-in-the-Middle: Even if you’re on a “trusted” LAN, an attacker can intercept DHCP requests and slip in altered lease information (e.g., a bogus default gateway). From there, they can sniff or tamper with blockchain traffic, potentially hijacking signing requests or redirecting token transfers.
  • ARP Poisoning and IP Hijacking: Because IP addresses are floating, attackers can falsely claim ownership of a given IP, causing devices to believe they’re sending to a valid node when in fact they’re talking to a malicious host. This opens up straightforward token-stealing or transaction-tampering opportunities.

OTR replaces this fragile, IP-centric model with a purely MAC-authenticated mesh approach:

  1. Static MAC-Based Identity
    Every device in the OTR network is known by its hardware (MAC) address, and only pre-approved MACs are allowed to participate. There’s no “dynamic lease” to hijack—your MAC is both your address and your credential. That means:
    • No DHCP handshake, no risk of a rogue server handing out malicious parameters.
    • You always know exactly which physical device you’re talking to, because each hop is MAC-authenticated.
  2. Proof of Authentication at the Link Layer
    Before any token-related messages are forwarded, the network validates the device’s MAC fingerprint (often tied to a hardware attestation module). If someone tries ARP-poisoning or MAC spoofing, they simply won’t pass the cryptographic check. As a result:
    • MITM tactics that rely on injecting false ARP/DHCP data fail at the link layer.
    • There’s no opportunity for an attacker to claim “I’m the gateway” or “I’m the DNS” because there is no DHCP-driven gateway—routing happens directly via MAC routes.
  3. Elimination of IP-Level DNS/DNS-Hijack Weakness
    In a DHCP world, if an attacker poisons DNS entries, wallet apps can be tricked into connecting to a fake node or a malicious block-relay endpoint. OTR sidesteps DNS altogether—nodes discover each other through a MAC registry and optional IPFS fallback, so:
    • There’s no DNS record to spoof.
    • Even if you pull data from IPFS, you verify content hashes and signature proofs, ensuring you’re talking to the real validator or relayer.
  4. MAC-Only Routing Reduces Attack Surface
    Because OTR’s mesh is built on direct MAC-to-MAC hops, there’s no concept of “default gateway” or “Rogue DHCP server.” Attackers can’t inject false routing instructions at DHCP time, nor can they hijack your sessions by claiming an IP address. In practice:
    • Each device maintains a small, authenticated neighbor table (MAC ↔ next-hop).
    • If a node ever tries to route packets under a different MAC than expected, the network simply drops the frames.
  5. Optional Encryption and Hardware Trust Badges
    On top of MAC authentication, you can layer AES-128/256 encryption tied to device keys. Even if an attacker somehow tampers with the RF channel or intercepts packets, they can’t decrypt payloads or inject valid token-transfer requests without the proper key. And since each device carries a hardware trust badge (fingerprint audit log), you have a full chain of custody for every transaction.

In Practice, This Means:

  • No Dynamic IPs → No Dynamic Attacks
    You never request or receive an IP lease, so there’s nothing for an attacker to spoof or poison. Your wallet’s “network address” is literally your NIC’s MAC, which is uniquely signed/approved.
  • All Hops Are Verified
    Before any token transfer or balance update is broadcast, the frame is authenticated at the MAC layer. If an attacker injects a “fake frame,” it simply won’t pass the link-level signature check.
  • Immutable Neighbor Tables
    Devices store a small, pre-approved MAC list (or check against a digitally signed registry). Even if someone plugs into a switch or tries to ARP-poison, they’re invisible to the rest of the mesh.
  • IPFS Fallback with Content Hash Verification
    When you need to sync blockchain state or pull transaction history, you fetch it from IPFS (using only verified CIDs). Even if someone tries to hijack IPFS nodes, the content is self-verifying (hash+signature), so you won’t accidentally execute a malicious chain update.

By eliminating DHCP and all of its downstream vulnerabilities (rogue leases, DNS poisoning, ARP spoofing), OTR ensures that every on-chain action—especially token transfers—can only originate from an authenticated, hardware-verified device. This drastically shrinks the attack surface and makes “token loss via network-level trickery” virtually impossible.

Home/office(Simplified Client):

1. Printer is running OTA Printer Node module

  • It registers itself on the OTR network using its MAC address (e.g., MAC_PRINTER_01)
  • Automatically joins the local MAC-authenticated subnet

2. Phone/Tablet wants to print

  • User’s device (e.g., phone) connects to the same OTR subnet (via Wi-Fi or BLE)
  • The phone runs the OTAwallet app or any OTR-compatible client
  • The client uses the /printer/discover API to find nearby printers by MAC

3. User sends a print job

  • The user selects a file or photo
  • The file is sent via /printer/job/send with:
    • Target MAC of the printer
    • Payload (document, image, etc.)
    • Optional: Metadata (number of copies, grayscale, etc.)

4. Printer node receives and prints

  • The node listens for jobs
  • Validates the job (signature, policy, CID if archived)
  • Starts printing
  • Logs a CID hash to IPFS for proof-of-job if enabled

5. User receives confirmation

  • Job status can be queried via /printer/job/status/:id
  • Optionally, it appears in the OTAwallet dashboard under “Recent Tasks”

Why MAC Mode Makes This Simple and Secure

  • No DHCP, no dynamic IP lookup — just MAC routing
  • Spoofing is mitigated by MAC allowlist + Proof of Authentication
  • Devices don’t need to “install” the printer — just discover and use via the API
  • Works even offline, since it can queue jobs and retry sync

Client Setup Needs

  • Phone or computer on OTR subnet (e.g., through patched router or node)
  • OTAwallet app or SDK installed
  • MAC pairing once (auto-saved)
  • That’s it — no drivers, no setup wizards