669 bytes.
That's how much data CAP XML — the industry standard — needs to tell a computer: there's a fire in Building A, evacuate now.
We compressed it to 8 bytes. Same core machine-readable alert semantics. Need payload and signatures? Typical Envelope size is still under 100 bytes.
Here's what that looks like:
Format Bytes
─────────────────────────────────
CAP XML (OASIS) 669 ████████████████████████████████████
JSON over HTTP 270 ██████████████
ECP Envelope 45-100 █████
ECP Token (UET) 8 █
That's not a typo. 8 bytes for a complete minimal machine alert — type, priority, zone, timestamp, and action flags. The 8-byte token (UET) is the minimal format. Need payload and HMAC signatures? That's the Envelope: 45-100 bytes, still 85-93% smaller than CAP.
If you work with LoRa, BLE, satellite, or any bandwidth-constrained network — this is your problem too. Not just emergencies: any structured message that needs to travel light.
Why does this matter?
LoRa transmits at 300 bytes/sec. BLE has a 20-byte MTU. Satellite links charge per byte. Industrial SCADA networks have real-time constraints. In those environments, 669 bytes is not just wasteful — it may not arrive at all.
We built ECP because we ran into this problem ourselves. We operate an emergency management system for airports, railways, and ports. When we measured our real traffic, the numbers were clear: most of the bandwidth was format overhead, not actual emergency data. But the protocol works for any domain where bytes matter.
Show me the code
Install the package (requires .NET 8 SDK):
dotnet add package ECP.Core
One line to send a fire alert
using ECP.Core;
using ECP.Core.Models;
byte[] alert = Ecp.Alert(EmergencyType.Fire, zoneHash: 1, priority: EcpPriority.Critical);
// alert.Length == 8
That's it. alert contains emergency type, priority, zone, timestamp, and action flags. 8 bytes.
Need more data? Use an Envelope
using ECP.Core;
using ECP.Core.Models;
byte[] hmacKey = new byte[32]; // load your key from secure storage
var envelope = Ecp.Envelope()
.WithType(EmergencyType.Earthquake)
.WithPriority(EcpPriority.Critical)
.WithPayload("Evacuate Building A via Stairway B")
.WithHmacKey(hmacKey)
.Build();
// 45-100 bytes, cryptographically signed
Decode anything with one call
using ECP.Core;
using ECP.Core.Models;
byte[] incomingBytes = GetIncomingBytes();
if (Ecp.TryDecode(incomingBytes, out var message))
{
if (message.IsUet)
Console.WriteLine($"Type: {message.Token.EmergencyType}");
else if (message.IsEnvelope)
Console.WriteLine($"Payload: {message.Envelope.PayloadType}");
}
static byte[] GetIncomingBytes() => Array.Empty<byte>();
Three API levels. One for quick alerts, one for signed envelopes, one for full control. You pick what you need.
Real numbers, not marketing
We didn't build this in a lab and hope it works. During development and internal testing of our emergency management platform, ECP has processed 263,000+ system events — monitoring, operational traffic, and integration tests — with an average 96% data reduction.
| Metric | Value |
|---|---|
| System events (internal testing) | 263,000+ |
| Average data reduction | 96% |
| CAP XML → ECP savings | 85-93% |
| JSON → ECP savings | 63-83% |
| Zero-allocation encode | Yes (WriteTo(Span<byte>)) |
Instant visual proof (no install) — see the comparison in 5 seconds, right in your browser.
Want to verify independently? Clone the repo and measure on your machine:
git clone https://github.com/Egonex-Code/ecp-protocol.git
cd ecp-protocol/samples/ProofCard
dotnet run
Want to see the raw payloads? Add -- --show-payload to see CAP XML, JSON, and ECP side by side.
Full benchmarks are also in the repo (benchmarks/ECP.PublicBenchmarks) if you want to measure throughput and allocation on your hardware.
What's inside
ECP is not a single package — it's a modular SDK. Use only what you need:
| Package | Purpose |
|---|---|
ECP.Core |
Encoder/decoder, UET token, Envelope, HMAC security. Start here. |
ECP.Registry |
Semantic compression, multilingual templates |
ECP.Cascade |
P2P broadcast with O(log N) fan-out |
ECP.Transport.WebSocket |
WebSocket delivery |
ECP.Transport.SignalR |
SignalR delivery |
ECP.Compatibility |
JSON-to-ECP migration bridge |
ECP.Core has zero external dependencies — it uses only .NET 8 BCL. No Newtonsoft, no Protobuf, no MessagePack. Just System.Security.Cryptography and BinaryPrimitives.
Why open source?
Multiple patents have been filed (UIBM, Italy) covering the protocol design. The core implementation is released under Apache 2.0.
Why? Because emergency communication shouldn't have a paywall. If a LoRa sensor in a remote area needs to send a fire alert in 8 bytes, it should be able to — without licensing fees.
The patents protect the innovation. The open source license lets everyone use it.
What ECP does NOT do
Transparency matters, so here's what ECP is not:
- Not a complete emergency management system. ECP is the wire protocol — the encoding layer. You still need your own dispatch, routing, and UI.
- Not a CAP replacement for all scenarios. If you have reliable broadband and need full CAP interoperability, CAP works fine. ECP targets constrained environments.
- Not battle-tested at internet scale. 263,000+ system events during internal testing is meaningful, but it's not millions. We're publishing everything so the community can help push those boundaries.
Try it
dotnet add package ECP.Core
Write your first alert. Check the output. Count the bytes.
If you want the full picture:
What would you encode in 8 bytes? IoT sensor readings? Satellite telemetry? Fleet tracking? Something we haven't thought of?
We built this for emergencies — but 8 bytes is 8 bytes. If you have a use case where every byte counts, we'd like to hear about it. Post your ProofCard run ID in the comments.
Found it useful? A ⭐ on the repo helps others find it.
Top comments (0)