Same channel, more mission payload. PULSE only.

Result 2: Enabling TCP/IP-based Application Across UDP/Multicast Infrastructure

Agnostic to any TCP/IP application.

Background

Dragon Nexus is a U.S. Army-sponsored bench test series hosted by invitation only by XVIII Airborne Corps at Fort Bragg, North Carolina. TerraKinesis (TK) was selected to participate in the inaugural event — the first formal, Army-directed evaluation environment for PULSE (TerraKinesis software solution) and the primary near-term revenue gate for the company.

The XVIII Airborne Corps is the Army’s contingency response force. Its units must be ready to deploy anywhere in the world within 18 hours to support U.S. commanders’ mission objectives. They fight in environments with limited or no fixed infrastructure, which means they must carry their own edge infrastructure into the fight. PULSE runs on the infrastructure the unit already fields, enabling faster, better decisions without requiring an expensive retrofit in time and cost.

The Challenge

Modern distributed military operations require real-time data exchange across teams, vehicles, sensors, and command nodes. Existing solutions depend on backhaul (SATCOM/cellular towers) and the cloud infrastructure that is unavailable, unreliable, or actively jammed where XVIII Airborne Corps deploys.

Next-generation command and control (NGC2) capabilities require up to 5 nodes (e.g., smart sensors/devices such as a TAK device, radio, tank, etc.) per warfighter. Current infrastructure supports only 20 devices per backhaul (SATCOM/cellular tower) link — meaning only 4 soldiers can be connected per satellite at any given time, and the number of those links is severely cost-constrained.

SATCOM (and other backhaul options) are a billion-dollar band-aid. It is not a solution — it is a workaround for a protocol-level failure that has never been fixed.

The underlying problem is protocol-level. TCP/IP requires a 3-way handshake for every message — generating at least 2 overhead messages for every 1 message sent. Every device on the network must decode every message. When a message fails, retransmission further floods the network. Each additional device compounds congestion until the network can no longer pass any message at all. The baseline demonstration at Dragon Nexus confirmed this: utilizing standard TCP/IP, the message success rate at 20 nodes is 0%.

This means critical battlefield information — troop positions, GPS coordinates, enemy intelligence — fails to reach the warfighters who need it most, at the moment they need it.

Event Initiation
Dragon Nexus 26-01 was initiated by the C2 Trail Boss — the U.S. Army’s integration lead for the Common Platform Environment Command and Control (CPE C2) program. The formal purpose of the event was to evaluate whether emerging software solutions could solve the node-scaling limitation that has constrained Army distributed networking for over two decades. TerraKinesis was selected to demonstrate PULSE as a candidate solution against this validated capability gap.

The Solution

TerraKinesis deployed PULSE (a firmware-based, distributed compute protocol) across the Dragon Nexus test environment. PULSE operates entirely without cloud, cellular, and satellite dependency, enabling resilient mesh networking across all participating nodes using existing tactical radio hardware.

Key Technical Capabilities Demonstrated

• NACK Protocol — Reduced network overhead by 95–99%, extending effective radio range and dramatically reducing bandwidth consumption

• Beehive Grouping (patent pending) — Enabled seamless scaling across the full node network with O(n) complexity, compared to O(n²) for competing approaches

• ELMF Architecture — Delivered sub-50 microsecond per-message latency with high delivery rates under packet loss conditions representative of contested RF environments

• Backwards Compatibility — Deployed on TrellisWare TSM radios using existing hardware, with no infrastructure replacement required

Results

For two decades, industry and government have tried to scale distributed computing on hub-and-spoke architecture and TCP/IP — a model that confirms every message and collapses as nodes are added. Dragon Nexus 26-01 proved the ceiling is real: at 20 nodes, TCP/IP delivery falls to zero.

PULSE is a different architecture. Every node is a peer. Every node relays the same message across a UDP/multicast mesh — built to scale to 1,000 nodes, not 20. TCP/IP was the ceiling. PULSE is the pathway through it, documented by the Army at Fort Bragg.

Operational Impact

Dragon Nexus confirmed what XVIII Airborne Corps already suspected: today’s networking protocols are operationally incompatible with the distributed formations the Army is building toward. At 20 nodes — the practical limit of TCP/IP under contested conditions — message delivery collapses to 0%. PULSE demonstrated sustained high-delivery performance at the same node count and load, using hardware already in the field.

For XVIII Airborne Corps — the Army’s most rapidly deployable combat force — this matters at the mission level. Distributed formations of crewed vehicles, uncrewed systems, sensors, and dismounted warfighters require real-time coordination that SATCOM cannot reliably provide in denied or degraded environments. PULSE enables that coordination without satellite dependence, new hardware, or a central point of failure.

XVIII Airborne Corps invited TerraKinesis to Dragon Nexus 26-02. The Scope of Work and increase integration to a large number of nodes. It will also include soldier touch points.

Path Forward

Dragon Nexus establishes PULSE in the TRL 5–6 range — validated and demonstrated in a relevant environment on live tactical hardware. The path to TRL 7 requires testing in an operational environment.

TerraKinesis is concurrently pursuing procurement pathways — OTA, xTech, SBIR Phase I, II, and III, and direct contract — to balance customer timelines with supply chain requirements.

Successful military validation opens the commercial pathway. The same PULSE protocol that coordinates a 1,000-node battlefield formation coordinates a software-defined vehicle, an autonomous fleet, and a smart city network. The physics are identical. The market is different. Defense wins fund the commercial build.

Pulse returns the channel to the warfighter.

Same radios.

Same waveform.

No new hardware required.

Army-documented, Fort Bragg June 2026.

About TerraKinesis

TerraKinesis is a Detroit-based defense technology company founded by a combat veteran and deep-tech engineers to solve one of the hardest unsolved problems in distributed computing: guaranteed message delivery at scale, without a server, without a satellite, and without the network failing when it matters most. The company built PULSE — the infrastructure layer for contested, denied, and degraded environments — and is backed by strategic defense and commercial investors, with active Series A discussions underway.

Glossary

Terms are defined as used in this document. Military terminology follows U.S. Army doctrinal usage.

Beehive Grouping — TerraKinesis’s patent-pending node organization architecture. Groups nodes into clusters that scale linearly — O(n) — rather than the exponential O(n²) growth that causes network collapse in competing approaches.

Barrage Relay — A TrellisWare TSM radio operating in relay mode, extending the range of a tactical mesh network by forwarding traffic between nodes that cannot communicate directly. Used in the Dragon Nexus Result 26-01.

C5ISR DEVCOM — Command, Control, Communications, Computers, Cyber, Intelligence, Surveillance, and Reconnaissance Development Command. The Army organization responsible for testing and validating communication technologies. Required for TRL 7 certification.

CPE C2 — Common Platform Environment Command and Control. The U.S. Army program established a unified software and hardware standard for battlefield command and control across all platforms and echelons. Dragon Nexus 26-01 was initiated by the CPE C2 Trail Boss.

CSO — Commercial Solutions Opening. A DoD acquisition vehicle that allows the government to competitively solicit and acquire commercial technologies without a traditional contract award process.

ELMF — Efficient Large Message Fragmentation. TerraKinesis’s architecture for breaking large messages into fragments, transmitting them across the mesh, and reassembling them at the destination — maintaining sub-50 microsecond per-message latency even under contested RF conditions.

NACK Protocol — Negative Acknowledgment. Instead of confirming every message received (ACK), PULSE only signals when a message is missing. This reduces network overhead by 95–99% compared to standard ACK-based protocols.

NGC2 — Next Generation Command and Control. The U.S. Army program modernizing battlefield command and control infrastructure. The prime contract pathway referenced in the Path Forward section.

Node — A single end-user, smart device with computing on the network. Could be a sensor, phone, radio, or location transmitter.

OTA — Other Transaction Authority. A flexible DoD procurement mechanism that allows faster acquisition outside of traditional Federal Acquisition Regulation requirements.

xTech — funding that connects the U.S. Army with small businesses, startups, and academic institutions. It functions as an accelerator that awards cash prizes and follow-on government contracts to innovators whose technologies can solve critical military challenges.

SATCOM — Satellite Communications. A connection between ground-based infrastructure and an orbiting satellite. Expensive, limited in capacity, and unavailable in denied or contested environments.

TAK / ATAK — Team Awareness Kit / Android Team Awareness Kit. The U.S. military’s primary situational awareness application. Displays troop positions, GPS coordinates, and battlefield intelligence in real time.

TCP/IP — The standard internet communication protocol. Requires a confirmed handshake for every message sent, generating at least 2 overhead messages for every 1 delivered. Designed for stable, connected networks — not contested or denied environments.

TrellisWare TSM — A tactical software-defined radio waveform used by the U.S. military for mesh networking. The hardware platform on which PULSE was deployed at Dragon Nexus.

TRL — Technology Readiness Level. A 1–9 scale used by the U.S. Department of Defense to measure the maturity of a technology. TRL 6 = demonstrated in a relevant environment. TRL 7 = demonstrated in an operational environment.

UDP/Multicast — A lightweight messaging protocol that sends one packet to many recipients simultaneously without requiring individual confirmation. PULSE uses UDP/multicast as its transport layer.

Appendix A - Result 1: Making Radios Better

The problem is protocol-level. TCP/IP breaks down at 20 nodes. The Army’s SATCOM budget does not scale to meet demand, and at a 1-to-5 soldier-to-sensor ratio, the problem only compounds.

PULSE is firmware-based. No satellite dependency. It scales the network from 20 nodes toward 1,000. At Dragon Nexus 26-01, it held the line at 20 nodes — the exact point where legacy protocols fail.

On TrellisWare TSM radios, PULSE cut network-management overhead from 30% to 12% — a 60% reduction, 2.5× lower than baseline — while total network utilization held flat (26.7% → 29.9%). Same channel. Same radios. Same waveform. The only variable was PULSE. Delivery is sustained at 20 nodes, where TCP/IP collapses to 0%.

Figure 1 - Baseline vs. PULSE on TrellisWare TSM

Figure 2 - PULSE running as firmware over a TrellisWare TSM handheld radio

We expect to beat 60%. A deeper integration with TrellisWare this summer should drive the reduction higher.

Every point of channel PULSE gives back is mission throughput. Same radios. Same waveform. No new hardware. PULSE returns the channel to the warfighter.

Appendix B - Result 2: Enabling TCP/IP-based Application Across UDP/Multicast Infrastructure

Dragon Nexus 26-01 marked a first. TAK traffic crossed a TrellisWare TSM Barrage Relay mesh with no TAK serve. PULSE provides the surrogate functionality as a plug-and-play without integration with the TAK application. i

The mechanism was simple. ATAK EUDs streamed Cursor-on-Target messages over TCP/IP to PULSE — the same TCP stream they send to a TAK server, unchanged. PULSE terminated that stream outside the ATAK application logic, translated it into UDP multicast, and carried it across the Barrage Relay bubble, with decoding on the far end. No TAK server. No ATAK plug-in. PULSE operated at Layer 3/4 — external and agnostic to the application.

Figure 3 - Result 2 Visual

TAK is the common situational-awareness tool for the U.S. Department of War (DoW) and its allies. Making it work across a UDP/multicast network, in denied and degraded environments, on radios already in the field, is not a technical milestone. It is an operational one.

The novelty of PULSE is its position. It sits below the application, and that changes what is possible. Two benefits follow:

1. It connects to any TCP/IP-based application — Anduril’s Lattice, Palantir’s Foundry — without touching the application itself.

2. It does not chase application updates — a plug-in lives inside the application and breaks when the application changes. PULSE sits beneath it. When ATAK updates, when Lattice updates, PULSE does not move.
   

This is a technical document. It describes a computing architecture for reliable data convergence in large, complex edge systems without a central server. It compares two layers where that convergence can run. A Conflict-free Replicated Data Type (CRDT) is an application-layer data structure. It reconciles the state with the full semantic context. That context lets it send compact changes and optimize network load. It pays for that in latency. An Edge-Native Logic Management Firmware (ELMF) is the firmware-layer counterpart. It reaches the same convergence at the processing-board level. That optimizes latency and pays in network load. It works on data packets passing through the distributed system, not on application logic. Same property, opposite layer, opposite cost.

TerraKinesis’ PULSE implements an ELMF. It adds two mechanisms that make the firmware position optimal, not merely fast:

1. Negative Acknowledgment (NACK) scheme that keeps a node silent unless it has a gap to report.

2. Beehive architecture, which confines every repair to a local colony.

Together, they keep the network load cost flat and scale linearly. The latency advantage holds as the formation grows from tens of nodes into the thousands. The right layer depends on whether time is a mission constraint. Where it is, the ELMF wins.

What a CRDT Is

A Conflict-free Replicated Data Type (CRDT) is a data structure built so that many copies of it, held on separate machines, can be changed independently and still arrive at the same final state. Each copy applies its local changes at once. No copy waits for permission. When copies later exchange what changed, the merge produces an identical result on every machine. Order, duplication, and timing do not change the outcome. Consistency is a property of the data type itself. No central server arbitrates. No lock is held.

Why Peer-to-Peer Systems Need Convergence

A peer-to-peer system has no central server to put writes in order. Nodes join, drop out, and lose contact. Networks are split into pieces. Messages arrive late, out of order, or never. The traditional fix is to route every write through a single coordinator that determines the order. That fix fails at the edge. The coordinator becomes a single point of failure and a bottleneck. A node that cannot reach it is dead in the water.

Convergence solves this without a coordinator. A CRDT, or any mechanism that guarantees the same property, lets each node act on its own state immediately and reconcile with its peers afterward. This is the only model that survives a Denied, Degraded, Intermittent, and Limited-bandwidth (DDIL) environment. There, a reliable path to a central authority cannot be assumed.

The Stack: Firmware, Operating System, Middleware, Application

Software on a connected device is organized in layers. Each layer sits farther from the hardware than the one beneath it.

• Firmware layer. Code that runs on the device hardware itself, closest to the processor and the radio. It is deterministic, minimal, and fast.

• Operating System layer. Manages memory, scheduling, and the drivers that talk to hardware. It mediates between the hardware and everything above it.

• Middleware layer. Shared services that sit between the operating system and the program, including messaging, serialization, and discovery.

• Application layer. The program itself, where business logic lives. Most CRDT implementations run here today.

Where convergence runs in this stack is not a detail. It sets how far every update travels before it takes effect. The merged result travels the same distance back before it reaches the wire.

Figure 1. Convergence logic can live anywhere in the stack. The higher it sits, the farther every update must travel.

The Application Layer: Edge-Native Databases

Running convergence at the application layer is the model of the Edge-Native Database, built on CRDTs. It has a real benefit. The application holds rich context about what the data means. It can describe a change compactly. Instead of resending the entire message or a full copy of the state for every loss, the application exchanges a small set of changes and merges them. The result is less traffic spent recovering from misses. For a large class of systems, this is the right design. It is well understood.

The Penalty Is Latency

The penalty is latency. Application-layer convergence sits at the top of the stack. Every update climbs from the radio, through the operating system, through middleware, and into the application before it is processed. The merged result then travels the same path back down before it reaches the wire. Each layer adds delay. For a system where a late update costs nothing, this delay is invisible. For a system where a late update is a failure, it is the whole problem.

The Firmware Layer: PULSE ELMF

TerraKinesis takes a different approach. We move convergence to the firmware layer, closest to the processor and the radio. PULSE implements this as an Edge-Native Logic Management Firmware, or ELMF. The ELMF places the logic that reconciles state and repairs loss at the bottom of the stack. That removes the round-trip through the upper layers. An update is processed when it arrives.

An ELMF is not a Conflict-free Replicated Data Type in the traditional, application sense. It is not the same data-type construct. It does not concern itself with application logic. Its focus is the data packets moving across the distributed system. It makes them converge reliably at the processing-board level, regardless of what the application above makes of them. It behaves as a CRDT at that level. It delivers the defining property: coordinator-free convergence to a single consistent state. It carries none of the application-layer machinery. At the edge, the behavior is what counts, not the construct.

The Tradeoff We Accept

The comparison comes with a tradeoff. When you set a CRDT against an ELMF, you trade latency for network load.

This ELMF trade-off might be viable for small- to medium-sized peer-to-peer networks over large, stable links when a customer is looking for low latency. TerraKinesis PULSE is built for different use cases. Our customers operate large, complex formations over DDIL data links. There, an unbounded increase in network load is not survivable. To make convergence viable where they operate, TerraKinesis adds two mechanisms.

1. Negative Acknowledgment (NACK) approach to delivery. The most common protocol in the world, Transmission Control Protocol over Internet Protocol (TCP/IP), uses Acknowledgment (ACK). Every node confirms every message it receives. The confirmations flood the network and grow with traffic. PULSE inverts this. A node stays silent when it receives data correctly. It speaks only to report a gap. This reduces protocol overhead by 95-99% compared to ACK and TCP/IP.

2. Beehive architecture, which is patent pending. When a repair is required, Beehive localizes it. Nodes are organized into dynamic colonies of fifteen to twenty-five. A gap is repaired inside the colony rather than across the entire network.

The following video explains the problem:

Video 1: TCP/IP versus TerraKinesis NACK Approach [1:43]

The Numbers Hold the Claim

PULSE delivers 98 percent of messages at 30 percent packet loss. It holds per-message latency under 50 microseconds on hardware as small as an ESP32. It sustains 36 milliseconds end-to-end across 1,000 virtual nodes. The scaling shifts from O(n^2) to O(n). Inside the ELMF, NACK and Beehive beat application-layer Edge-Native Databases on the two axes that matter at scale: node count and latency. They beat even those that already use a NACK approach.

Figure 2. Network load as the formation scales. Global repair spreads recovery across the whole network, so load climbs with node count. Beehive confines repair to a colony, so the load stays bounded. Both curves are illustrative.

Figure 3. As a formation grows, the application-layer convergence cost climbs with the square of the node count. The ELMF grows linearly. The application curve is illustrative.

Validation

PULSE has been validated in two independent environments. The latency and scaling results above came from 20-node ESP32 hardware and runs of up to 1,000 virtual nodes. The reliability of the ELMF was measured separately. That test ran in the field, over a live TrellisWare TSM handheld radio.

Figure 4. PULSE running as an ELMF over a live TrellisWare TSM handheld radio. Zero packet loss across 150-plus messages. Inter-arrival timing holds in a 7-millisecond band: 996 minimum, 999 mean, 1003 maximum. This proves reliable delivery over a real waveform, not the latency or scale results measured on the hardware above.

Two independent legs support the same architecture. Synthetic runs establish latency and scale. A live radio establishes that the ELMF holds on a real waveform in the field. The next step is the large-formation field test. There, the linear-scaling claim meets a real network at a size.

Where Each Belongs

Application-layer Edge-Native Databases are the right tool when time is not a constraint. They are the home of point-of-sale systems for retailers and restaurants. A terminal can go offline, keep ringing up orders, and reconcile its inventory and tickets a second later with no harm done. They are the wrong tool when a late message is a failed mission. Drone warfare, intelligent transportation systems, and connected vehicles share one property: the value of a message decays in milliseconds. These systems need convergence close to processing, not at the top of the stack. They need an ELMF.

Build on the Right Layer

If you are building a system where latency is a mission constraint, the layer your convergence runs on is a decision you cannot defer. TerraKinesis builds PULSE. It is the messaging substrate that makes firmware-level convergence viable on hardware as small as a four-dollar microcontroller. We are validating it now at Dragon Nexus with the XVIII Airborne Corps.

To review the data or discuss how PULSE fits into your architecture, reach out to Mustafa Durrani at mustafa@terrakinesis.com.

Every layer assumes a different radio, a different waveform, a different piece of kit strapped to the warfighter or bolted onto the vehicle. When the Primary goes down, the unit switches to Alternate. When Alternate goes down, they switch to Contingency. And so on, until they reach Emergency — which usually means voice over HF and a prayer.

This model made sense when every pathway was a single point of failure. A radio. A satellite link. A frequency. One jammer pointed at the right frequency and the link was dead.

This model was a compromise. It made sense when compute at the edge did not exist, when processors on tactical nodes could not encode, decode, or repair data in real time, and when the gain from a smarter transport layer was not sufficient to justify the engineering effort. The technology was simply not there for COTS processors at the edge. So the military solved the problem with hardware redundancy instead of software intelligence — at the cost of increasing the warfighter’s fighting load.

That compromise is no longer acceptable. Edge compute is here. Processors that fit inside a cheap drone can execute forward error correction in milliseconds. The gain from a self-healing transport layer is no longer marginal — it is the difference between a formation that survives jamming and one that does not. Modern warfare demands mesh-scale communication across thousands of nodes in contested spectrum. The current model was not designed for that fight.

But what if the data link itself could not be killed with a single jammer? What if the mesh healed itself faster than the adversary could disrupt it? What if taking down the mesh required an emission signature so large that it became a target worth more than the data it was trying to silence?

That is the argument for a self-healing UDP/multicast data mesh. And that is what changes the PACE equation.

The Problem

Today’s military data links are point-to-point. One sender. One receiver. One pathway. Jam the path, interfere with it, or destroy a node along it, and the message does not arrive. Hub-and-spoke does not solve this. It scales it. Each spoke is its own point-to-point link to the hub. The hub is a single point of failure managing dozens of single points of failure. Take down the hub and every spoke goes dark.

The military compensates by layering redundancy. PACE is that redundancy. But PACE is expensive. Each layer requires its own hardware, its own spectrum allocation, and its own logistics supply chain. The four-system model is a SWaP-C problem, whether on a soldier’s rucksack or on a deployed drone.

The result is predictable. Drones today rely on a single data link. If that link gets jammed, the drone is lost. The warfighter loses situational awareness. The mission degrades.

This is not a technology problem. We have the technology today, ready to be fielded. It is an architecture problem, and it begins with a change in perspective.

Self-Healing Changes the Math

A UDP/multicast mesh does not rely on a single path. Every node in the mesh is both a sender and a receiver, and data propagates across multiple paths simultaneously. If one node is jammed or destroyed, the mesh routes around it automatically. No operator intervention. No switching to Alternate. No time wasted by the warfighter switching hardware or configurations.

This is the power of self-healing at the transport layer. The mesh detects losses. The mesh repairs them. It does both in microseconds — not the minutes it takes a human to recognize a link failure, diagnose the cause, and switch to a backup system.

PULSE is built with the single goal of accomplishing this: a true UDP/multicast mesh. This is done by building a full protocol from the bits up, based on NACK-based repair, forward error correction encoding and decoding in under 50 microseconds, and Beehive clustering that organizes nodes into self-managing groups.

Every node carries the logic to detect, repair, and reroute. No central controller. No single point of failure.

The mesh may still need a PACE plan, but it is far more resilient before it ever reaches for one. A self-healing mesh at the transport layer absorbs jamming, reroutes around lost nodes in DDIL environments, and restores data flow — all before a frequency hop is necessary. The mesh exhausts its own redundancy first. Primary, Alternate, Contingency, and Emergency are embedded in the topology itself. Every path is Primary. Every route is Alternate. The mesh provides all four layers simultaneously without four separate hardware stacks. When the mesh finally does jump to another frequency, it is a deliberate step — not a panicked fallback.

Figure 1 - A Self-Healing Mesh

The Jamming Paradox

Here is what most people miss about jamming a mesh.

A single-path data link is easy to jam. Point a directional jammer at the right frequency and the link dies. The adversary risks very little. The jammer can be small, mobile, and hard to detect, and it requires lower power output — giving it a smaller RF signature.

A true data mesh is different. Data travels across multiple paths and multiple nodes simultaneously. The adversary cannot kill the mesh by jamming one node or even a handful of nodes. The mesh reroutes. The mesh repairs. To actually suppress the mesh, the adversary must jam a significant number of nodes across a wide geographic area at the same time. That requires power on the order of kilowatts.

A lot of power.

And power of this magnitude corresponds directly to a very large signature.

A large-area, broadband jammer is one of the most detectable emissions on the battlefield. It lights up every signal intelligence sensor in the theater. It reveals its position like a flare in the night sky, becoming the first target in the tactical theater. Furthermore, jammers on the order of kilowatts are large, heavy, and bulky — typically mounted on a vehicle in a convoy, or located in a command post. It reveals position. It reveals capability. It reveals intent. In a modern fight where the first thing detected is the first thing killed, that jammer becomes a high-value target.

This creates a paradox for the adversary. To suppress the mesh, the adversary must employ a strategic asset — a high-power jammer — that is more valuable than the communications it is trying to silence. Furthermore, they must accept creating a large RF signature that reveals the position of wherever they deploy it. The cost of jamming quickly exceeds the cost of the data it disrupts.

Put differently: if the adversary is willing to light up a strategic jammer to kill your drone mesh, that jammer just became the priority target. And the warfighter now knows exactly where it is.

The mesh does not just survive jamming. It makes jamming expensive. And it turns the act of jamming into an intelligence gift and a new high-priority target.

A Simpler PACE for Cheap Drones

The implications for drone operations are significant.

Today, a military drone requires an expensive, purpose-built data link. Specialized hardware. Specialized waveforms. Specialized antennas. A single drone can cost tens of thousands of dollars just in communication equipment. And when that single link gets jammed, the drone becomes a very expensive paperweight.

A self-healing mesh changes this in three ways.

First, it eliminates the need for specialized communication hardware. PULSE runs on UDP/multicast over standard transport. It is compatible with commercial off-the-shelf radios and software-defined radios already in the inventory. No proprietary waveform. No vendor lock. The communication layer is software — measured in kilobytes — that runs on the constrained processors already inside cheap drones.

Second, it enables a simpler PACE plan. Instead of four hardware stacks, the drone carries one software-defined radio that cycles through a smaller range of RF frequencies. The mesh handles the rest. If one frequency is jammed, the drone hops to the next. If a node is lost, the remaining nodes reroute. The entire PACE framework collapses into a single software layer operating across a narrow frequency set.

Third, it makes the drone formation resilient at scale. PULSE scales linearly to 1,000+ nodes. A swarm of 500 cheap drones running PULSE does not need 500 individual data links managed by 500 individual PACE plans. The swarm is one mesh. One self-healing, self-organizing data fabric. Lose 50 drones to jamming or kinetic effects and the remaining 450 continue the mission without interruption.

Most importantly, the warfighter does not need to manage four communication layers. The warfighter points the swarm at the objective. The mesh handles the rest. And the warfighter stays focused and engaged in the mission.

Figure 2 - PACE Architecture versus UDP/Multicast Mesh

The So What

The current PACE model was designed for a world of single-path, single-hardware communication links. It is a brute-force approach to redundancy. More hardware. More weight. More power. More cost. More complexity.

A self-healing UDP/multicast mesh replaces brute-force redundancy with architectural resilience. The mesh provides multiple simultaneous paths without multiple hardware stacks. It heals faster than operators can diagnose. And it turns adversary jamming from a cheap disruption tool into an expensive, detectable strategic commitment.

For drone operations specifically, this means three things:

Cheaper, scalable hardware. Strip the expensive, proprietary data links. Replace them with COTS radios running PULSE. Reinvest the savings into more airframes.

Simpler operations. One mesh. One software layer. One narrow, automatic RF cycling plan. The warfighter manages the mission, not the communication stack.

Lethal formations. A resilient swarm of 500 cheap drones defeats an adversary that has optimized for killing expensive single-link platforms. The adversary cannot jam the mesh without revealing strategic assets. And the adversary cannot afford to kinetically engage 500 targets when each target costs less than the munition required to destroy it.

The mesh is not a communication system. The mesh is a weapon system. And it changes the cost calculus of the fight.

Subscribe to follow along. If you are building at the edge — defense or commercial — reach out. We are always looking to connect with people solving hard problems in large and complex environments.

Mustafa Durrani is the Co-Founder of TerraKinesis, a Detroit-based dual-use defense technology company. TerraKinesis builds PULSE — software that provides guaranteed message delivery in large, complex, and contested electromagnetic environments. He is a combat veteran, West Point graduate, and Chicago Booth MBA with 20+ years spanning the U.S. Army, General Motors, AWS, and defense technology.

Zafar Durrani is the Founding Engineer at TerraKinesis, a Detroit-based dual-use defense technology company. TerraKinesis builds PULSE — software that provides guaranteed message delivery in large, complex, and contested electromagnetic environments. He has a BS in Electrical Engineering from the Colorado School of Mines and 5 years of experience spanning the U.S. Army, Texas Instruments (TI), and the energy industry.

On April 3, 2026, an F-15E Strike Eagle from the 494th Fighter Squadron was shot down over southwestern Iran. Both crew members ejected. The pilot was rescued within hours. The weapons systems officer (WSO) was not.

The WSO landed alone in the Zagros Mountains. He carried a handgun, SERE training, and a Combat Survivor Evader Locator (CSEL) — an 800-gram satellite beacon integrated into his survival vest. The CSEL transmits encrypted location coordinates and short text messages to satellites. It uses rapid frequency hopping and ultra-short burst transmissions to reduce the probability of detection.

But every transmission creates an emission. The CSEL operates in a spoke-and-hub topology. The WSO is the spoke. The satellite is the hub. Iranian electronic warfare units and IRGC ground forces were hunting him across a constrained search area. Military officials confirmed that aircrews are trained not to broadcast continuously because the beacon can be detected by the enemy. So he rationed his communications. Short bursts. Long silences. Predefined text messages — “injured,” “enemy nearby,” “ready for extraction” — and limited voice. He hid in a mountain crevice for over 36 hours while hundreds of Iranian soldiers closed in and Iranian state television called on civilians to turn him over for a bounty.

The rescue required hundreds of special operations forces, dozens of aircraft, CIA deception campaigns, Israeli air support, and U.S. attack aircraft dropping bombs on approaching Iranian convoys. Two Black Hawk helicopters took fire. An A-10 Warthog was shot down. Two C-130 transport planes became stuck on an improvised airstrip and were deliberately destroyed to deny the enemy access to sensitive systems. At least one special operations helicopter was also destroyed.

The WSO survived. The mission succeeded. But the cost was extraordinary — and the fundamental constraint remains unchanged. A downed warfighter today must choose between communication and concealment. The architecture forces that trade-off.

The Problem

The CSEL is an impressive device. It does exactly what it was designed to do. The problem is the architecture it operates within.

Spoke-and-hub survival communications place all risk on a single point of failure: the warfighter. Every transmission — no matter how short, no matter how encrypted — originates from one point. The enemy does not need to break the encryption. The enemy only needs to detect the emission and triangulate the source. In a constrained search area like the Zagros Mountains, even frequency-hopping burst transmissions narrow the search.

This creates a binary choice. Transmit and risk detection. Stay silent and risk losing the link to rescue. The WSO in Iran chose long periods of silence, transmitting only at calculated intervals. That decision kept him alive. The architecture worked. But it worked at the margin. And margins shrink as adversaries improve. It will not work with a near-peer adversary such as China.

A Different Architecture

PULSE changes this calculus.

Imagine a pilot ejects over hostile territory. Upon ejection, 1,000 cheap, disposable nodes deploy across a 1,000-kilometer range. Each node is small, lightweight, and expendable. The dispersal methods are multiple and complementary: nodes can be air-dropped by friendly aircraft across the operational area, pre-positioned along known flight corridors before a mission, and integrated directly into the pilot’s ejection seat assembly and released on ejection. The concept mirrors existing expendable sensor deployments, such as sonobuoys in anti-submarine warfare — cheap, numerous, and designed to be lost. Each node runs PULSE and connects to overhead satellite constellations.

Every node transmits the same data across the mesh. The pilot communicates with commanders through the network, not through a single beacon. The enemy detects signals — but from 1,000 sources spread across a vast area. There is no single node to trace. There is no hub to target. There is no spoke to isolate.

The pilot hides in an isolated crevice, just as the WSO did in the Zagros Mountains, but remains continuously connected — hidden in plain sight inside a wall of redundant, indistinguishable transmissions. Commanders maintain real-time situational awareness. Rescue forces receive continuous position updates. The warfighter never has to choose between communication and concealment.

This is not theoretical. PULSE has been validated at 1,000+ nodes in virtual simulation. Physical hardware tests at 20 nodes match the simulation results. The code runs on hardware as small as a $4 microcontroller. No server-grade compute. No cloud dependency. No SATCOM backbone required.

Figure 1 — Spoke-and-Hub vs. PULSE Mesh Architecture

Why This Works

PULSE runs over UDP/multicast and provides guaranteed messaging using its intelligent layer and the Beehive group. It can easily scale to 1,000 nodes on a single network. A detailed technical breakdown of PULSE — including the negative acknowledgment (NACK) and Beehive colony repair mechanics — is available in our companion article:

mustafa@terrakinesis.com

TerraKinesis' PULSE: Guaranteed Messaging in Large, Complex, and Contested Electromagnetic Environments.

Over the past month, I have been writing LinkedIn posts about what it takes to build a technology company from scratch — working backwards from the customer, identifying constraints, understanding what scale actually means, and designing based on first principles. Today, I am sharing what we have been building…

Read more

4 months ago · 4 likes · mustafa@terrakinesis.com

This architecture provides three advantages in a survival communications scenario. First, signal ambiguity. One thousand identical transmissions across a 1,000-kilometer footprint make it operationally infeasible for an adversary to determine which node is proximate to the warfighter. Second, continuous connectivity. The pilot does not ration transmissions. The network absorbs the communication load. Third, resilience under jamming. PULSE maintains guaranteed message delivery under 71% packet loss. If the enemy jams a cluster of nodes, the remaining mesh self-heals and re-routes.

The network becomes a shield. The warfighter becomes invisible inside it.

What This Means

The F-15E rescue in Iran will be studied for years. It demonstrated extraordinary courage, coordination, and capability. It also exposed a structural vulnerability in the Department of War’s communication with isolated warfighters in hostile territory.

The next pilot who ejects over hostile territory should not face the same trade-off. The architecture should not force a warfighter to choose between communication and concealment. PULSE eliminates that choice. The network provides both.

In May 2026, TerraKinesis will demonstrate PULSE with the US Army. That demonstration will validate what we have proven in simulation: guaranteed messaging at 1,000+ nodes on the transport infrastructure already deployed at the tactical edge. The scenario in the Zagros Mountains is exactly the kind of problem PULSE was built to solve.

With PULSE, we imagine the world differently. Not just data delivery. Survivability.

TerraKinesis is a Detroit-based, VC-backed, dual-use technology company. Our first demonstration with an Army unit is targeted for May 2026. If you are building at the edge and need guaranteed messaging at scale, contact us at mustafa@terrakinesis.com.

In my first article, I introduced PULSE — intelligent software that provides guaranteed messaging in large, complex, contested electromagnetic environments. We built PULSE for the Department of Defense’s hardest problem: real-time command and control across 1,000+ nodes on the tactical edge, with no cloud, no SATCOM, and no stable backbone.

That problem is not unique to the battlefield.

Two commercial sectors face the same fundamental physics. Intelligent transportation systems cannot guarantee a message between two vehicles 100 meters apart. And the modern automobile cannot guarantee a message between two electronic control units separated by 5 kilometers of copper wire that degrades every day it is on the road.

Both problems trace back to the same root cause: a reliance on architectures that were designed for stable, centralized infrastructure — applied to environments that are anything but.

PULSE solves both.

Part I: Intelligent Transportation Systems — The Nuclear Chain Reaction the Industry Chose to Avoid

The Original Vision — And Why It Failed

The intelligent transportation systems (ITS) community identified the vehicle-to-everything (V2X) problem over two decades ago. In 1999, the FCC allocated 75 MHz of spectrum in the 5.9 GHz band specifically for transportation safety. The original technology — Dedicated Short-Range Communications (DSRC) — was built on IEEE 802.11p, a peer-to-peer standard designed for direct vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication within roughly 1 kilometer.

DSRC was the right idea. Vehicles talking directly to each other. No middleman. No backbone dependency. Real-time safety messaging at the speed of radio.

But DSRC had a scaling problem. The same scaling problem the military discovered with TCP/IP-based command and control. As the number of vehicles on a DSRC mesh grew, the protocol could not guarantee message delivery across all participants. Collisions increased. Latency became unpredictable. Reliability degraded under load. The ITS community called it a nuclear chain reaction — a cascade failure where every additional node compounds the problem for every other node.

The industry had a choice: solve the peer-to-peer scaling problem, or route around it.

They routed around it.

The Pivot to Cellular — A Short-Term Compromise

In 2017, 3GPP standardized Cellular-V2X (C-V2X), a new approach that leveraged existing cellular networks to enable vehicle-to-network (V2N) communication alongside direct V2V. By 2020, the FCC reallocated the 5.9 GHz spectrum, sunsetting DSRC in favor of C-V2X. In November 2024, the FCC adopted final rules establishing a two-year sunset for all remaining DSRC operations.

The logic was sound. Cell towers are everywhere. Cellular infrastructure is maintained, funded, and continuously upgraded by carriers with deep capital. The C-V2X pivot eliminated the peer-to-peer scaling problem by moving traffic through managed infrastructure. It was the hub-and-spoke answer to a mesh problem.

This is the exact same architectural trade-off the military made — and for the same reason. Hub-and-spoke works when the backbone is available. It is the path of least resistance. And for the majority of ITS use cases — traffic signal optimization, fleet management, route planning — it is adequate.

But it does not solve the killer use case.

The Latency Problem No One Wants to Talk About

Two vehicles are approaching an intersection. They are 100 meters apart. One is about to run a red light. The other needs to know — now.

Under C-V2X with cellular backhaul, that safety message does not travel 100 meters. It travels from Vehicle A up to a cell tower, through the carrier’s core network, and back down to Vehicle B. Depending on network load, that round trip can take 50 to 200 milliseconds through the internet backbone. At highway speeds, 100 milliseconds is 3 meters of travel distance. At intersection speeds in an urban environment, it is the difference between a near-miss and a collision.

C-V2X does include a direct communication mode — the PC5 sidelink interface — that supports V2V without cellular infrastructure. But PC5 inherits the same peer-to-peer scaling limitations that sank DSRC. As vehicle density increases, PC5 message reliability degrades. The industry is back to the same nuclear chain reaction, just on a different radio standard.

This is the fundamental tension in intelligent transportation: the use cases that matter most — collision avoidance, emergency braking coordination, intersection safety — require both low latency and guaranteed delivery at scale. No architecture on the market today delivers both simultaneously.

What PULSE Changes

PULSE was built to solve exactly this problem — guaranteed messaging across large numbers of nodes on peer-to-peer radio links, without backbone dependency.

Layer PULSE on top of the direct V2V link — whether DSRC, C-V2X PC5, or any future sidelink standard — and the nuclear chain reaction disappears. PULSE’s NACK-based repair engine and Beehive distributed architecture handle the scaling problem at the transport layer. Vehicles that miss a safety message get repaired by their nearest neighbors in under 1 millisecond. No round trip to a cell tower. No backbone bandwidth consumed. No cascade failure as density increases.

The result: direct V2V communication that scales. The original DSRC vision — vehicles talking to each other at the speed of radio — but with guaranteed delivery that holds under real-world density.

The So What

PULSE enables safer vehicles and less congestion by providing the guaranteed V2V messaging layer that makes intersection collision avoidance, cooperative adaptive cruise control, and emergency vehicle preemption actually work at density. Not on a test track. Not in a pilot with 12 equipped vehicles. At the scale of a real city, with thousands of connected vehicles operating simultaneously.

This is also the unlock for autonomous vehicles. The industry’s current approach to autonomy treats every vehicle as an isolated sensor platform — relying on cameras, radar, and LiDAR to perceive the world independently. That is the hard way. A vehicle that can see around corners, through buildings, and a mile down the highway — because other vehicles and infrastructure are sharing guaranteed real-time state — does not need to solve perception from scratch. It already knows.

Connected infrastructure does not replace onboard sensors. It makes them radically more effective. But connected infrastructure requires guaranteed messaging at scale. Without it, the shared state is a suggestion. With PULSE, it is a contract.

The autonomous vehicle future does not depend on better cameras, models, and computers. It depends on better communication. I will go deeper on this in a future post — including why the current perception-only approach has a physics ceiling that no amount of computation will overcome, and how PULSE changes the math.

Part II: The Software-Defined Vehicle — Wireless is More Reliable Than Wired

The Hidden Fragility of Copper

Here is a fact that surprises people outside the automotive industry: the wiring harness is one of the three heaviest subsystems in a modern vehicle. A luxury SUV carries 60 to 80 kilograms of wire — up to 5 kilometers of copper conductors connecting more than 4,000 individual connection points across 2,000+ separate circuits.

Every one of those connections is a potential failure point.

Copper wires flex every time a door opens. They vibrate with the engine. They bake under the hood and freeze in the wheel wells. They corrode at connectors. They chafe against body panels. Over the life of a vehicle, wires break. Insulation cracks. Connections loosen. And when a wire fails in a safety-critical circuit — antilock braking, stability control, airbag deployment — there is no fallback. The signal path is gone.

The Controller Area Network (CAN bus) that carries safety-critical messages inside a vehicle was first deployed in 1991. It is a serial bus that operates at up to 1 Mbps — a fraction of what modern vehicle systems demand. CAN messages traverse copper wires with typical propagation delays of 0.1 to 0.2 milliseconds per frame, but under heavy bus load, worst-case latencies can reach several milliseconds due to priority-based arbitration. And the entire system has a single point of failure: the wire itself.

A Surprising Discovery

When we built PULSE for the edge, we optimized for a specific environment: contested radio links, high packet loss, distributed nodes that move. We designed the Beehive architecture to create redundant repair paths so that no single failure could break the data mesh.

Then we realized: the inside of a vehicle is the same problem at a smaller scale.

Electronic control units (ECUs) distributed throughout a vehicle need guaranteed messaging between them. The distances are shorter — meters instead of kilometers — but the reliability requirement is identical. A brake command cannot be dropped. An airbag trigger cannot be delayed. A stability control correction cannot arrive late.

PULSE creates a self-healing wireless data mesh inside the vehicle. Multiple radio paths exist between any two ECUs. When one path degrades — due to interference, physical obstruction, or component failure — PULSE repairs through an alternate path in under 1 millisecond. The encode/decode latency of PULSE is 50 microseconds. That is faster than a CAN frame traverses the copper wire it is printed on.

Wireless is not replacing wired because wireless is cheaper. Wireless is replacing wired because wireless is more reliable. A copper wire has one path. A wireless mesh has many. A copper wire degrades over time through wear, corrosion, and mechanical stress. A wireless mesh adapts in real time. A copper wire that is cut stays cut. A PULSE mesh that loses a path reroutes in microseconds.

The So What

Weight and Cost. A typical vehicle contains 5 to 10 kilometers of copper wiring. That wire weighs 40 to 80 kilograms. Replace it with a wireless mesh and that mass disappears.

For electric vehicles, every kilogram matters. A 40 to 80 kilogram reduction extends range by 2 to 4 percent — with zero change to the battery or powertrain. For all vehicles, the impact goes far beyond weight.

The wiring harness is one of the last major subsystems that cannot be automated. It is assembled by hand. Every branch, every connector, every routing path adds labor hours, tooling, and failure modes. Reducing harness complexity does not just save material. It changes the production equation.

For a typical vehicle, replacing copper with PULSE delivers:

• 40 to 80 kg of mass elimination — no redesign required

• 2 to 4 percent range extension on electric platforms — free mileage

• 5 to 10 percent reduction in vehicle piece cost — driven by material savings, labor reduction, and simplified assembly

The wiring harness is the heaviest, most labor-intensive, least automatable component in the vehicle. PULSE makes it optional.

Redundancy and Safety. Today, a single wire failure in a safety-critical circuit means the signal is gone. There is no fallback. The industry’s answer is hardware redundancy — duplicate wiring, duplicate ECUs, duplicate sensors — to brute-force reliability. Every duplicate adds weight, cost, and complexity. For autonomous vehicles, where safety-critical circuits multiply by an order of magnitude, the redundancy tax is enormous.

PULSE eliminates the need to solve redundancy with hardware. Multiple wireless paths between any two ECUs mean that a single failure — or multiple failures — do not break the safety chain. The vehicle heals itself. Software-defined redundancy at the transport layer replaces copper-defined redundancy at the physical layer. Less weight. Lower cost. Higher reliability.

Future-Proofing. Every major OEM is moving toward a software-defined vehicle (SDV) architecture — high-bandwidth, low-latency, centralized computing with modular service deployment. CAN bus cannot support it. The bus was designed in 1983 for a world with a handful of ECUs. The modern vehicle has over 100.

Automotive Ethernet is the leading alternative. But Ethernet still runs on copper or fiber. It still has single points of failure. It still adds weight. And it still requires the same hand-assembled harness that CAN does — just with higher-bandwidth cable.

PULSE provides a wireless transport that supports SDV architecture requirements without the physical constraints of wired infrastructure. Over-the-air updates. Modular ECU deployment. Dynamic service routing. All without touching the harness. The vehicle communication architecture becomes software. And software scales.

One white elephant we have not addressed: power. ECUs still need it. There are several approaches worth exploring — fewer copper runs dedicated solely to power delivery, harvesting energy from vehicle motion, wireless power transfer. We will tackle power in a future post. Subscribe to this Substack link to follow along.

Three Sectors. One Problem. One Solution Pattern.

The intelligent transportation system and the software-defined vehicle face the same fundamental challenge: guaranteed messaging across distributed nodes in complex environments.

On the road, the infrastructure is the cellular network — available most of the time, but not all of the time, and never fast enough for the use cases that save lives.

Inside the vehicle, the infrastructure is the copper wire — reliable when it is new, but degrading every day, with no redundancy when it fails.

PULSE sits above both. It does not replace the radio link between vehicles or the network inside them. It guarantees that the messages those links carry actually arrive — on time, every time, at scale.

Now consider what happens when these layers connect.

A vehicle running PULSE internally — ECU to ECU, wireless mesh, self-healing — rolls onto a highway where PULSE is running externally — vehicle to vehicle, guaranteed delivery, no backbone dependency. The same transport layer. The same protocol. The same guarantee. An airbag sensor inside the vehicle and a collision warning from a vehicle 500 meters ahead are both PULSE messages. They are both guaranteed. They both arrive in under 1 millisecond.

And when that vehicle operates in a tactical convoy, the same PULSE mesh extends to the command post. Vehicle-to-vehicle on the road. ECU-to-ECU inside the vehicle. Vehicle-to-C2 on the tactical network. Three domains. One protocol. One guarantee.

No one else is building this. No one else is even thinking about it.

This is how TerraKinesis extends PULSE into the commercial sector. The physics are the same. The architecture is the same. The guarantee is the same.

Are you ready to build?

In the next post, I will discuss the trade-offs — what we optimized for, what we deliberately left on the table, and why those decisions matter for both defense and commercial applications.

Mustafa Durrani | Co-Founder, TerraKinesis, mustafa@terrakinesis.com | www.terrakinesis.com

TerraKinesis is a Detroit-based, VC-backed, dual-use technology company. My co-founders and I developed PULSE — intelligent software that provides guaranteed messages in large, complex, contested electromagnetic environments. We built PULSE because no solution on the market today can guarantee message delivery across 1,000+ nodes on the transport infrastructure already deployed at the edge.

Introduction to TerraKinesis

TerraKinesis is a Detroit-based, VC-backed, dual-use technology company. My co-founders and I developed PULSE — intelligent software that provides guaranteed multicast messaging in complex, contested electromagnetic environments. We built PULSE because no solution on the market today can guarantee message delivery across 1,000+ nodes on the transport infrastructure already deployed at the edge.

The Problem

The modern battlefield is moving toward distributed, autonomous formations — crewed vehicles, uncrewed systems, sensors, and dismounted warfighters operating across air, ground, and sea. Commanders need real-time command and control (C2) of 1,000+ edge nodes in contested, denied, degraded, intermittent, and limited (DDIL) environments. No SATCOM. No cloud. Only the radios and computers that are on warfighters, their vehicles, and unmanned drones.

Not every message carries the same weight. Position location information (PLI) — the continuous stream of where every asset is on the battlefield — is best-effort. Individual updates are perishable. If one is dropped, the next one arrives in seconds. That is acceptable.

But a commander also needs to know whether a drone has hit its target. That message cannot be dropped, delayed, or assumed. It drives the next decision — whether to re-engage, redirect assets, or clear the airspace. In a distributed formation operating without cloud or SATCOM, there is no fallback. If that message does not arrive, the commander is making the next call blind.

Today, guaranteed message delivery over peer-to-peer data meshes — such as UDP/Multicast — breaks down at roughly 20 nodes with standard solutions. Newer approaches have reached approximately 150 nodes but require a dedicated database instance on every node. Neither comes close to the 1,000+ node formations the Army is driving toward. The new breed of solutions demands a compute footprint that existing edge hardware cannot support.

Existing approaches either:

1. Avoid the problem entirely by building a hub-and-spoke architecture dependent on SATCOM, 5G, and Wifi— an approach that fails the moment connectivity to the backbone is lost.

2. Attempt to compensate with forward error correction layered on top of retransmit-based repair — creating a bottleneck that compounds under stress. When burst jamming destroys a large fraction of transmitted packets, nodes simultaneously flood the sender with repair requests. Each failure consumes backbone bandwidth and degrades the control loop.

Both approaches break precisely when they are needed most. Until now, hub-and-spoke has been the only viable option at scale — a limitation the US Army is working to solve in Next Generation Command and Control (NGC2).

What We Built

PULSE sits above any existing hardware stack and is built for the infrastructure already deployed at the tactical edge. No hardware changes. No rip-and-replace. If it can send and receive data, PULSE runs on it. It turns any packet-based link into a resilient, guaranteed multicast transport.

To understand what makes PULSE different, start with how the internet handles reliability. TCP/IP uses acknowledgements (ACKs) — every receiver confirms receipt of each packet. That works when connectivity is supported by stable infrastructure: national wireless carriers, landlines, SATCOM, and the internet backbone. It does not work when you have 1,000+ nodes in a jammed environment, because the confirmation traffic itself becomes the problem.

This is the three-way handshake: Node A sends a message to Node B. Node B sends an acknowledgement (ACK) back to Node A. Node A then sends an ACK back to Node B confirming receipt of the acknowledgement. Only after that third step is the message considered delivered. At two nodes on a stable infrastructure, this is fast and reliable.

At 1,000+ nodes in a contested electromagnetic environment, every message requires three trips across a degraded radio link — and every failed acknowledgement triggers the cycle again. The confirmation traffic compounds until the network collapses under its own overhead.

PULSE operates on the opposite paradigm: negative acknowledgement (NACK). Nodes stay silent unless something goes wrong. Only failures generate traffic. This is the right foundation for the edge — but even NACK-Oriented Reliable Multicast (NORM), the most common NACK-based approach on the market, carries significant overhead that limits it to approximately 150 nodes in complex environments.

PULSE simplifies NORM’s core algorithm — delivering equivalent performance across 95% of DDIL conditions while processing 1,000 times faster and running on 1/1,000th of the codebase. The same reliability. A fraction of the weight.

Beehive: Distributed Repair at Scale

When a NACK does occur, PULSE does not route the repair request back to the original sender. Instead, PULSE organizes nodes into colonies — clusters that can repair each other locally without touching the backbone. We call this the Beehive architecture.

When a node fails to receive a message, its nearest healthy neighbors — already organized into a colony — broadcast the repair in pre-assigned time slots. Recovery completes in under 1 millisecond. The sender is never involved. Backbone bandwidth is never consumed. The control loop is never interrupted.

PULSE demonstrates a pathway to 1,000+ nodes under 71% packet loss in a self-healing data mesh. The PULSE logic is hardware agnostic, from a $4 microcontroller to a $100K Klas Voyager. The codebase runs on bare-metal algorithms with no dependencies on external libraries, which keeps the integration surface small. Integrating PULSE with existing applications and transport layers takes 2 to 4 weeks.

The Results

PULSE has been validated at 1,000+ nodes in virtual simulation — the formation size the Army is driving toward with NGC2. Our 20-node physical hardware tests match the simulation results, giving us confidence that the architecture scales as designed.

The numbers that matter to commanders:

• 167–833 times lower repair latency — recovery completes before a retransmit request is ever generated

• Zero backbone cost per repair — no bandwidth consumed on the control network

• Full control-loop preservation — operating at full rate versus 47% degraded under the alternative

• Hardware agnostic — runs on compute as small as a $4 microcontroller in under 1,000 lines of code, no server-grade compute required

PULSE supports 1,000+ nodes — 7 to 50 times the scale of anything on the market. It processes data 1,000 times faster on a fraction of the code footprint.

At its core, PULSE is a data engine — it encodes and decodes packets. It works irrespective of the transport layer, as long as the transport provides a data link. Radio, mesh, serial, custom RF — if it moves bytes, PULSE runs on it.

A technical breakdown — design decisions, trade-offs, and what we deliberately left on the table — is coming in a follow-on post. Whitepaper drafts covering what we built and the results are available upon request at mustafa@terrakinesis.com.

Why this Matters

The Department of War (DoW) is investing heavily in distributed, autonomous operations. The Army’s Next Generation Command and Control (NGC2) program — $2.9B in the FY2026 budget — is driving toward formations with 1,000+ heterogeneous assets. The Defense Innovation Unit is actively seeking edge-native C2 solutions. CJADC2 has a dedicated office signaling strategic priority across all services.

The gap: existing solutions are built for server-grade, cloud-centric environments. SATCOM and enterprise computers are unavailable to warfighters where they operate. PULSE fills this gap — delivering guaranteed C2 messaging at scale on the infrastructure already deployed.

PULSE does not replace a partner’s waveform, radio layer, or C2 stack. It sits above them as a plug-and-play microservice, turning any packet-based link into a resilient multicast transport with built-in local repair. No changes to existing hardware. Software-only, designed to integrate — not compete.

Where Are We

TerraKinesis is a pre-seed, Detroit-based, dual-use technology company backed by a well-known VC. We have a working proof of concept validated at 1,000+ nodes in virtual simulation and 20 nodes on physical hardware. We are currently in discussions with the US Army and defense prime stakeholders for technology demonstrations and formal partnerships. First demonstration with an Army unit is targeted for May 2026.

We built PULSE because we lived with the problem. Between us, the founding team brings decades of experience across automotive engineering, distributed systems, defense technology, and autonomous platforms. We saw firsthand that the tools being built for complex edge environments could not scale on the available hardware and transport.

So we built something that could.

What is Next

This article is the first in a series. In the coming weeks, we will publish:

• A head-to-head comparison of PULSE against QUIC and NORM.

• A deep dive into the technical trade-offs behind PULSE — design decisions, what we optimized for, and what we deliberately left on the table.

• An exploration of PULSE extensions into the commercial sector — where reliable multicast at scale matters beyond the battlefield.

Complex, Large-Scale Edge systems have a Data Problem. We are Solving It. Are You Ready to Join Us?

If you are building at the edge and need guaranteed messaging at scale, let’s talk.

Mustafa Durrani | Co-Founder & CEO, TerraKinesis mustafa@terrakinesis.com | www.terrakinesis.com

#PULSE #TerraKinesis #DefenseTech #EdgeComputing #C2 #MeshNetworks #GuaranteedMessaging #UDP/Multicast #Building #workingbackwards #scale #constraints #firstprinciples #NGC2 #CJADC2