What's Inside a Semcom Binary?

A complete RSA cryptosystem in 160 bytes more than "Hello World." No runtime. No dependencies. No supply chain. Just verified machine code.

The Comparison

We built a toy RSA encryption tool — keygen, encrypt, decrypt — using Semcom's verified modular exponentiation capability. Then we measured.

Hello World

33,432 bytes

Standard C program. printf("hello")

RSA Demo

33,592 bytes

Keygen + encrypt + decrypt. Verified modular exponentiation.

The difference: 160 bytes. That's the entire RSA implementation — a verified modular exponentiation function compiled to 29 ARM64 instructions. Everything else is the same Mach-O container overhead that any program pays.

What's in the Binary

Binary Breakdown: RSA Demo (33,592 bytes)

Mach-O headers + load commands~4 KB
Code signature~4 KB
Symbol table + string table~4 KB
Glue code (argv parsing, printf, dispatch)~4 KB
String constants ("keygen", "n=3233 e=17 d=2753")~200 B
mod_exp — the verified RSA math116 B
Total33,592 B

The verified capability — mod_exp, 33 lines of LLVM IR compiled to 29 machine instructions — is 0.3% of the binary. The rest is operating system packaging.

The Docker Container

On Linux with static linking, the binary is 67KB. In a FROM scratch Docker container, that's the entire image.

Node.js app
~1 GB
Python app
~400 MB
Go binary
~15 MB
Alpine Linux
~9 MB
Semcom
96 KB

Zero supply chain.

The container has one file. No package manager. No OS. No libraries. No node_modules. No requirements.txt. Nothing to CVE. Nothing to patch. Nothing to audit except the binary itself.

The Verified Source

The mod_exp function — modular exponentiation via repeated squaring — was synthesized by the Semantic Compiler. It was validated against test cases, verified for semantic correctness, and installed permanently in the Method Dictionary. This is the complete source:

define i64 @mod_exp(i64 %base, i64 %exp, i64 %mod) { entry: %mod_is_one = icmp eq i64 %mod, 1 br i1 %mod_is_one, label %return_zero, label %loop_init loop_init: %base_mod = srem i64 %base, %mod br label %loop loop: %result = phi i64 [1, %loop_init], [%result_next, %loop_body] %b = phi i64 [%base_mod, %loop_init], [%b_next, %loop_body] %e = phi i64 [%exp, %loop_init], [%e_next, %loop_body] %done = icmp eq i64 %e, 0 br i1 %done, label %return_result, label %loop_body loop_body: %odd = and i64 %e, 1 %is_odd = icmp eq i64 %odd, 1 %mul_result = mul i64 %result, %b %mul_mod = srem i64 %mul_result, %mod %result_next = select i1 %is_odd, i64 %mul_mod, i64 %result %b_sq = mul i64 %b, %b %b_next = srem i64 %b_sq, %mod %e_next = lshr i64 %e, 1 br label %loop return_result: ret i64 %result return_zero: ret i64 0 }

33 lines. Synthesized from intent, validated with test cases, compiled to 29 machine instructions. Every program built with Semcom has this level of transparency.

What This Means

Traditional Software

Source code → compiler → binary. Trust the developer. Trust the compiler. Trust 1,200 transitive dependencies you've never read.

Semcom

Intent → verified IR → binary. Every function has test evidence. Every capability is inspectable. The supply chain is empty because there is no supply chain.