meshticulum.

A SAGE Foundation project / In development

Small radios.
Bigger possibilities.

Secure messages. Verified resources. A transport designed to make more of every radio link, and use faster paths when they become available.

Explore the source See how it works

Experimental, open source, Apache 2.0.
Standalone core. Built for applications beyond Lantern.

Illustrative network: verified resources and encrypted messages pass between radio peers, with an optional faster IP path.
01 / The idea Keep trust with the data, across a change of path.
LoRa + IPAuthenticated flowsSigned public resourcesRecipient-encrypted envelopes

01 / Why Meshticulum

The radio is small.
The ambition shouldn’t be.

A useful network needs both practical radio operation and secure ways to move complete data. Meshticulum brings those priorities together in a separate protocol.

A starting point

MeshCore

A lightweight packet-radio framework, with embedded companion and repeater roles. Its practical radio focus is part of what inspires this work.

MeshCore project
A starting point

Reticulum

A cryptographic networking stack spanning local and wide-area networks, including very low-bandwidth links. Its broader networking model informs the other side of the design.

Reticulum overview
The bridge we’re building

Meshticulum

Bounded radio transfers, authenticated peer and service bindings, verified resources, and an explicit path policy that can use LoRa or IP.

Compare the designs

This is a bridge between design strengths. MeshCore and Reticulum wire compatibility is not implemented.

02 / Architecture

Trust above.
Transport below.

A resource keeps its identity when its path changes. Each transfer still binds the peers, service, limits and original deadline.

Meshticulum layers: applications use public resource verification or private encrypted envelopes; both use bounded reliable flow and authenticated sessions; exclusive radio workers or an experimental TCP carrier transport the packets. Host applications supply policy and device ownership.
Reusable Meshticulum components. Applications supply current admission and native device ownership.
01

Move useful bytes

Compact resource blocks, receiver credit and selective acknowledgements reduce avoidable framing and per-frame overhead.

02

Verify before accepting

Public resources use signed manifests and content hashes. Private envelopes retain recipient encryption and sender signatures.

03

Keep the original limits

Deadlines, replay decisions and attempt debt survive cancellation and restart. A retry does not renew permission.

Follow a transfer through the architecture

03 / Measured, with scope

More than a modem
bitrate.

We measure useful bytes in authenticated encrypted transfers, and require independent publisher and content verification. Timing boundaries matter.

Latest accepted finite 16 KiB resource sample11 October 2026
1.071kB/s

Useful goodput
through the sender’s flow ACK

16,356bytes

Fresh public resource bytes
independently verified

85DATA frames

Acknowledged
zero DATA retries or duplicates

The response ACK interval was 15.268 seconds. The complete request-to-publisher-verification interval was 80.731 seconds, or 202.6 B/s. These measure different parts of the same transfer.

SF7 / BW500 / CR4/5921.375 MHz0 dBm chip settingMeasured airtime, energy and EIRP: unavailable

A comparison you can inspect

The 1,071.3 B/s sample is numerically 2.61× the 410 B/s contributed test in MeshCore issue #3404. That test used 25 individually acknowledged 128-byte frames at SF7/BW500. Ours used a windowed resource reply. Different workloads and timing boundaries prevent a general speed ranking.

What’s still ahead

Two consecutive finite samples exceeded 1,000 B/s. Sustained goodput, larger whole-file transfers, range at faster profiles, and native private forward-secrecy qualification remain open. The project is in development; an alpha release has not been published.

Read the measurement boundaries Inspect the sample records

04 / One family, clear boundaries

Its own transport.
Part of SAGE.

Created and maintained by Dhillon Andrew Kannabhiran, under the SAGE Foundation.

Meshticulum began in Lantern. The reusable protocol now stands on its own, so other applications can build on it too.

01

Meshticulum

Protocol, cryptography, reliable flow, drivers and verified resources.

You are here 02

SAGE Lantern

Product code, STL and printing files, private SAGE adapters, device policy and deployment.

 03

SAGE

Persistent agent memory, governance and core infrastructure.

Dependency direction: Lantern → Meshticulum

For developers

Read the design.
Build on the core.

Start with a local resource exchange. Follow the protocol boundaries before bringing a radio or a native application into the transfer.

01 / Inside the protocol

Technical overview

Cryptography, reliable flow, verified resources and path selection, with a diagram of the stack.

 02 / Different designs

Compare the projects

MeshCore, Reticulum and Meshticulum side by side, with security properties and scoped performance evidence.

 03 / Try the source

SDK and device setup

Verified Python APIs, a local block example, pinned firmware builds and the application-owned flashing workflow.

Explore the work

Open code.
Explicit evidence.

Read the design, inspect the results, or help build the next piece.

Open the repository Read the documentation See the roadmap