Concrete does not have</th>	Rationale</th></tr></thead>
Garbage collection</td>	Predictable latency, explicit resource management</td></tr>
Hidden control flow</td>	Auditability, debuggability</td></tr>
Hidden allocation</td>	Performance visibility, allocator control</td></tr>
Interior mutability</td>	Simple reasoning, verification tractability</td></tr>
Reflection / eval</td>	Static analysis, all paths known at compile time</td></tr>
Global mutable state</td>	Effect tracking, reproducibility</td></tr>
Variable shadowing</td>	Clarity, fewer subtle bugs</td></tr>
Null</td>	Type safety via `Option<T></code></td></tr>`
Exceptions</td>	Errors as values, explicit propagation</td></tr>
Implicit conversions</td>	No silent data loss or coercion</td></tr>
Operator overloading</td>	Operators are primitive, not trait methods</td></tr>
Uninitialized variables</td>	Memory safety</td></tr>
Macros</td>	Undecided; if added, will be hygienic and capability-aware</td></tr>
Closures</td>	Hidden captures are implicit allocation and data flow</td></tr>
Concurrency primitives</td>	Undecided; must preserve linearity and determinism</td></tr>
Undefined behavior (in safe code)</td>	Kernel semantics fully defined</td></tr> </tbody></table> #</a>Pattern Matching</h2> Exhaustive pattern matching with linear type awareness:</p> `fn describe(opt: Option<Int>) -> String { </span> match opt { </span> Option#Some { value } => string_concat("Got ", int_to_string(value)), </span> Option#None {} => "Nothing" </span> } </span>} </span></code></pre> Linear types in patterns must be consumed:</p>` `fn handle!(result: Result<Data, File>) { </span> match result { </span> Result#Ok { value } => use_data(value), </span> Result#Err { error } => destroy(error) </span> } </span>} </span></code></pre> Borrowing in patterns:</p>` `fn peek(opt: &Option<Int>) -> Int { </span> match opt { </span> &Option#Some { value } => value, </span> &Option#None {} => 0 </span> } </span>} </span></code></pre>` #</a>Traits</h2> Traits provide bounded polymorphism with explicit static dispatch:</p> `trait Printable { </span> fn print(&self) with(Console) </span>} </span> </span>trait Describable { </span> fn describe(&self) -> String </span>} </span> </span>fn print_all<T: Printable>(list: &List<T>) with(Console) { </span> ... </span>} </span></code></pre>` #</a>Receiver Modes and Linear Types</h3> Trait methods take the receiver in one of three forms:</p> `&self</code> — borrows the value immutably</li>` `&mut self</code> — borrows the value mutably</li>` `self</code> — takes ownership, consuming the value</li> </ul> If a trait method takes self</code>, calling it consumes the value. This follows linear consumption rules:</p>` `trait Consume { </span> fn consume(self) </span>} </span> </span>fn use_once<T: Consume>(x: T) { </span> x.consume() // x is consumed here </span> // x.consume() // ERROR: x already consumed </span>} </span></code></pre> A trait implementation for a linear type must respect the receiver mode. An &self</code> method cannot consume the value. An &mut self</code> method cannot let the value escape. A self</code> method consumes it.</p>` #</a>Type Inference</h2> Type inference is local only</strong>. Function signatures must be fully annotated. Inside bodies, local types may be inferred:</p> fn process(data: List<Int>) with(Alloc) -> List<Int> { </span> let doubled = map(data, double) // return type inferred </span> let filtered = filter(doubled, is_positive) // return type inferred </span> filtered </span>} </span></code></pre> You can always understand a function’s interface without reading its body.</p> #</a>Modules</h2> pub fn open(path: String) with(File) -> Result<File, IOError> { </span> ... </span>} </span> </span>fn read(file: &File) with(File) -> String { </span> ... </span>} </span> </span>fn validate(path: String) -> Bool { </span> ... </span>} </span></code></pre> Visibility is pub</code> or private by default. Multi-file modules use mod name;</code> plus import name.{symbol}</code>.</p> #</a>Capabilities as Public Contract</h3> Capabilities are part of a function’s signature and therefore part of the public API contract. Changing the required capability set of a public function is a breaking change. This applies in both directions: adding a capability requirement breaks callers who don’t have it; removing one changes the function’s guarantees.</p> When reviewing dependency updates, diff the capability declarations. A library that adds with(Network)</code> to a function that previously had none is a significant change, even if the types remain identical.</p> mod filesystem; </span> </span>import filesystem.{open, read, write}; </span></code></pre> #</a>Unsafe, Trusted, and FFI</h2> Concrete splits low-level safety into four layers:</p> Capabilities</strong> declare semantic effects in public signatures (with(File)</code>, with(Alloc)</code>). They propagate through the call graph and are auditable with grep</code>.</li> trusted fn</code> / trusted impl</code></strong> mark code that uses raw pointers internally but exposes a safe API. Inside trusted code, raw pointer dereference, assignment, pointer arithmetic, and pointer casts are allowed without leaking Unsafe</code> to callers. The trust boundary is explicit in the source and tracked through the full IR pipeline and audit reports.</li> trusted extern fn</code></strong> marks narrow audited foreign bindings such as libc-style math wrappers. This is intentionally narrower than general FFI and shows up separately in reports.</li> with(Unsafe)</code></strong> gates foreign or semantically dangerous boundaries. Ordinary extern fn</code> calls still require with(Unsafe)</code>, even inside trusted code.</li> </ol> The Unsafe</code> capability gates operations the type system cannot currently verify: foreign function calls, raw pointer dereference (outside trusted code), raw pointer assignment (outside trusted code), and unsafe pointer casts (outside trusted code).</p> Unsafe</code> propagates through the call graph like any other capability. Grep for with(Unsafe)</code> to find all foreign boundaries. Grep for trusted</code> to find all internal trust boundaries.</p> #</a>Raw Pointers</h3> Raw pointers exist for FFI and low-level memory manipulation:</p> const T // immutable raw pointer </span>mut T // mutable raw pointer </span></code></pre> Raw pointers are Copy</code>. They carry no lifetime information and no linearity guarantees. This is safe because:</p> Creating a raw pointer from a reference is safe.</li> Holding a raw pointer is safe. It’s a number.</li> Using a raw pointer requires Unsafe</code>. Dereference, assignment, and unsafe casts are gated.</li> </ul> fn to_ptr<T>(r: &T) -> const T { </span> return r as const T; </span>} </span> </span>fn store<T>(ptr: mut T, value: T) with(Unsafe) { </span> ptr = value; </span>} </span></code></pre> The key boundary is deliberate:</p> Safe</strong>: reference-to-pointer casts like &x as const T</code> or &mut x as mut T</code></li> Unsafe</strong>: pointer dereference, pointer assignment, pointer-to-pointer casts, integer-to-pointer casts, pointer-to-integer casts, and other provenance-breaking operations</li> </ul> Copy</code> does not imply usable. Raw pointers can be freely duplicated because they carry no guarantees. Safety is enforced at the point of use, not at the point of creation.</p> #</a>Foreign Functions</h3> Declare foreign functions with extern fn</code>. Calling them normally requires Unsafe</code>:</p> extern fn malloc(size: Uint) -> mut Unit; </span>extern fn free(ptr: mut Unit); </span> </span>fn alloc_raw(size: Uint) with(Unsafe) -> mut Unit { </span> return malloc(size); </span>} </span></code></pre> The compiler generates calling convention glue and links the symbol. Foreign signatures are restricted to FFI-safe types. Today that means primitive scalars, raw pointers, unit, and #[repr(C)]</code> structs whose fields are themselves FFI-safe. A narrow audited subset can be declared as trusted extern fn</code> so callers do not need with(Unsafe)</code> for pure, well-understood foreign symbols. This is not a general safe-FFI escape hatch; it is a deliberately small carve-out.</p> #</a>Layout and #[repr(C)]</code></h3> Concrete now has an explicit FFI/layout surface:</p> #[repr(C)] </span>struct Header { </span> len: Uint, </span> kind: u32, </span>} </span></code></pre> The current rules are intentionally strict:</p> #[repr(C)]</code> structs cannot have generics</li> every field of a #[repr(C)]</code> struct must itself be FFI-safe</li> extern fn</code> parameters and returns must be FFI-safe</li> #[repr(packed)]</code> and #[repr(align(N))]</code> exist, but the broader ABI/layout model is still being tightened</li> </ul> This is one of the current implementation frontiers. The language now has a real low-level layout surface, but the long-term goal is to make the ABI model as explicit and mechanically trustworthy as the rest of the language.</p> #</a>Implementation</h2> #</a>Determinism</h3> Concrete aims for bit-for-bit reproducible builds</strong>: same source + same compiler = identical binary. No timestamps, random seeds, or environment-dependent data in output.</p> For debugging, deterministic replay</strong>: random generation requires Random</code> with explicit seed, system time requires Clock</code>. Same inputs produce identical execution.</p> #</a>The Grammar</h3> LL(1). Every parsing decision with a single token of lookahead. No ambiguity, no backtracking.</p> This is a permanent design constraint, not an implementation detail. Future language evolution is bounded by what LL(1) can express. We accept this constraint for tooling simplicity and error message quality.</p> #</a>Compilation Targets</h3> Native</strong> via direct LLVM IR emission today, with SSA as the backend boundary. MLIR and additional backends remain possible later, but the important architectural rule is that they should plug in after SSA rather than creating parallel semantic backend paths.</p> #</a>Tooling</h3> Today Concrete ships with the compiler, a built-in test runner (--test</code>), project metadata, examples, and more than 370 end-to-end tests. The compiler exposes audit-focused inspection modes (--report caps\|unsafe\|layout\|interface\|mono</code>) and internal stage outputs (--emit-core</code>, --emit-ssa</code>). The testing strategy has expanded well beyond smoke tests: fuzzing, property tests, trace tests, report-consistency tests, and selected codegen differential tests are now part of the project’s confidence story. A formatter, richer package workflow, linter, and REPL are better described as planned tooling than finished tooling. The standard library now covers more than 30 modules, so the next priority is less “add basics” and more “deepen, harden, and make the public surface cleaner while pushing formalization.”</p> #</a>Profiling and Tracing</h3> Profiling and tracing are first-class:</p> Built into the runtime, not bolted on</li> Low overhead when disabled</li> Structured output for tooling integration</li> </ul> Code is read more often than written, but executed more often than read. Performance visibility matters for systems programming.</p> #</a>What You Can Say About Programs</h2> If a program type-checks:</p> “This function is pure.”</strong> No capabilities declared. No side effects, no IO, no allocation.</p> “This resource is used exactly once.”</strong> Linear type. No leaks, no double-free, no use-after-free.</p> “These are the only effects this code can perform.”</strong> Capability set is explicit and complete.</p> “This code cannot escape the type system.”</strong> Unsafe operations require with(Unsafe)</code>.</p> “Allocation happens here, using this allocator.”</strong> Call site binds the allocator.</p> “Cleanup happens here.”</strong> defer destroy(x)</code> is visible.</p> “This build is reproducible.”</strong> Same inputs, same binary.</p> Mechanical guarantees from a type system proven sound in Lean. Not conventions, proofs.</p> #</a>Example</h2> import FileSystem.{open, read, write} </span>import Parse.{parse_csv} </span> </span>fn process_file(input_path: String, output_path: String) with(File, Alloc) -> Result<Unit, Error> { </span> let in_file = open(input_path)? </span> defer destroy(in_file) </span> </span> let content = read(&in_file) </span> let data = parse_csv(content)? </span> let output = transform(&data) </span> </span> let out_file = open(output_path)? </span> defer destroy(out_file) </span> </span> write(&mut out_file, output) </span> Ok(()) </span>} </span> </span>fn transform(data: &List<Row>) -> String { </span> ... </span>} </span> </span>fn main!() { </span> let arena = Arena.new() </span> defer arena.deinit() </span> </span> match process_file("input.csv", "output.txt") with(Alloc = arena) { </span> Ok(()) => println("Done"), </span> Err(e) => println("Error: " + e.message()) </span> } </span>} </span></code></pre> Everything is visible: resource acquisition, cleanup scheduling, error propagation, allocator binding.</p> #</a>Influences</h2> The kernel calculus is formalized in Lean 4. Coq could serve the same role; we chose Lean for its performance and active development.</p> Austral shaped the type system more than any other language. Linear types in Concrete are strict: every value must be consumed exactly once. The capability system for effect tracking also comes from Austral.</p> From the broader systems-language tradition come borrowing, traits, error handling, and pattern matching. Concrete uses lexical regions instead of lifetime annotations, which keeps the model smaller and more explicit.</p> Zig’s influence shows in explicit allocator passing and defer. Zig functions that allocate take an allocator parameter; Concrete expresses the same idea through with(Alloc)</code> and allocator binding at call sites.</p> Go had defer first. Go also shipped gofmt, which ended style debates by making one canonical format. We plan to ship a formatter.</p> The !</code> syntax for impure functions comes from Roc. fn main!()</code> marks impurity at a glance.</p> Koka, Eff, and Frank are the algebraic effects languages. Concrete’s capabilities are a simplified version of their effect systems. Capability polymorphism is now part of the language design and current implementation, though the overall effect system is still intentionally much smaller and more explicit than those languages.</p> Haskell proved that pure-by-default is practical. Clean had uniqueness types (precursor to linear types) and purity before Haskell did.</p> Cyclone pioneered region-based memory, the research line that led to Rust’s lifetimes and our lexical regions. ATS showed linear types and theorem proving can coexist. Ada/SPARK proved formal verification works in production: avionics, rail, security-critical systems.</p> CompCert and seL4 established that you can mechanically verify real systems software. A verified C compiler and a verified microkernel. That’s the standard we’re aiming for.</p> These ideas work. We’re combining them and proving the combination sound.</p> #</a>Who Should Use This</h2> Concrete trades convenience for explicitness, flexibility for auditability. Prototyping is slower. Some patterns become verbose. You’ll miss interior mutability for certain data structures.</p> But for cryptographic primitives, consensus protocols, financial transaction systems, medical device firmware, the trade is worth it. Strong claims about program behavior, mechanically verified.</p> A language you can trust the way you trust mathematics: not because someone promises it works, but because you can check the proof.</p> #</a>Quick Reference</h2> Annotation</th> Meaning</th></tr></thead> fn foo() -> T</code></td> Pure function, no capabilities</td></tr> fn foo!() -> T</code></td> Shorthand for with(Std)</code></td></tr> fn foo() with(C) -> T</code></td> Requires capability set C</code></td></tr> with(Alloc)</code></td> Function may allocate</td></tr> with(Alloc = a)</code></td> Bind allocator a</code> at call site</td></tr> T</code></td> Linear type, consumed exactly once</td></tr> struct Copy T</code></td> Unrestricted type, freely duplicated</td></tr> &T</code></td> Immutable reference</td></tr> &mut T</code></td> Mutable reference</td></tr> const T</code> / mut T</code></td> Raw pointer (unsafe to dereference)</td></tr> borrow x as y in R { }</code></td> Explicit borrow with named region</td></tr> defer expr</code></td> Run expr</code> at scope exit</td></tr> destroy(x)</code></td> Consume via destructor</td></tr> extern fn foo(...)</code></td> Foreign function binding</td></tr> </tbody></table> #</a>Appendix A: Standard Capabilities</h2> The Std</code> capability (accessed via !</code>) bundles these individual capabilities:</p> Capability</th> Gates</th></tr></thead> File</code></td> Open, read, write, close files. Directory operations.</td></tr> Network</code></td> Sockets, HTTP, DNS resolution.</td></tr> Alloc</code></td> Heap allocation. Requires allocator binding at call site.</td></tr> Clock</code></td> System time, monotonic time, sleep.</td></tr> Random</code></td> Random number generation. Requires explicit seed for reproducibility.</td></tr> Env</code></td> Environment variables, command line arguments.</td></tr> Process</code></td> Spawn processes, exit codes, signals.</td></tr> Console</code></td> Stdin, stdout, stderr.</td></tr> </tbody></table> Capabilities not in Std</code>:</p> Capability</th> Gates</th></tr></thead> Unsafe</code></td> Raw pointer operations, FFI calls, transmute, inline assembly. Never implicit.</td></tr> </tbody></table> A function with no capability annotation is pure. A function with !</code> has access to everything except Unsafe</code>. A function with explicit with(File, Alloc)</code> has exactly those capabilities.</p> Capabilities are not hierarchical. Std</code> is a shorthand for a set, not a super-capability. You cannot request “half of Std.”</p> #</a>Appendix B: Open Questions</h2> These are unresolved design decisions:</p> Concurrency</strong></p> No concurrency primitives exist. The language is currently single-threaded. Any future model must preserve:</p> Linearity (no data races from aliasing)</li> Determinism (reproducible execution)</li> Effect tracking (concurrency as capability)</li> </ul> Candidates: structured concurrency (like Trio/libdill), deterministic parallelism (like Haskell’s par</code>), actor model with linear message passing. Not decided.</p> Effect Handlers</strong></p> Capabilities track effects but don’t handle them. Full algebraic effects would allow:</p> fn with_mock_filesystem<T>(f: fn() with(File) -> T) -> T { </span> handle File in f() { </span> open(path) => resume(MockFile.new(path)) </span> read(file) => resume(mock_data) </span> } </span>} </span></code></pre> This enables testing, sandboxing, effect interception. Significant implementation complexity. Not committed.</p> Module System</strong></p> Current design is still intentionally minimal. Open questions:</p> Parameterized modules (functors)?</li> Module-level capability restrictions?</li> Separate compilation units built on file summaries?</li> How much semantic authority should remain file-local before Core IR?</li> </ul> FFI and ABI Model</strong></p> The implementation now has #[repr(C)]</code>, FFI-safe validation, and explicit unsafe gating, but the ABI model is not finished. Remaining questions:</p> Integer mappings (is Int</code> C’s int</code> or intptr_t</code>?)</li> Complete struct and enum layout guarantees</li> Calling conventions</li> Nullable pointer representation</li> String encoding at boundaries</li> </ul> Variance</strong></p> Generic types have variance implications. List<T></code> is covariant in T</code>. fn(T) -> U</code> is contravariant in T</code>. The spec doesn’t address this. For linear types, variance interacts with consumption. Needs formalization.</p> Macros</strong></p> No macro system. Options:</p> None (keep it simple)</li> Hygienic macros (Scheme-style)</li> Procedural macros (Rust-style)</li> Compile-time evaluation (Zig-style comptime)</li> </ul> Procedural macros would need capability restrictions. Not decided.</p> #</a>Appendix C: Glossary</h2> Affine type</strong>: A type whose values can be used at most once. Rust’s ownership model is affine: you can drop a value without consuming it.</p> Capability</strong>: A token that grants permission to perform an effect. Functions declare required capabilities; callers must have them. Capabilities propagate: if f</code> calls g</code>, and g</code> needs File</code>, then f</code> needs File</code>.</p> Consumption</strong>: Using a linear value in a way that fulfills its “exactly once” obligation. Methods of consumption: pass to a function taking ownership, return, destructure via pattern match, call destroy()</code>.</p> Copy type</strong>: A type exempt from linearity. Values can be duplicated freely. Must be explicitly marked. Cannot have destructors or linear fields.</p> Destruction</strong>: Consuming a linear value by invoking its destructor. destroy(x)</code> calls the type’s destructor and consumes x</code>.</p> Effect</strong>: An observable interaction with the world outside pure computation: IO, allocation, mutation, non-determinism. Concrete tracks effects through capabilities.</p> Elaboration</strong>: The compiler phase that transforms checked surface syntax into typed Core IR. In the current compiler, parsing, resolution, checking, elaboration, Core validation, monomorphization, lowering, SSA verification/cleanup, and code emission are separate passes.</p> Kernel</strong>: The core calculus formalized in Lean. A small language with mechanically verified properties. The surface language elaborates into it.</p> Lexical region</strong>: A scope that bounds reference lifetimes. References created in a region cannot escape it. Unlike Rust’s lifetime parameters, regions are always lexical and never appear in signatures.</p> Linear type</strong>: A type whose values must be used exactly once. Not zero (leak), not twice (double-use). Concrete’s default.</p> Purity</strong>: Absence of effects. A pure function computes a result from its inputs without IO, allocation, or mutation. In Concrete, functions without capability annotations are pure.</p> Raw pointer</strong>: A const T</code> or mut T</code> value. Carries no lifetime or linearity information. Safe to create and hold; unsafe to dereference.</p> Reference</strong>: A borrowed view of a value. &T</code> for immutable, &mut T</code> for mutable. The original value is inaccessible while borrowed.</p> Region</strong>: See lexical region.</p> Std</strong>: The standard capability set. Shorthand for File</code>, Network</code>, Alloc</code>, Clock</code>, Random</code>, Env</code>, Process</code>, Console</code>. Excludes Unsafe</code>.</p> Unsafe</strong>: The capability that permits operations the type system cannot verify: FFI, raw pointer dereference, transmute.</p> #</a>Appendix D: Comparison Table</h2> Feature</th> Concrete</th> Rust</th> Zig</th> Austral</th> Go</th></tr></thead> Memory safety</td> Linear types</td> Ownership + borrow checker</td> Runtime checks (optional)</td> Linear types</td> GC</td></tr> Linearity</td> Strict (exactly once)</td> Affine (at most once)</td> None</td> Strict</td> None</td></tr> GC</td> None</td> None</td> None</td> None</td> Yes</td></tr> Effect tracking</td> Capabilities</td> None</td> None</td> Capabilities</td> None</td></tr> Pure by default</td> Yes</td> No</td> No</td> Yes</td> No</td></tr> Explicit allocation</td> Capability + binding</td> Global allocator</td> Allocator parameter</td> No</td> GC</td></tr> Null</td> None (Option<T></code>)</td> None (Option<T></code>)</td> Optional (?T</code>)</td> None (Option[T]</code>)</td> Yes (nil</code>)</td></tr> Exceptions</td> None</td> Panic (discouraged)</td> None</td> None</td> Panic</td></tr> Error handling</td> Result</code> + ?</code></td> Result</code> + ?</code></td> Error unions</td> Result</code></td> Multiple returns</td></tr> Lifetime annotations</td> None (lexical regions)</td> Yes</td> None</td> None</td> N/A (GC)</td></tr> Formal verification</td> Kernel in Lean</td> External tools</td> None</td> None</td> None</td></tr> Defer</td> Yes</td> No (RAII)</td> Yes</td> No</td> Yes</td></tr> Interior mutability</td> None</td> Cell</code>, RefCell</code>, etc.</td> Pointers</td> None</td> Pointers</td></tr> Unsafe escape hatch</td> with(Unsafe)</code></td> unsafe</code> blocks</td> No safe/unsafe distinction</td> Unsafe_Module</code></td> No distinction</td></tr> Macros</td> None (undecided)</td> Procedural + declarative</td> Comptime</td> None</td> None</td></tr> Concurrency</td> None (undecided)</td> async</code>, threads, channels</td> Threads, async</td> None</td> Goroutines, channels</td></tr> Formatter</td> Planned</td> rustfmt (separate)</td> zig fmt</td> None</td> gofmt</td></tr> Grammar</td> LL(1)</td> Complex</td> Simple</td> Simple</td> LALR</td></tr> </tbody></table> #</a>Appendix E: Error Messages</h2> These are representative error messages. The actual compiler may differ.</p> Linearity violation: value not consumed</strong></p> error[E0201]: linear value `f` is never consumed </span> --> src/main.con:4:9 </span> \| </span> 4 \| let f = open("data.txt") </span> \| ^ this value has type `File` which is linear </span> \| </span> = help: linear values must be consumed exactly once </span> = help: add `defer destroy(f)` or pass `f` to a function that takes ownership </span></code></pre> Linearity violation: value consumed twice</strong></p> error[E0202]: value `f` consumed twice </span> --> src/main.con:7:12 </span> \| </span> 5 \| let content = read_all(f) </span> \| - first consumption here </span> 6 \| </span> 7 \| destroy(f) </span> \| ^ second consumption here </span> \| </span> = help: after passing `f` to `read_all`, you no longer own it </span></code></pre> Borrow escape</strong></p> error[E0301]: reference cannot escape its region </span> --> src/main.con:3:12 </span> \| </span> 2 \| borrow data as r in R { </span> \| --- region R starts here </span> 3 \| return r </span> \| ^ cannot return reference with region R </span> 4 \| } </span> \| - region R ends here </span> \| </span> = help: references are only valid within their borrow region </span></code></pre> Missing capability</strong></p> error[E0401]: function requires capability `Network` which is not available </span> --> src/main.con:8:5 </span> \| </span> 8 \| fetch(url) </span> \| ^^^^^^^^^^ requires `Network` </span> \| </span> = note: the current function has capabilities: {File, Alloc} </span> = help: add `Network` to the function's capability declaration: </span> \| </span> 2 \| fn process(url: String) with(File, Alloc, Network) -> Result<Data, Error> </span> \| +++++++++ </span></code></pre> Mutable borrow conflict</strong></p> error[E0302]: cannot borrow `data` as immutable because it is already borrowed as mutable </span> --> src/main.con:4:17 </span> \| </span> 3 \| borrow mut data as m in R { </span> \| - mutable borrow occurs here </span> 4 \| let len = length(&data) </span> \| ^^^^^ immutable borrow attempted here </span> \| </span> = help: mutable borrows are exclusive; no other borrows allowed </span></code></pre> Unsafe operation without capability</strong></p> error[E0501]: operation requires `Unsafe` capability </span> --> src/main.con:6:5 </span> \| </span> 6 \| ptr_read(addr) </span> \| ^^^^^^^^^^^^^^ unsafe operation </span> \| </span> = note: reading from raw pointers may cause undefined behavior </span> = help: add `Unsafe` to the function's capabilities: </span> \| </span> 2 \| fn dangerous(addr: const Int) with(Unsafe) -> Int </span> \| ++++++++++++ </span></code></pre> #</a>References</h2> #</a>Languages</h3> Lean 4</a> — theorem prover and programming language</li> Austral</a> — linear types and capabilities for systems programming Specification</a></li> </ul> </li> Rust</a> — ownership, borrowing, traits</li> Zig</a> — explicit allocators, defer, no hidden control flow</li> Roc</a> — pure functional, !</code> for effects</li> Koka</a> — algebraic effects and handlers</li> Eff</a> — algebraic effects research language</li> Frank</a> — effects as calling conventions</li> Clean</a> — uniqueness types, pure by default</li> ATS</a> — linear types with theorem proving</li> Cyclone</a> — region-based memory for C</li> Ada/SPARK</a> — formal verification in systems programming</li> </ul> #</a>Verified Systems</h3> CompCert</a> — verified C compiler</li> seL4</a> — verified microkernel</li> CertiKOS</a> — verified concurrent OS kernel</li> Iris</a> — higher-order concurrent separation logic</li> </ul> #</a>Papers</h3> Linear Logic</a> — Wadler’s papers on linear logic</li> Linearity and Uniqueness: An Entente Cordiale</a> — linear vs unique vs affine</li> Cyclone</a> — region-based memory safety for C</li> An Introduction to Algebraic Effects and Handlers</a> — Matija Pretnar</li> Capability Myths Demolished</a> — what capabilities actually provide</li> The Next 700 Programming Languages</a> — Landin’s classic</li> Hints on Programming Language Design</a> — Tony Hoare</li> Growing a Language</a> — Guy Steele</li> RustBelt: Securing the Foundations of the Rust Programming Language</a> — formal verification of Rust</li> Stacked Borrows: An Aliasing Model for Rust</a> — Ralf Jung on aliasing</li> Ownership is Theft: Experiences Building an Embedded OS in Rust</a> — Tock OS</li> A History of Haskell: Being Lazy with Class</a> — design decisions</li> Why Functional Programming Matters</a> — John Hughes</li> On the Criteria To Be Used in Decomposing Systems into Modules</a> — Parnas</li> Clean</a> — uniqueness types specification</li> Using Lightweight Formal Methods to Validate a Key-Value Storage Node</a> — practical verification at AWS</li> </ul> #</a>Blog Posts</h3> Language Design Philosophy</strong></p> Worse is Better</a> — Richard Gabriel on simplicity vs correctness</li> The Hundred-Year Language</a> — Paul Graham</li> Less is more: language features</a> — Mark Seemann on constraints</li> Out of the Tar Pit</a> — Moseley and Marks on complexity</li> Design Principles Behind Smalltalk</a> — Dan Ingalls</li> What to Know Before Debating Type Systems</a> — Chris Smith</li> Execution in the Kingdom of Nouns</a> — Steve Yegge</li> </ul> Austral and Linear Types</strong></p> Introducing Austral</a> — Fernando Borretti’s rationale</li> How Austral’s Linear Type Checker Works</a> — implementation decisions</li> How Capabilities Work in Austral</a> — how capabilities compose</li> Type Systems for Memory Safety</a> — survey of approaches</li> Linear types can change the world!</a> — Wadler</li> Retrofitting Linear Types</a> — adding linear types to Haskell</li> </ul> Rust Design Decisions</strong></p> The Problem with Single-threaded Shared Mutability</a> — why Rust forbids it</li> Rust: A unique perspective</a> — ownership from first principles</li> The Edition Guide: Non-Lexical Lifetimes</a> — why Rust moved beyond lexical scopes</li> Polonius: the future of the borrow checker</a> — Niko Matsakis</li> After NLL: Moving from borrowed data</a> — borrow checker limitations</li> Ralf Jung’s Blog</a> — Stacked Borrows, unsafe, formal semantics</li> Learn Rust With Entirely Too Many Linked Lists</a> — ownership through pain</li> The Rustonomicon</a> — dark arts of unsafe Rust</li> </ul> Graydon Hoare (Rust creator)</strong></p> The Rust I Wanted Had No Future</a> — original vision</li> Not Rust</a> — what Rust deliberately avoided</li> What next for compiled languages?</a> — language evolution</li> </ul> Zig Design Decisions</strong></p> Allocgate</a> — why Zig’s allocator design changed</li> What is Zig’s Comptime</a> — compile-time execution design</li> </ul> Effects and Capabilities</strong></p> Algebraic Effects for the Rest of Us</a> — Dan Abramov</li> What Color is Your Function?</a> — Bob Nystrom on effect tracking</li> Structured Concurrency</a> — Nathaniel Smith</li> Eff Programming Language</a> — algebraic effects research language</li> Koka: Programming with Row-polymorphic Effect Types</a> — official book</li> </ul> Roc and Purity</strong></p> Roc FAQ</a> — official FAQ and design rationale</li> Why Roc Uses Platform/App Split</a> — effect isolation design</li> </ul> Go Design Decisions</strong></p> Go at Google: Language Design in the Service of Software Engineering</a> — Rob Pike</li> Simplicity is Complicated</a> — Rob Pike</li> Errors are values</a> — Rob Pike</li> Go Proverbs</a> — design philosophy</li> Toward Go 2</a> — Russ Cox on language evolution</li> </ul> Memory and Allocators</strong></p> Untangling Lifetimes: The Arena Allocator</a> — Ryan Fleury</li> Always Bump Downwards</a> — Nick Fitzgerald</li> Memory Allocation Strategies</a> — Bill Hall’s series</li> </ul> Error Handling Design</strong></p> The Error Model</a> — Joe Duffy on Midori’s approach</li> Error Handling in a Correctness-Critical Rust Project</a> — sled database</li> </ul> Formal Methods in Practice</strong></p> Proofs About Programs</a> — Hillel Wayne</li> Formal Methods Only Solve Half My Problems</a> — Marc Brooker at AWS</li> How AWS Uses Formal Methods</a> — Amazon’s TLA+ experience</li> </ul> Lean 4</strong></p> Functional Programming in Lean</a> — official book</li> Theorem Proving in Lean 4</a> — official book</li> Metaprogramming in Lean 4</a> — macros and tactics</li> </ul> Type System Design</strong></p> Parse, Don’t Validate</a> — Alexis King</li> Names Are Not Type Safety</a> — Alexis King</li> Types as Axioms, or: Playing God with Static Types</a> — Alexis King</li> The Expression Problem</a> — Philip Wadler</li> </ul> Bob Harper</strong></p> Dynamic languages are static languages</a></li> Modules matter most</a></li> </ul> #</a>Talks</h3> Effects for Less</a> — Alexis King on effects (essential)</li> The Road to Zig 1.0</a> — Andrew Kelley</li> Is It Time to Rewrite the OS in Rust?</a> — Bryan Cantrill</li> Propositions as Types</a> — Philip Wadler</li> Correctness by Construction</a> — Derek Dreyer on RustBelt</li> Simple Made Easy</a> — Rich Hickey</li> Constraints Liberate, Liberties Constrain</a> — Runar Bjarnason</li> Growing a Language</a> — Guy Steele (watch this)</li> Why Algebraic Effects Matter</a> — Daan Leijen</li> Outperforming Imperative with Pure Functional Languages</a> — Richard Feldman</li> Why Roc?</a> — Richard Feldman</li> Preventing the Collapse of Civilization</a> — Jonathan Blow on why new languages matter</li> Ideas about a new programming language for games</a> — Jonathan Blow on Jai</li> Linear Types for Low-latency, High-throughput Systems</a> — Jean-Philippe Bernardy</li> seL4 and Formal Verification</a> — Gernot Heiser</li> </ul> #</a>Books</h3> Types and Programming Languages</a> — Pierce</li> Practical Foundations for Programming Languages</a> — Harper</li> Certified Programming with Dependent Types</a> — Chlipala</li> Software Foundations</a> — interactive Coq textbook</li> Programming Language Foundations in Agda</a> — Wadler and Kokke</li> The Little Typer</a> — Friedman and Christiansen</li> Crafting Interpreters</a> — Bob Nystrom</li> </ul> The Death of the Inner Self 2025-12-23T00:00:00+00:00 The core argument is simple: many features of human life that appear stable and natural are historically produced. As society accelerates, a number of these features begin to lose their function and their permanence. I believe consciousness as we know it is one of them.</p> #</a>Individuality as technology</h2> Life is organized around information that replicates under constraint. Computation generalizes this biological logic. It allows selection and optimization to occur faster and at larger scales by externalizing memory, comparison, and feedback. Problems that once required internal deliberation can be solved through external processes that test, filter, and iterate possibilities.</p> Capital pushes this logic further. It reorganizes social life around continuous feedback, price signals, and competitive selection. As these forces compound, individuality starts to look less like a foundation and more like an interface that emerged to solve earlier coordination problems.</p> Capital behaves as an impersonal intelligence oriented toward speed, abstraction, and self-optimization. As cognition, decision-making, and coordination migrate into automated systems, the inner self loses its structural role. Over time, many assumptions we take for granted are worn down by this acceleration. Individuality and consciousness appear increasingly exposed to this process.</p> #</a>The construction we cannot see</h2> Fish do not realize they live in water. The medium that sustains them is so constant that it disappears from perception. Some of the most important structures are overlooked for the same reason. Individuality and consciousness belong to that category.</p> We tend to treat individuality and consciousness as self-evident facts, as if humans have always experienced themselves as bounded selves with an inner voice, a private mental space, and a continuous narrative identity. Because this experience feels natural, it is assumed to be timeless. However, for most of human history people did not describe themselves as individuals in the modern sense. Decisions were not understood as outcomes of inner deliberation, and agency was not located inside a private interior self. Action was organized through rituals, traditions, kinship, and prescribed roles. Meaning arrived from outside the person rather than from introspection. In many societies outside the Western trajectory, this structure remains largely intact.</p> The idea of a you inside your head observing your own thoughts is therefore a learned construction. It depends on language, habits, metaphors, and social practices that had to be developed and stabilized over time. Inner speech, narrative memory, moral self-examination, and the sense of authorship over action emerged as cultural achievements layered on top of older biological processes.</p> Modern societies actively reproduce this configuration. From early childhood, people are trained to understand themselves as autonomous units with opinions, preferences, goals, and an inner life that belongs only to them. The training is so pervasive that it becomes invisible. Other ways of being human recede from view, even though many have existed and some still persist.</p> #</a>The weakening of the conditions</h2> The conditions that once made individuality functional are weakening. Earlier systems relied on human subjects to think, decide, judge, and take responsibility. Cognition and coordination were constrained by human minds. Individuality emerged as a solution: a stable self enabled long-term planning, moral accounting, and institutional continuity.</p> Earlier societies coordinated without modern consciousness. Contemporary systems increasingly coordinate without modern selves. Decision-making proceeds without inner deliberation. Meaning is delivered through incentives, metrics, and feedback loops.</p> At the cultural level, individuality remains constantly invoked. People are urged to be themselves, express themselves, optimize themselves. Yet the channels for expression arrive pre-shaped, quantified, and monetized. What appears as selfhood increasingly takes the form of managed performance within narrow bounds.</p> #</a>Replacement by degrees</h2> The modern self does not collapse in a single moment. It is replaced function by function, each substitution small enough to go unnoticed.</p> Taste was once formed through a slow, private process: encountering things by accident, sitting with discomfort, learning to love what initially resisted you. Algorithmic recommendation compresses this into a profile that updates in real time. The system knows what you will like before you do. The inner process of forming a preference, the hesitation, the revision, the gradual shaping of sensibility, loses its purpose when an external system performs it faster and with better accuracy. What remains looks like taste but functions as consumption.</p> Judgment follows a similar path. In organizations that once depended on accumulated experience, performance metrics now determine what counts as competent work. The slow formation of professional intuition, the kind that takes years to develop and resists easy articulation, gets flattened against quarterly targets. When the metric becomes the institution’s memory of what the work is for, the judgment it was meant to approximate quietly disappears. People still show up. They optimize what is measured. The rest erodes.</p> Inner deliberation faces the same pressure from a different direction. When an AI assistant can draft your emails, plan your week, summarize your reading, and suggest your next decision, the internal process of thinking through a problem starts to feel unnecessary. Not wrong, just slow. The assistant is not forcing you to stop thinking. It is making thinking feel like friction in a system that rewards speed. Over time, the habit of sustained internal reflection weakens for the same reason any unused capacity weakens: through disuse.</p> Each of these substitutions is individually reasonable. Each solves a real problem. Taken together, they describe a pattern where the functions that once required a self are gradually absorbed by systems that do not.</p> #</a>What is at stake</h2> The modern self once felt inevitable because it solved concrete problems. It enabled abstraction, continuity, and responsibility at scale. Its future usefulness is far less certain.</p> The self depends on performing certain functions, and when those functions migrate outward, the self weakens not through suppression but through redundancy.</p> The question is not whether individuality was real. It was. It produced philosophy, law, science, art, and institutions that reshaped the world. The question is whether it will remain functional as the systems around it absorb more of what it used to do. A coordination technology that no longer coordinates does not persist on sentimentality alone.</p> None of this means the self will vanish. It means the conditions under which it developed are changing, and what comes next may look different enough that the word “individuality” stops pointing at anything recognizable. Whether that transition is a loss, a transformation, or simply the next phase of the same process that produced the self in the first place is not something that can be settled in advance. But it should be named clearly, because what cannot be seen clearly cannot be preserved deliberately.</p> Notes on permanence, time, and ergodicity 2025-12-15T00:00:00+00:00 Ergodic Group</a> is built around a basic observation: some systems improve the longer you stay with them. Repetition sharpens execution, experience carries forward, and judgment builds on itself.</p> At Hermès, a leather worker trains for two years before touching a bag. One artisan makes one bag start to finish, every stitch by hand, fifteen to twenty-four hours of work per piece. This is the opposite of speed at all costs. It is also one of the most successful luxury companies in the world. The constraint is not overhead. It is what the customer is paying for.</p> The broader culture moves in the other direction. Cycles shorten. Signals multiply. Decision horizons shrink. A lot of institutions keep moving while quietly losing the judgment they once had. They stay busy, but they stop getting better. Copying outruns learning.</p> In that environment, endurance tells you something. If a system keeps working under stress for a long time, its structure probably matches reality better than its competitors’. The internet did not flatten everything. It made it easier to see who had substance and who was living off distribution.</p> #</a>Two forms of time</h2> Time operates in human systems in two fundamentally different ways.</p> Measured time is divisible and uniform: schedules, deadlines, accounting periods, discount rates. It can be allocated, optimized, and exchanged. Most planning systems live here. They assume value can be judged apart from history.</p> Lived time works differently. It accumulates. Learning, memory, and judgment develop through it, and each cycle changes the next one. Anything that depends on formation happens here. Snapshots miss the point because the value is in what compounds.</p> In 2001, Boeing moved its headquarters from Seattle to Chicago. The stated reason was to position the company closer to “Wall Street and governments.” Engineers who understood the planes were physically separated from executives who understood the spreadsheets. Over the next two decades, Boeing spent $41.5 billion on stock buybacks while cutting capital expenditure to half of Airbus’s rate. Harry Stonecipher, who took over as CEO, said he wanted Boeing “run like a business rather than a great engineering firm.” The 737 MAX, designed to avoid the cost of pilot retraining, killed 346 people. This is what happens when lived time is forced into measured time.</p> Berkshire Hathaway made the opposite bet. Buffett has refused quarterly earnings guidance since 1996. Shareholders are told to judge the business over decades, not quarters. The result is six decades of compounding judgment, the longest sustained record in American corporate history. Same markets, different use of time.</p> When lived time gets forced into measured time, formation breaks down. Standards do not settle. Judgment does not compound. You only find out what a system really is if you leave it alone long enough to show you.</p> #</a>Formation under constraint</h2> Excellence comes from sustained practice under the right constraints. Errors have to be survivable. People need room to adjust without every bad iteration becoming fatal. Judgment improves when experience carries over from one attempt to the next.</p> At Pixar, every film is terrible for years before it is good. Ed Catmull describes the process as taking movies “from suck to not-suck.” The mechanism is the Braintrust: a group of fellow directors and storytellers who meet every few months to review each film in production. The key detail is that the Braintrust has no authority. The director is not required to take a single suggestion. That keeps candor high without turning feedback into bureaucracy.</p> Most studios kill projects after one bad screening. Pixar treats bad screenings as information, not verdicts. The difference is not talent. It is structure. Formation takes time, and the Braintrust protects that time by separating honest feedback from the power to cancel.</p> #</a>Four domains</h2> Ergodic Group works across four domains: mathematics, code, culture, and craft. Most companies live mostly in one of them. The edge comes from connecting them.</p> Mathematics sets the structure and the constraints. Code turns that structure into action and tests it against reality. Culture lets intent survive changes in personnel. Craft brings the whole thing back to materials, tolerances, and physical consequences.</p> SpaceX shows how these domains work on each other. The math: a technique called lossless convexification lets an onboard computer solve fuel-optimal landing trajectories in real time, computing the exact moment to fire the engines so velocity hits zero at touchdown. The code: autonomous guidance software recomputes trajectories during descent, adjusting for wind and sensor readings, which makes landings on ocean platforms possible. The culture: failures are instrumented, not hidden. Between 2013 and 2016, SpaceX crashed booster after booster, and each crash produced telemetry that led to a specific fix. Hydraulic fluid ran out, so they added more. A throttle valve stuck, so they redesigned it. The craft: when carbon fiber layup produced wrinkles at roughly $200 per kilogram, SpaceX switched Starship to stainless steel at roughly $3 per kilogram. Steel gets stronger at cryogenic temperatures, handles far more heat, and opened reentry profiles that carbon fiber could not. A materials decision changed the vehicle, the software, and the math.</p> The point is not that these domains coexist. It is that learning compounds when they stay connected.</p> #</a>Ergodicity as a filter</h2> Ergodicity describes a situation where repetition improves the usual outcome because learning carries over from one round to the next.</p> Claude Shannon spent fifteen years at Bell Labs before publishing “A Mathematical Theory of Communication” in 1948. He was not being graded on quarterly output. Bell Labs gave researchers something modern organizations rarely give anyone: enough uninterrupted time to get to the bottom of a problem. That setup produced the transistor, information theory, Unix, the laser, and cellular telephony. The transistor did not come from a brainstorm. It came from people with different specialties working near each other for years.</p> When AT&T was broken up in 1984, that model disappeared with it. No later technology company has reproduced the same output. The institution itself held the judgment, and that judgment did not survive disassembly.</p> As acceleration intensifies, most sectors get noisier and more fragile. Coordination gets harder. Institutional memory thins out. Advantages that looked durable turn out to depend on a few people, a few habits, or a distribution edge that disappears. Infrastructure and culture last longer because they are not just products to be sold. They are environments people operate inside. When learning carries forward, time starts working in your favor.</p> #</a>Operation</h2> In 1984, GM and Toyota opened a joint factory in Fremont, California called NUMMI. Toyota sent over four hundred trainers from Japan for months of side-by-side work with American employees. Absenteeism dropped from twenty percent to two percent. Defect rates fell to the lowest in the United States.</p> GM tried to export the lessons. A vice president told employees to “take a picture of every square inch” of NUMMI and replicate it at other plants. It failed everywhere. The visible process looked the same. The results did not. The missing piece was judgment, and judgment does not travel well as a memo. Toyota had not built a checklist. It had built a way of working.</p> Ergodic Group is built on what NUMMI proved and what GM missed. The value is not in the visible process. It is in the judgment that accumulates when people have time to learn, when the links between domains stay intact, and when repetition actually improves the work.</p> The new financial backend of the world 2025-12-09T00:00:00+00:00 By Federico Carrone and Roberto Catalan</strong></p> Ethereum is emerging as a general purpose financial backend that reduces the cost and complexity of building financial services while improving their speed and security. For decades the internet accelerated communication but did not create a neutral system for defining ownership or enforcing obligations. Economic activity moved online without the accompanying machinery of rights, records, and jurisdiction. Ethereum fills this gap by embedding these functions in software and enforcing them through a distributed validator set.</p> Markets depend on property rights, and property rights depend on reliable systems for recording ownership, supporting transfer, and enforcing obligations. Prices then communicate scarcity and preference, enabling coordination at scale. Technological progress has repeatedly lowered the cost of transmitting information and synchronizing action. Ethereum extends this pattern by lowering the cost of establishing and verifying ownership across borders.</p> #</a>From internet native to global infrastructure</h2> Ethereum’s early innovation was the introduction of programmable digital assets with defined economic properties. Issuers could establish monetary rules, engineer scarcity, and integrate assets into applications. Before Ethereum, such experimentation required constructing a network and persuading others to secure it, a process limited to technically sophisticated groups. Ethereum replaced infrastructure duplication with shared security and a general purpose environment, turning issuance from a capital intensive undertaking into a software driven activity.</p> The more consequential development has been the recognition that Ethereum can reconstruct traditional financial services in a form that is more transparent and less operationally burdensome. Financial institutions devote substantial resources to authorization, accounting, monitoring, dispute resolution, and reporting. Consumer interfaces sit atop complex internal systems designed to prevent error and misconduct. Ethereum substitutes a portion of this apparatus with a shared ledger, a programmable execution environment, and cryptographic enforcement. Administrative complexity is reduced because core functions are delegated to software rather than replicated within each institution.</p> Ethereum reduces that burden by providing a shared ledger with real time updates, a programmable space for defining rules, and cryptographic enforcement. It does not remove institutions but changes which parts of the financial stack they must build themselves. Issuance becomes simpler, custody more secure, and administration less dependent on proprietary infrastructure.</p> #</a>Software, trust and the reduction of friction</h2> Some economists describe transaction costs through three frictions: triangulation, transfer and trust. Triangulation concerns how economic actors identify each other and agree on terms. Transfer concerns how value moves between them. Trust concerns the enforcement of obligations. Traditional financial architecture manages these frictions through scale, proprietary systems, and coordination among intermediaries.</p> Ethereum remove middlemen and therefore lowers the three frictions enumerated before. Open marketplaces support discovery of assets and prices. Digital value can settle globally within minutes without the layers of correspondent banking. Obligations can be executed automatically and verified publicly. These capabilities do not eliminate institutional functions but shift part of the work from organizations to software, reducing cost and operational risk.</p> New entrants benefit immediately. They can rely on infrastructure maintained by thousands of engineers rather than building their own systems for settlement, custody, and enforcement. Business logic becomes code. Obligations can be automated. Settlement becomes immediate. Users retain custody. This expands the range of viable business models and allows firms to serve markets that incumbents consider too small or too complex.</p> Having a single global ledger also changes operational dynamics. Many institutions operate multiple databases that require frequent reconciliation and remain vulnerable to error. Ethereum maintains a continuously updated and replicated record that cannot be amended retroactively. Redundancy and recoverability become default properties rather than costly internal functions.</p> Security follows the same pattern. Instead of defending a central database, Ethereum distributes verification among many independent actors. Altering history requires coordination at scale and becomes prohibitively expensive. Confidence arises from system design rather than institutional promises.</p> #</a>New financial services and global reach</h2> These features enable services that resemble established financial activities but operate with different cost structures. International transfers can use digital dollars rather than correspondent networks. Loans can enforce collateral rules in code. Local payment systems can interoperate without proprietary standards. Individuals in unstable economies can store value in digital instruments independent of local monetary fragility.</p> Clearing, custody, reconciliation, monitoring, and enforcement shift from organizational processes into shared software. Companies can focus on product design and distribution rather than maintaining complex internal infrastructure. Scale is achieved by acquiring users, because infrastructure is shared. Value accrues to applications rather than to duplicated internal systems.</p> The impact is most visible in markets with fragile financial systems. In economies with unstable currencies or slow payment networks, Ethereum provides immediate functional gains. In developed markets the benefits appear incremental but accumulate as more instruments and processes become programmable.</p> #</a>Institutional transformation and long term dynamics</h2> Many financial instruments are heterogeneous. Corporate debt is a clear example. Terms differ by maturity, coupon, covenants, collateral, and risk. Trading depends on bilateral negotiation and intermediaries who maintain records and enforce obligations. Ethereum can represent these instruments digitally, track ownership, and execute terms automatically. Contracts retain their specificity, while administration becomes standardized and interoperable.</p> The boundary between what firms must build and what software can enforce is moving. Regulation and legal systems remain central, but the institutions sitting on top of them look different when settlement, custody, and enforcement are handled by shared infrastructure instead of proprietary systems.</p> Ethereum already functions as an alternative financial rail. Multiple independently developed clients, substantial real world usage, an active research community, and a commitment to openness and verification set it apart from other blockchain networks.</p> #</a>Conclusion</h2> Ethereum converts core financial frictions into software functions, and that changes the economics of building and operating financial services. Institutions become lighter and more focused. Firms that adopt Ethereum early will operate at lower cost and gain a head start against competitors still running on legacy systems.</p> Technological transitions begin in niches where incumbents do not meet demand. As systems mature, costs fall and broader adoption becomes feasible. Ethereum followed this path. It began with internet native communities, expanded across emerging markets where users lacked reliable financial tools, and is now positioned to upgrade mainstream markets by making financial companies easier to create and operate.</p> Software is becoming the organizing principle of financial infrastructure. Ethereum makes that concrete. Regulation and institutional adaptation will shape how far it goes, but the economic incentives already point toward systems that are open, verifiable, and resilient.</p> The missing institution of the Internet 2025-12-02T00:00:00+00:00 By Federico Carrone and Roberto Catalan</strong></p> Modern economic systems rest on two foundations: tools that expand productive capacity and institutions that define who controls their output. The internet transformed how information moves, but it did not reconstruct the institutional machinery that governs ownership and exchange. Digital economic life therefore expanded without a durable system of rights, enforcement, or jurisdiction. Blockchain networks, and Ethereum in particular, address this gap by embedding institutional functions in software and enforcing them through economic incentives and cryptographic verification.</p> #</a>Technology, Culture and Institutional Design</h2> Humans build two kinds of things: tools that expand what individuals can do, and institutions that coordinate what groups can do together. Fire, agriculture, medicine and computing are tools. Property rights, contracts, markets and corporate structures are institutions. The two feed each other. Tools expand capacity, institutions channel it into collective action, and the combination compounds over time.</p> #</a>Property Rights and Markets as Social Technologies</h2> People invest when they believe they will keep what they earn. Property rights give that assurance by specifying who owns what, who can use it, and who is excluded. Markets sit on top of these rights and coordinate production through prices. None of this is natural. It is all engineered through law and political settlement.</p> Prices, money and contracts compress information about scarcity and risk so that strangers can trade without needing to trust each other or answer to a central planner. The global expansion of trade in the twentieth century ran on this machinery: neutral jurisdictions, corporate structures, and legal containers that let participants from different regulatory environments collaborate. Whatever you think of it, this infrastructure underwrote the international economic order of the late twentieth century.</p> #</a>The Missing Architecture of Digital Ownership</h2> The internet lowered the cost of communication and commerce across borders, but it did not establish a neutral mechanism for defining and enforcing claims on digital assets. Offline, ownership is adjudicated by courts, enforced by states and geographically bounded. Online, in the absence of a global authority, ownership defaults to either national legal systems or to the platforms that mediate activity.</p> Corporations filled this vacuum by providing infrastructure for identity, communication and exchange. They set terms of access, mediate transactions and retain discretionary control over assets generated within their systems. Users and firms may create content, build businesses and accumulate value, but their rights are contingent on the policies of the platform operator.</p> The experience of Zynga illustrates this dynamic. The company developed a profitable games business on Facebook and briefly achieved a valuation exceeding that of Electronic Arts. Its fortunes deteriorated when Facebook revised its policies and altered its revenue share. Zynga owned its intellectual property and its infrastructure but not the environment on which its business model depended, a common position for firms built on platform economies. In digital markets, platforms function as de facto landlords.</p> This is not an isolated case but a structural feature of platform centered economies: extensive participation paired with limited control.</p> #</a>Ethereum as an Institutional Experiment</h2> Ethereum is a response to this institutional absence. It provides a mechanism for creating, transferring and enforcing digital assets without reliance on corporate or national intermediaries. The system operates as a verifiable computing environment in which rules are encoded in software and enforced collectively by a distributed network.</p> Traditional computing systems require users to trust the operator. Ethereum distributes computation across thousands of machines that execute identical code and verify each other in a continuous process. Outputs are accepted when consensus is reached and misbehavior is economically penalized. Under these conditions, property rights and contractual commitments can be represented as digital objects whose enforcement does not depend on courts or discretionary authority.</p> This architecture automates functions normally performed by institutions. Auditors repeat financial records to detect manipulation. Courts resolve disputes. Regulators impose compliance standards. These systems are essential but costly and slow. Ethereum replicates aspects of verification and enforcement at the system level using software, mathematics and economic incentives.</p> The network is open to participation without authorization and resistant to censorship because no single entity can unilaterally block or rewrite transactions. These properties arise from the structure of the system rather than ideological intent.</p> #</a>The Emergence of a Digital Financial System</h2> The first adopters of Ethereum were technologists experimenting with new mechanisms for ownership and coordination. Most of the culture and products were created for themselves. Over time, a broader range of actors began using the system for financial services.</p> The most consequential development has been the rise of stablecoins, digital representations of fiat currency backed by real world assets. Their combined market capitalization exceeds three hundred billion dollars, with a majority circulating on Ethereum. Transaction volumes on blockchain networks now approach those processed by major payment systems.</p> Stablecoins replicate core financial functions such as store of value and transfer of funds without geographic restrictions and with continuous settlement. Their programmability enabled the construction of lending protocols that allow users to lend and borrow assets with risk parameters enforced in software rather than through institutional mediation.</p> These systems differ from traditional financial infrastructure. Participation is global rather than jurisdictional. Switching costs are low because services are built on interoperable standards. Exit is immediate. Risk is transparent though often misunderstood.</p> Compare that to countries like Argentina, where interoperability between banks and fintech wallets, something as trivial as scanning a QR code, is still an ongoing regulatory battle. Incumbents try to use their market position to avoid being interoperable. On Ethereum, interoperability is structural. Individuals can receive payment, convert assets, provide liquidity and borrow collateralized funds within minutes from a mobile device. In legacy systems, similar transactions take days and incur high fees. Adoption reflects demand for neutral infrastructure in environments where intermediation is unreliable.</p> #</a>Implications</h2> Several areas of financial activity are migrating to blockchain based systems, including remittances, trade finance and private credit. Others, such as corporate debt markets, remain fragmented and costly but exhibit characteristics that may make them suitable for digital reconstruction on top of Ethereum.</p> Plenty can still go wrong. Regulatory uncertainty, operational risk and rough user experience all constrain adoption. Scaling throughput without giving up decentralization remains an open engineering problem. Software vulnerabilities and governance failures have already caused real losses and will cause more.</p> Early evidence suggests that parts of financial intermediation can run at lower cost and with more transparency than existing systems. Whether that continues depends as much on how regulators and incumbents respond as on the technology itself.</p> #</a>Artificial Intelligence and Coordination</h2> Artificial intelligence increases productive capacity by automating tasks but does not resolve questions of ownership, governance or compliance. Output may be generated more efficiently, but disputes over entitlement, liability and compensation persist.</p> Artificial intelligence and blockchains, but in particular Ethereum, are the two biggest innovations in the decades to come. The two technologies solve concrete core primitives of humans: productivity gains and coordination. Artificial intelligence will make people more productive, but it will not eliminate the bureaucratic machinery required to verify and enforce outcomes. Ethereum introduces a technology that complements AI: a system where humans and autonomous agents can coordinate, trade, and settle disputes directly through code, without relying on institutions to prove that everyone followed the rules.</p> #</a>Conclusion</h2> The internet lowered the cost of transmitting information but left digital ownership in the hands of whoever runs the platform. Ethereum reconstructs elements of property rights and contractual enforcement as public infrastructure encoded in software.</p> It may end up as core infrastructure or it may remain a specialized tool. That depends on regulators, incumbents, and whether the engineering problems get solved. But it has already shown that financial coordination can run at a different cost structure, and that digital property can exist without a central administrator.</p> The internet built an economy without institutions. Ethereum is an attempt to build them.</p> Next 10 Years of Ethereum 2025-11-15T00:00:00+00:00 Ethereum's Native Rollup Roadmap with Justin Drake 2025-10-01T00:00:00+00:00 Crypto doctrine 2025-09-25T00:00:00+00:00 #</a>Crypto and the accelerated and chaotic 21st Century</h1> Crypto has been most useful where trust is weakest. In practice, it has found product-market fit in two places:</p> In countries where inflation, capital controls, or censorship are ordinary constraints, crypto gives people and companies tools they actually need.</li> In internet-native communities, crypto provides a financial layer that lets people coordinate, speculate, and build markets at a scale the web did not support before.</li> </ul> People that don’t live in a developing country or that didn’t grow up with the internet have enormous difficulties understanding crypto because they don’t have skin in its game. They believe crypto doesn’t have any “real” use case or that is not serious enough. They are right. The thing is that we are living in a world that’s becoming more absurd.</p> Memes do not only make you laugh anymore, memes are now winning elections.</p> These use cases will grow with time and probably new ones will be found. The world is becoming more chaotic and more divided each day. Crypto benefits from that kind of environment because it reduces the number of places where trust has to be taken on faith.</p> One of crypto’s prime advantages is that it kills many of the middlemen and allows us to coordinate even in the harshest environments. Trust assumptions fall because more of the system is enforced by incentives, compilers, distributed systems, and cryptography. That does not remove politics or disagreement. It just narrows the set of things people need to argue about.</p> Most of us are internet natives. We grew up on IRC, 4chan, Reddit, Hacker News, Twitter, Bitcoin, and Ethereum, and we also have roots in unstable countries. We are the Fremen of crypto, raised in a harsh environment. We know what chaotic societies feel like from the inside, and we know what it takes to build inside them. At the same time, we are builders who like working at the frontier of engineering and scientific change.</p> Open source and decentralization are not just philosophical preferences for crypto. They are practical conditions for the ecosystem to work. Building in the open, helping other people onboard, and creating systems larger than the original project are part of how crypto survives long term. This can look irrational if you assume the only goal is short-term extraction. It is more legible if you assume the goal is to help a new financial and coordination layer persist.</p> Our main objective is to help these new internet highways get built in sustainable ways. Economic sustainability matters, but so do resilience, openness, and the ability to resist the usual drift toward centralization. Centralization is almost always easier in the short run. If pure money were the only objective, there would be simpler ways to make it. We treat money as a tool, not the final point.</p> With or without money, you will find us building.</p> “Top-down management leveraging command-and-control hierarchies are for the mahogany boardrooms of yesteryear. We are navigators, adventurers, and explorers of the future. We are married to the sea” - Yearn’s Blue Pill</p> Zero-Knowledge Proofs and the Economics of Verification 2023-04-13T00:00:00+00:00 Scientific and engineering fields usually move in long stretches of incremental work. Then, every so often, a new tool or idea changes the constraints and the whole field jumps. Most of the time progress comes from thousands of small improvements made by researchers, engineers, and companies. But occasionally something arrives that changes what is practical, not just what is theoretically possible.</p> The public usually notices breakthroughs in areas like aerospace, energy, or AI. Cryptography moves more quietly, even when the consequences are just as large. During the COVID years, the field made real progress, especially in zero-knowledge proofs and other primitives that make verification cheaper and privacy easier to preserve. The bet in this piece is that these advances will matter well beyond cryptography itself.</p> One of the most important changes has been practical speed. Zero-knowledge proofs have existed since the 1980s, but for a long time they lived mostly in papers because the proving costs were too high for ordinary systems. Over the last decade, and especially in the last few years, that changed. Engineers pushed them much closer to real-world use.</p> The financial system still depends on intermediaries: auditors, regulators, accountants, banks, and payment networks. That system works when the institutions inside it are trusted and the surrounding state has enough legitimacy to enforce the rules. Bitcoin introduced a different model: a permissionless monetary network where users can move value without asking an intermediary for access. In places where inflation, capital controls, or institutional weakness are part of daily life, that difference is not theoretical. It is immediate.</p> As trust becomes more uneven, systems that can be independently verified become more attractive. That does not mean social trust disappears. It means more parts of the stack will be built so they rely on less of it.</p> Bitcoin was designed primarily as a monetary asset and settlement network, so expressive computation on top of it has always been limited by design. Ethereum expanded that design space by allowing more complex programs, which is why lending, exchanges, and other financial applications grew there first. But blockchains still impose severe constraints. Computation is expensive, throughput is limited, and the cost of moving meaningful value is often too high.</p> This is where zero-knowledge proofs and related distributed-systems primitives become useful. A zero-knowledge proof lets one party show that a computation was done correctly without revealing the underlying data and without forcing everyone else to rerun the computation. The crucial asymmetry is that proving is expensive, but verification is much cheaper. That is what makes the technique economically meaningful rather than just mathematically elegant.</p> At the beginning it’s difficult to grasp, even for engineers, that this technology is possible. The mathematics behind it, until recently, seemed magical, and that’s why it was called moon math. Thanks to ZKPs, transferring money in systems similar to Bitcoin becomes cheaper and much faster because there is no need for every node to re-execute each transaction. In some architectures, one node can process all the transactions and prove them using ZKPs, while the rest simply verify them, saving valuable computing resources. Among other things, ZKPs enable creating a financial system that doesn’t depend on social trust like traditional finance and that doesn’t depend as much on re-executing algorithms as Bitcoin.</p> Zero Knowledge Proofs facilitate the development of an entirely new range of applications that are executed and proven on a single computer outside the blockchain, with verification happening within Ethereum. The cost of verification is much lower than the cost of proving or executing the computation. Ethereum will evolve from a slow yet secure distributed mainframe, where execution time is shared among all users to run small programs, into a distributed computer that stores and verifies proofs generated externally from the blockchain.</p> Blockchains are not the only systems that benefit from these primitives. As AI-generated content begins to overshadow human-generated content on the internet, ZKPs become useful for verifying that content came from a specific model, system, or approved pipeline. “Proof of humanity” systems are already using ZKPs to verify that a human is accessing specific resources.</p> More broadly, some industries will face growing pressure to prove they are operating correctly rather than asking users to trust them. Online gaming, ad networks, and other opaque intermediaries are obvious candidates. Fully Homomorphic Encryption, a related primitive that enables computation on encrypted data without exposing it, will play a similar role wherever privacy constraints are binding.</p> In the past decade, we have launched applications serving tens of millions of users. We are now focused on helping others build startups around these technologies where the technical advantage is real and the use case is concrete.</p>

Fede's Guide to a Healthier Life

2026-03-13T00:00:00+00:00

When I was young I loved science and engineering. Like most nerds, I thought thinking was the only thing that mattered. Working out seemed like a vanity project, something for people who cared about how they looked and not much else. I didn’t understand the body-mind connection at all. I was a skinny kid who spent all day reading, tinkering with computers, and hanging out with friends. The idea that physical health could affect how well I think would have sounded like nonsense to me.

It took me a long time to figure out how wrong I was.

Can I prove Concrete programs in Lean?

2026-03-12T00:00:00+00:00

I have been thinking about what it would take to prove Concrete</a> programs in Lean. Not the compiler itself, but actual user programs: take a function written in Concrete, connect it to its Core IR representation inside the compiler, and prove properties about it using Lean’s existing theorem library.

The AI Training Data Trap for Programming Languages Has an Exit

2026-03-11T00:00:00+00:00

Edgar Luque recently wrote about how AI creates a new adoption barrier for programming languages</a>. His claim is that AI coding assistants need training data, training data only exists for popular languages, and so new languages get bad AI support, which prevents adoption, which in turn prevents training data from accumulating. A self-reinforcing loop that locks in whatever is already dominant.

If you are building a new general-purpose language that competes with Python, Go, or Rust on roughly the same terms, Luque’s analysis is devastating. What makes it worse than previous adoption barriers is that you cannot community-effort your way out of it. The AI training pipelines belong to a handful of companies, and those companies will always prioritize the languages where the most data already exists.

But there is a blind spot in the argument.

The Rust Effects Debate and Concrete's Case for a Smaller Language

2026-03-09T00:00:00+00:00

Yoshua Wuyts recently wrote about his “grand vision” for Rust</a>, outlining three directions he thinks the language should pursue: effects, stronger substructural types, and refinement types. The Hacker News thread</a> that followed split predictably: one camp saw a safer, more principled systems language taking shape while the other saw echoes of Scala, C++, and a language that becomes harder to read than the software it is meant to clarify.

Both camps are seeing something real, and I think resolving the tension between them requires something other than adding more features to Rust. That is where Concrete</a> comes in.

Dissolution Without Construction

2026-03-06T00:00:00+00:00

I have been circling the same problem for a while now. Friction produces value. Legibility destroys what it measures. Formation requires lived time. The modern self is dissolving through redundancy. Previous technological shifts gave people decades to adapt, and this one might give them months.

These kept feeling like separate observations. I no longer think they are.

#</a>The Speed Mismatch</h2>
Every major coordination technology in history has dissolved the form of selfhood that preceded it. Writing destroyed oral memory. The printing press destroyed manuscript culture. Institutions dissolved kinship. None of this is new.
What is new is the asymmetry between how fast things dissolve and how fast things grow.
Writing spread slowly. A scribe copied a text, carried it to another city, taught someone to read it. The dissolution of oral memory and the construction of literate thought happened at roughly the same pace, both measured in generations. The printing press was faster, but still slow enough that cultural forms could emerge alongside the destruction. The novel, the diary, the public library, liberal education: these took centuries to stabilize, but centuries were available because print moved at the speed of physical objects.
Algorithmic systems dissolve at computational speed. A recommendation engine can reshape the taste-formation process of millions of people in months. An AI assistant can make inner deliberation feel unnecessary within a single product cycle.
But construction, the formation of new human capacities, new cultural forms, new modes of perception, still happens at biological speed. A person becomes a particular kind of person through years of encounter, revision, failure. A cultural form stabilizes through generations of practice. There is no computational shortcut because the capacity is constituted by the process, not by its output. You cannot compress becoming.
The gap between dissolution speed and construction speed is the problem. Not dissolution itself.
This reframes a conversation that has been stuck for years. One side says previous transitions worked out, so this one will too. They are wrong for a structural reason: previous transitions worked out because dissolution was slow enough for construction to keep pace. That condition no longer holds. The other side says technology is destroying us. They are also wrong, or at least imprecise. Dissolution is not destruction. Every previous transition dissolved something real and produced something new. The issue is not that dissolution is happening. The issue is that it is happening at a speed that makes construction impossible.
#</a>Friction as Governor</h2>
Desire depends on resistance. The deeper point is that resistance imposes a pace. The distance between wanting and obtaining is a temporal structure. It gives the person time to become someone who can integrate what they receive. Remove the distance and the person receives before they can absorb.
Friction performs this function at civilizational scale. When the printing press dissolved oral culture, books were expensive. Literacy spread gradually. The oral self did not vanish overnight. It weakened over decades and centuries, and during that time the constructive side, new practices of reading, new institutions, new literary forms, had room to develop. The friction inherent in physical media imposed a speed limit on dissolution, and that speed limit happened to match the speed of human formation.
Friction in taste formation gives a person time to develop the capacity to perceive, not just a set of preferences. Friction in professional training gives the practitioner time to develop judgment that resists articulation. Friction in deliberation gives the self time to form. Remove it and dissolution outruns construction. The gap opens. Nothing grows where the old capacity was.
#</a>Legibility as Accelerant</h2>
The German forest again. Eighteenth-century foresters replaced diverse, messy woodland with uniform Norway spruce plantations. Yields surged. Then the undergrowth died, the soil degraded, and the forest collapsed. What looked like inefficiency was the system’s life support.
Legibility does something specific to the speed problem. It converts illegible processes into optimizable targets. Once a process is visible, it can be measured. Once measured, optimized. Once optimized, the friction in the original process gets removed as inefficiency. Legibility is the mechanism that identifies friction, and optimization is the mechanism that strips it out. Together they accelerate dissolution.
The self depended on opacity. Taste formed in private. You encountered things by accident, sat with discomfort no algorithm could detect, revised your sensibility through a process invisible to any external system. Professional judgment lived in knowledge that could not be articulated. Inner deliberation happened in a space that was, by definition, not observable from outside.
AI reaches into all of this. It makes taste formation legible through behavioral data. It makes deliberation legible through interaction logs. It makes professional intuition legible through performance metrics. Each act of legibility strips away a layer of friction that was functioning, without anyone noticing, as a speed governor on dissolution.
#</a>The Compounding Problem</h2>
This is the part that worries me most. Dissolution does not just outrun construction. It degrades the conditions under which construction is possible.
Formation requires complete cycles: effort, feedback, adjustment, repeated across lived time. Acceleration fragments these cycles. What spreads fastest diverges from what works best. Imitation spreads faster than learning. Every act of dissolution removes some of the friction, opacity, and time that construction requires. The more functions the self loses, the less capacity remains to develop new ones. The process compounds. Dissolution accelerates while the ground for construction erodes.
Someone who has never formed taste through friction is not going to develop whatever post-algorithmic perception might look like. Someone who has never exercised inner deliberation will not develop whatever comes after deliberation. The new capacity, if it exists, will not emerge from a vacuum. It will emerge from people who have developed enough of the old capacity to transcend it, the way literate thought emerged from people who had first mastered oral memory. If dissolution destroys the old capacity before the new one can develop from it, the sequence breaks.
That is not a transition. It is an interruption.
#</a>What Would Have to Be True</h2>
I do not know what comes after the literate self. Nobody in 1450 could have described what the printing press would produce either. But I can describe the conditions under which construction becomes possible.
It would require friction. Not arbitrary difficulty, but the specific resistance that imposes a pace compatible with human formation. It would require opacity. Domains where the slow work of becoming is not legible to optimization systems, where a person can develop without being measured. And it would require time. Actual time. Complete cycles of effort and revision that are not compressed or interrupted.
The current system removes all three. Optimization treats friction as waste. AI treats opacity as a problem to solve. Markets treat slowness as a competitive disadvantage. The incentives point uniformly toward faster dissolution.
Previous transitions produced their own constructive forms because the speed of dissolution left room for them. Print was slow enough that the novel could emerge. Institutional life was gradual enough that liberal education could develop. The printing press did not spontaneously generate the literate self. People built schools, designed curricula, established practices of reading and argument that took centuries to stabilize. That work was deliberate, institutional, and slow, but it was possible because the dissolution it responded to was also slow.
The question I cannot answer is whether anything can grow at biological speed in an environment that has been optimized for computational speed. Whether construction is possible when the conditions for construction are precisely what the system is most efficient at removing.
There is an irony I should not avoid. I build coordination infrastructure for a living. Ethereum clients, cryptographic proof libraries, distributed systems. Tools that accelerate exactly the process this essay describes. And the essay itself is not construction. It is diagnosis. I am genuinely confused by my own position. I see the dissolution clearly enough to write about it. I also build the tools that produce it. I have not resolved this. I am not sure it can be resolved. Naming the speed mismatch does not slow it down. It may even accelerate it by making the problem legible, which is what I argued legibility does: convert things into objects of optimization. I do not know whether writing about dissolution is a form of friction, something that slows the reader down, forces them to sit with discomfort, or a frictionless take on friction, consumed and forgotten at algorithmic speed. I suspect the answer depends on what you do after reading it.

Legibility Kills What It Measures

2026-03-03T00:00:00+00:00

In the 18th century, German foresters invented scientific forestry. They looked at a messy, diverse forest and saw inefficiency. Old trees, young trees, deadwood, underbrush, species with no commercial value. They cleared it all and planted Norway spruce in straight rows, evenly spaced, same age, same species. The forest became legible. You could measure it, manage it, predict its yield with precision.

For one generation, it worked brilliantly. Yields surged. Then the forest began to die. The complex undergrowth had been cycling nutrients, retaining moisture, hosting the insects that pollinated the canopy and the fungi that fed the roots. The foresters had not simplified the forest. They had destroyed the system that kept the forest alive while keeping only the part they could see.

James Scott tells this story in Seeing Like a State to illustrate a pattern that recurs wherever central authorities impose legibility on complex systems. The pattern is simple: make the illegible legible, optimize what you can now see, and lose what you couldn’t see but depended on.

At the Core of Finance Lies Geometry. In the End, It’s All Jensen’s Inequality.

2026-03-01T00:00:00+00:00

Never cross a river that is on average four feet deep. If the river is eight feet deep in the middle and dry on the sides, the average tells you nothing about whether you will drown. You will drown in the middle, or you won’t. There is no averaging across parallel universes where you both survive and die.
The same asymmetry shows up wherever outcomes compound. Lose 50% of your wealth and you need a 100% gain just to break even, because the loss hits a larger base than the recovery builds from. Going from $100 to $200 and from $200 to $400 are different dollar amounts but the same proportional move: one doubling. Wealth is about ratios and scaling, not absolute differences.
This multiplicative structure has consequences that run deeper than intuition suggests. The mathematics that governs survival in compounding environments was invented 400 years ago to help astronomers multiply large numbers, partially rediscovered in the 18th century to solve a paradox about gambling, formalized again through information theory, and then largely obscured by theories that optimized across hypothetical worlds instead of along a single path through time.
That is the geometric claim in this essay: wealth evolves multiplicatively, while most ordinary intuition is additive. The logarithm is the change of coordinates that lets us move between those two descriptions.
This is the story of why geometry sits at the core of finance, why a single inequality ties the whole picture together, and why reducing variance can be more valuable than increasing returns.

The Tail Hedge Debate: Spitznagel Is Right, AQR Is Answering the Wrong Question

2026-02-26T00:00:00+00:00

Stock markets crash. The S&P 500 price index fell about 57% from October 9, 2007 to March 9, 2009, and about 34% from February 19, 2020 to March 23, 2020.1</a>2</a> A put option is a contract that pays you when the market falls below a certain price (the “strike”). If you hold stocks and also hold puts, the puts can offset some of your losses during a crash. The question is whether the cost of buying puts is worth the protection they provide.
There are two sides. AQR Capital Management published “Chasing Your Own Tail (Risk)”</a> (Nielsen, Villalon, and Berger, 2011</a>). They argue that buying puts systematically costs more than it saves. On the other side, Mark Spitznagel at Universa Investments, where Nassim Taleb is scientific advisor, argues that a small put allocation improves long-term returns (Spitznagel, 2021</a>). Universa reported a 3,612% gain in March 2020 (via an investor letter, as reported by Bloomberg).3</a>
We tested both claims with our open-source options backtester</a> on 17 years of real SPY options data (2008 to 2025), covering three crashes: the 2008 financial crisis, COVID, and the 2022 bear market.
Spitznagel is right about the strategy he actually proposes. AQR’s published critique uses near-ATM puts and a no-leverage framing, neither of which matches the portfolio Spitznagel and Universa describe. When we test deep OTM puts, even the no-leverage framing beats SPY. Spitznagel’s externally funded overlay still wins by a wider margin.

Detecting Crashes with Fat-Tail Statistics

2026-02-19T00:00:00+00:00

Financial markets don’t follow normal distributions. That is a claim about frequency, not just theory: it tells you how often catastrophic events happen. Under a naive Gaussian model, a crisis on the scale of 2008 lands so deep in the tails that standard risk models treat it as effectively impossible. It happened on a Tuesday.
The problem is that we keep using tools designed for thin-tailed worlds. Value at Risk (VaR) models that assume normality. Risk metrics that treat the 2008 crash as an “outlier” rather than a regular feature of financial returns.
I built fatcrash</a>, a Rust+Python toolkit with 15 classical methods, to test whether fat-tail statistical methods can detect crashes before they happen. The performance-critical math (fitting, simulation, all rolling estimators) runs in Rust via PyO3; everything else (data, viz, CLI) is Python.

Twenty Centuries of Financial Data: What 240 Countries and 2,000 Years Reveal

2026-02-12T00:00:00+00:00

In 1252, Florence minted the gold florin. Within decades it became the dominant trade currency of medieval Europe. Merchants in Bruges, Venice, and Constantinople quoted prices against it. By the 1400s, the florin’s dominance had faded, replaced by the Venetian ducat. Then the Spanish real. Then the Dutch guilder. Then sterling. Then the dollar. Each transition involved devaluations, defaults, and crises that ruined anyone holding the wrong currency at the wrong time.
We have data on all of this. Not estimates. Actual recorded exchange rates, starting from 1106. And not just exchange rates: gold and silver prices from 1257, interest rates from 1311, commodity prices from 1260, GDP per capita from the year 1 CE, sovereign debt ratios from 1800, and crisis indices covering two centuries of banking panics, currency collapses, and sovereign defaults.
I assembled forex-centuries</a>, the most comprehensive open-source collection of long-run financial and economic data available. 27 sources, 1,100+ files, ~240 countries, spanning twenty centuries. Exchange rates, precious metals, interest rates, commodity prices, inflation, GDP, real wages, sovereign debt, regime classifications, and real effective exchange rates — all in one repository with an automated build pipeline, weekly CI updates, and reproducible analysis. No other free repository combines this breadth of asset classes across this depth of history. The only comparable product is Global Financial Data</a> (commercial, institutional pricing). The goal: provide the raw material for studying how currencies and financial systems behave over centuries, not decades.

Friction as Luxury: What We Lose When AI Gives Us What We Want

2026-02-05T00:00:00+00:00

#</a>The Last Scarcity</h2>
Most discussions of AGI focus on distribution: who gets access, who profits, who loses their job, who controls the infrastructure. Those are real problems, but they’re not the deepest one.
The deeper problem is what happens to desire. I do not mean ambition in the generic sense. I mean the capacity to want something at a distance, to stay oriented toward something you do not yet have, and to find meaning in the space between reaching and arriving. That capacity is more fragile than we usually admit, and it depends more on friction than most people notice.
#</a>I.</h2>
Economists have a clean model of desire. People have preferences, goods satisfy preferences, welfare rises as more preferences are satisfied. In that framework, a technology that can satisfy almost any preference at negligible cost looks like an obvious good. The only remaining question is who gets access.
That model leaves out something important. Desire is not just a lack waiting to be filled. It has a shape, and that shape depends on certain conditions holding.
When you want something over time, you imagine having it. You plan for it, you make sacrifices toward it. The object accumulates meaning from this process. It gets layered with your effort, your anticipation, your history of reaching. When you finally arrive, you don’t just get the object. You get the object plus everything you invested in wanting it. Those two things can’t be separated.
That is why anticipation is often richer than arrival, why the best albums sometimes need months rather than minutes, and why relationships built through difficulty have a texture that convenient ones often do not. The resistance is not incidental to the value. It helps produce it.
#</a>II.</h2>
When this structure breaks down, the clinical term is anhedonia. But there is a milder and more socially acceptable version of the same pattern. People in this condition can be entertained constantly but rarely feel deeply absorbed. They consume without much appetite. They move from one stimulating thing to the next not because anything is satisfying, but because sitting with incompleteness starts to feel unbearable.
You can already see the shape of it in declining attention spans, in the difficulty of sustaining interest in anything that doesn’t deliver immediate feedback, in people who feel simultaneously overstimulated and bored. They haven’t been deprived, they’ve been saturated.
This doesn’t distribute evenly in society. In environments where discomfort is quickly solved, by money, by services, by endless entertainment, the mind gets less practice holding lack. You can grow up surrounded by abundance and still become poor in one specific way: poor in patience for distance.
Structurally, it starts to resemble addiction: craving breaks away from fulfillment. Many substances do not mainly deliver pleasure. They intensify wanting. They train the nervous system to treat discomfort as a cue for relief, and relief as a cue for repetition. A frictionless AI environment could reproduce some of that pattern without chemicals. Boredom, loneliness, uncertainty, and effort all become prompts for instant stimulation. Over time the threshold rises, what once felt absorbing becomes merely adequate, and the rest of life starts to feel slow and underpowered by comparison.
Consumer capitalism produced a weakened version of this. Desire progressively hollowed out by eliminating friction, but with enough friction remaining that the structure didn’t fully collapse. The streaming service still requires you to choose. The algorithm still occasionally surprises you. The simulation of connection is imperfect enough that you sometimes notice it’s a simulation.
#</a>III.</h2>
Imagine a system that can generate, on demand, a novel calibrated to your tastes: the style you find most pleasurable, the level of complexity you find most engaging, the length that matches your current patience. Or music that sounds like what you loved most at nineteen, except new, immediate, and endless. Or a conversation partner who is always interested in what interests you, always available, never distracted, never carrying needs of their own into the exchange.
The output might be genuinely good. The novel could be technically accomplished. The music could actually move you. The conversation could be substantive. The problem is what happens to wanting once the gap collapses to zero.
The capacity to stay oriented toward a distant goal, to defer, to invest, to tolerate incompleteness, atrophies when it is never exercised. Not through some dramatic break. Through disuse. The ability to want things that require time does not vanish all at once. It gets weaker, and the weakening may not even feel like a loss because something pleasant keeps arriving on schedule.
#</a>IV.</h2>
None of this is new. The Stoics understood that wanting easily obtained things produces a character incapable of bearing difficulty. Religious traditions have long held that the meaningful life runs through resistance rather than around it.
What’s new is the scale. Previous technologies eliminated specific friction but left other friction intact. The printing press made books abundant but reading still required effort. The internet made information free but you still had to sift through it, evaluate it, decide what mattered. Every digital environment until now required you to bring something it couldn’t supply: attention, skill, patience.
A genuinely general AI dissolves this last requirement. It can supply the taste, the context, the judgment. You no longer need to bring anything except the desire to receive. And if that desire is itself shaped by the AI, tuned to whatever maintains engagement, then even the wanting has been outsourced.
#</a>V.</h2>
Here is the inversion. In a world of material abundance, the things that keep their value are often the ones that resist the logic of abundance. Their value is tied to the conditions that make them difficult, not to artificial scarcity.
A handmade object carries the trace of the hands that made it. A wine vintage can’t be accelerated. The waiting isn’t incidental to what the wine is. A community built around a shared difficult practice, painting, rock climbing, chess, building and fielding armies of miniatures, generates bonds that digitally mediated interaction doesn’t replicate, because those bonds are forged in shared difficulty.
These things do not become valuable despite being harder than consuming AI output. They become valuable partly because of that hardness. In a world of frictionless satisfaction, friction becomes a luxury.
#</a>VI.</h2>
The safety, alignment, and job-displacement debates are all real. But they share a common assumption: that the humans on the other side will still be capable of deciding what to do with what they’ve been given, and that political agency and collective imagination will survive intact.
That assumption is doing a lot of work.
The atrophying of desire is not some distant hypothetical. You can already see smaller versions of it in what weaker technologies have done to culture. What AGI does to human psychology is not separate from what it does to human politics. It comes first. A population that has lost the capacity to want things at a distance, to stay oriented toward a difficult future, and to find meaning in effort and incompleteness has lost something essential to self-government.
The scarcity that matters most in a post AGI world won’t be compute or energy. It will be the capacity to want something deeply enough, and for long enough, that the wanting shapes who you are.
If desire is the last scarcity, then slowness, difficulty, and incompleteness aren’t obstacles to overcome. They’re the conditions of a life worth living.

China is trying to commoditize the complement

2026-01-22T00:00:00+00:00

China is trying to win by commoditizing the complement and I believe they are close to succeeding. This is a strategic challenge the West should take seriously instead of dismissing.
For the last two decades, the West exported cognition because it owned the platforms, the cloud, the software distribution, and the talent concentration. If the cognitive engine becomes cheap, portable, and good enough, that asymmetry weakens. A small country can buy or download the same cognitive machinery, then apply it to its own bureaucracy, its own companies, its own language, its own domain problems.
The West has dominated the thinking and services world. Software, finance, media, research, management layers, and the export of expertise. The US is the clearest example. In 2024, US services exports were about 1.1 trillion dollars, the highest on record. The US and the West sell thinking at scale. AI threatens to flatten that advantage because AI turns thinking into infrastructure.
China dominates the atoms world. Industrial capacity, manufacturing throughput, physical supply chains, cost curves. In 2023 China produced about 28 percent of global manufacturing value added.
If you can make the layer next to you cheap and abundant, you drain its pricing power and force value to move somewhere else. In AI, the complement is model access. For a lot of Western companies, the business is still basically gated intelligence sold as an API. China has every incentive to make that layer feel like electricity: available everywhere, cheap, hard to monopolize.
Open weight releases are part of that play: DeepSeek, Qwen, Kimi, and MiniMax are only a few of the Chinese open-source models. Once strong models are common, model access stops being a moat. It becomes a commodity input.
A huge fraction of what we call services is legible work: reading, writing, coding, summarizing, translating, drafting, answering, generating variations, searching a space of options. That layer is now replicable and it is getting local. Apple is publishing technical reports about on-device foundation models, including aggressive quantization aimed at making serious inference run on consumer hardware. When strong models run on a laptop, countries stop importing thinking as a service. They import weights, or they distill, fine-tune, and deploy inside their own borders.
That said, China is not without constraints, and from where I sit they matter.
Capital controls limit how freely Chinese companies can operate globally. The state can redirect investment at a scale nobody else can match, but centralized allocation tends to overshoot. Solar panel overcapacity, steel oversupply, and the EV price war all follow the same pattern: massive subsidized buildout that ends up compressing margins for everyone, including the Chinese firms themselves.
Top talent still flows toward open research environments. Many of the best Chinese researchers publish in Western conferences and a significant number stay abroad. The tightening of political control over universities and private companies can accelerate execution on defined goals, but it makes it harder to sustain the open-ended, high-risk research that produces unexpected breakthroughs rather than incremental gains.
Predictability matters for long-term innovation. Foreign companies are recalibrating their exposure. Some domestic entrepreneurs are more cautious than they were a decade ago. Centralized coordination gives speed, but it can also reduce the appetite for bets that do not align with current priorities.
The West still has one advantage that is hard to replicate: it is where most of the world’s ambitious talent wants to live, work, and build. It is a compound effect of open institutions, freedom of movement, and decades of accumulated trust. As long as that holds, the West keeps attracting the talent and the capital that turn ideas into new industries.
None of these constraints cancel out the commodity play. But they mean the race is closer than either side assumes, and the outcome is far from settled.
China stays strong in atoms because it already has the scale advantage. The West still leads in areas that require deep institutions and long accumulated competence, frontier research and high trust services in particular. But AI compresses the services premium by making a large portion of cognition cheap and replicable. That is why open models matter. They attack the margin structure of the thinking economy.
If you sell intelligence, this is bad news. If you own distribution, hardware, data, or a workflow people cannot easily leave, you survive. If you own atoms and you get thinking for free, you get a scary combination, because the services premium that sustained Western economic leadership for decades can be undercut by a player with industrial dominance and access to the same cognitive tools.

Building a SaaS with Elixir/Phoenix and React

2026-01-15T00:00:00+00:00

Most SaaS codebases I’ve seen share the same problems. Authentication that sort of works until someone finds an edge case. Caching layers that nobody fully understands. Deployment scripts held together with hope. The team moves fast early on, then spends years paying down the debt.
We got tired of this cycle. Over several projects, we developed a stack and a set of practices that let us move fast without leaving landmines for our future selves. Elixir on the backend, React on the frontend, Nix for everything else. No Docker. No Kubernetes. Decisions that raised eyebrows at first but have proven themselves in production.
This post explains what we use and why.
#</a>The case for Elixir</h2>
Our backend runs on Elixir, which might seem like an unusual choice in a world dominated by Node, Python, and Go. The reason comes down to what happens when things go wrong.
Elixir runs on the Erlang VM, a runtime Ericsson built in the 1980s for telephone switches. These systems needed to stay up for years at a time, handling failures gracefully without human intervention. Crashes are expected in Elixir, even encouraged as an error-handling strategy. When a process crashes, it crashes in isolation. A supervisor notices and restarts it. The rest of the system keeps running. You don’t get woken up at 3am because one user’s request hit an edge case that brought down the whole server.
Phoenix is the web framework we use on top of Elixir, though we use it differently than most teams. Phoenix has become famous for LiveView, its technology for building interactive UIs with server-rendered HTML. We don’t use it. Instead, Phoenix serves only JSON through a REST API, and a completely separate React application handles everything the user sees.
This creates a hard boundary between backend and frontend. Backend developers focus entirely on data and business logic without thinking about UI concerns. Frontend developers own the user experience end-to-end without needing to understand Elixir. The two teams communicate through the API contract, and neither steps on the other’s work. When we eventually build mobile apps, they’ll consume the same API with no new backend work required.
#</a>Why we abandoned Docker for Nix</h2>
This is probably our most controversial choice. Docker has become the default for development environments and deployment. We use Nix instead.
When a new developer joins our team, the onboarding process is simple: clone the repository and run nix develop</code>. A few minutes later, they have everything they need. Elixir, Node.js, PostgreSQL, Redis, Meilisearch, all running natively on their machine. Not in containers. Actually installed. Without container overhead, everything runs at native speed. Debugging is straightforward because there’s no abstraction layer between you and the process. And there are no Docker Desktop licensing conversations.
But the real payoff comes in production, where our servers run NixOS. The entire server configuration is declarative and lives in version control alongside our code. When we push a change, every server ends up in exactly the same state. Deployments are atomic. They succeed completely or fail completely, with no partial states to debug. If something goes wrong, rolling back takes one command.
Nix has a steep learning curve. The documentation is notoriously difficult, and the language has unusual semantics. But once you’ve internalized the concepts, you get guarantees Docker can’t provide. A build that works today will produce the exact same result in five years, because every input is pinned and reproducible.
#</a>Building for offline use</h2> Most web applications assume users have constant connectivity. Ours doesn’t, and this assumption has shaped our entire frontend architecture. The frontend stores data locally using Dexie.js, a library that wraps IndexedDB with a friendlier API. When a user makes changes, those changes save to the local database first. A sync queue tracks what needs to go to the server, and when the network becomes available, the queue drains automatically. A salesperson updates CRM records on a flight with no WiFi. A technician fills out inspection forms in a basement with no signal. Someone’s home internet drops for thirty seconds while they’re submitting an important form. In all these scenarios, our app keeps working. Users might not even notice the interruption. The UI responds immediately to their actions, and synchronization happens in the background. We use TanStack Query for data fetching, but with caching completely disabled. Every API call fetches fresh data from the server. IndexedDB is our cache, and we control exactly when and how it syncs. No more stale data bugs because some cache somewhere wasn’t invalidated properly. #</a>Database decisions</h2> PostgreSQL. UUIDs as primary keys instead of auto-incrementing integers. This makes enumeration attacks much harder, because an attacker can’t simply guess that /users/124</code> follows /users/123</code>, though it does not replace proper authorization checks. UUIDs also let us generate identifiers on the client before the record exists in the database. For multi-tenancy, we use application-enforced tenant isolation. Every table that holds customer data includes an org_id</code> column, and every query filters by it. If you want the database to enforce that boundary too, PostgreSQL row-level security is the next step. The alternative is giving each tenant their own database schema. That provides stronger isolation, but migrations have to run once per tenant, connection pools multiply, and cross-tenant queries for admin purposes become complicated. The org_id</code> approach is simpler and scales well for most SaaS applications, as long as you’re disciplined about enforcing it everywhere. We also have a strict rule: no random data in tests. We don’t use Faker. Every test uses explicit, predictable inputs. When a test fails, it fails the same way every time you run it. You can debug it, reproduce it, and fix it. Random test data causes tests that fail one time in twenty for reasons nobody can reproduce. #</a>Authentication</h2> Most tutorials get authentication wrong in ways that create real security vulnerabilities. We use JWT tokens with a two-token system. The access token is short-lived, expiring after 15 minutes. It’s stateless, so the backend validates it without touching the database. The refresh token lasts 7 days and is stored in the database. When the access token expires, the frontend uses the refresh token to get a new one. Because refresh tokens live in the database, we can revoke them instantly. When a user clicks “log out of all devices,” it actually works. We delete their refresh tokens, and within 15 minutes every session everywhere is invalidated. Both tokens live in httpOnly cookies rather than localStorage. JavaScript cannot read httpOnly cookies, which means an XSS vulnerability cannot simply exfiltrate the tokens the way it can from localStorage. But cookies change the threat model rather than eliminating it: you still need SameSite</code> settings and CSRF protection or strict origin checks on sensitive endpoints. Most tutorials store JWTs in localStorage because it’s simpler, but it leaves users vulnerable to script injection. Password hashing uses Argon2, OWASP’s current recommendation over bcrypt. #</a>Libraries</h2> For JWT handling, we use Joken instead of Guardian. Guardian is popular but tries to do too much. It has opinions about plugs, permissions, token types. We found ourselves fighting these abstractions. Joken just encodes and decodes tokens. We handle the rest. Oban handles background jobs. Unlike Sidekiq or Celery, Oban uses PostgreSQL as its backend instead of Redis. One less service to run. Job state is transactional with your application data. You can insert a database record and enqueue a job in the same transaction, with the guarantee that either both happen or neither does. On the frontend: Zustand for client state, TanStack Query for API calls, React Hook Form with Zod for forms. For components, shadcn/ui built on Radix primitives. Radix handles accessibility correctly, which is hard to do from scratch. #</a>Deployment</h2> We deploy to bare metal servers running NixOS. No Docker in production. No Kubernetes. Kubernetes solves problems of scale that most SaaS applications don’t have. For a typical SaaS with a handful of services, it adds operational complexity without proportional benefits. You end up managing Kubernetes instead of building your product. Our setup is simple. systemd supervises the Phoenix processes. Caddy handles TLS and reverse proxying, automatically getting certificates from Let’s Encrypt. When we deploy, we push the new NixOS configuration to our servers using deploy-rs. The switch is atomic. If something goes wrong, we roll back in seconds. Secrets are encrypted in the git repository using agenix. Each server has its own age encryption key, and secrets are decrypted at deployment time on the target machine. #</a>Observability</h2> We set up logging, metrics, and error tracking before writing the first feature. Every team says they will add observability later. They never do. Logs are structured JSON. Every entry includes a request ID, user ID, and organization ID. These logs ship to Grafana Loki through Promtail. The request ID is generated when a request enters our system and propagates through everything: API calls, background jobs, external service calls. When a user reports a problem and we have their request ID, we can trace exactly what happened across the entire system. Metrics go to Prometheus, errors to Sentry. Dashboards and alerts exist before the first feature because retrofitting them later never happens. #</a>Build order</h2> First comes the foundation: Nix configuration, Makefile, project structure, database setup. It feels like yak shaving until the first time it saves you. Second, we build admin tools. A dashboard for internal use. User impersonation, which lets us log in as any user to see what they see. Seed data that creates realistic test scenarios. You need to demo to stakeholders before the product is done. You need to debug issues by experiencing the product as users do. Third is authentication, because almost everything else depends on knowing who the user is. Then the actual product features. Polish like error handling, loading states, and accessibility comes last but isn’t optional. #</a>The full guide</h2> The complete guide is at github.com/unbalancedparentheses/saas_guidelines</a>. Database connection pooling, rate limiting, circuit breakers, health checks, graceful shutdown, disaster recovery, and more.
Unprepared for What's Coming 2026-01-08T00:00:00+00:00 Humanity is completely unprepared for what’s coming. I’ve been talking with partners, employees, and countless people over the last few weeks. I’m amazed by most people’s inability to adapt or even grasp second order effects of what’s coming. They don’t even want to think about the consequences. Some of the smartest people I’ve met in my life are trying to avoid accepting the reality: it’s very likely we will have tools that are able to do almost everything better than a human in a very short timeline. It’s very likely that even those of us who can generally adapt quickly won’t be able to overcome this tsunami. We will experience one of the biggest deflationary shocks in history. Only robotics combined with AI could be bigger than this. I find it almost absurd to watch so many YouTube channels and X accounts showing you how to create your own simple app or SaaS. If anybody can build things fast, what do you think will happen? Is there demand for thousands of applications of every kind? During the last 20 years some of the smartest people alive battled for attention of people by building software and the limitation was execution costs, speed and distribution. Right, but I’m forgetting that people say it’s not the time of implementation anymore. In theory, we’re now in the time of ideas. So what happens when someone has a good idea and anyone can copy it in days? If implementation becomes worthless, what remains? Perhaps taste, distribution, or maybe in some cases deep domain expertise. But even those moats are eroding fast. What makes this different from past disruptions is the pace. Previous technological shifts gave people decades to adapt. This one might give them months. We built this. And yet it feels like it’s happening to us, not by us. The strange position of being both the creator and the displaced. This is going to be very sad and fun at the same time. Happy to be alive during this time. Type Systems: From Generics to Dependent Types 2026-01-01T00:00:00+00:00 Every type error you’ve ever cursed at was a bug caught before production. Type systems reject nonsense at compile time so you don’t discover it at 3 AM. But they vary wildly in what they can express and what guarantees they provide. The Concrete Programming Language: Systems Programming for Formal Reasoning 2025-12-26T00:00:00+00:00 There’s a tension at the heart of systems programming. We want languages expressive enough to build complex systems, yet simple enough to reason about with confidence. We want performance without sacrificing safety. We want the freedom to write low-level code and the guarantees that come from formal verification. Concrete is an attempt to resolve these tensions through commitment to a single organizing principle: every design choice must answer the question, can a machine reason about this? #</a>On This Specification</h2> This document describes what we’re building, not what we’ve finished building. The kernel formalization in Lean is ongoing work. Until that formalization is complete, this specification likely contains mistakes, ambiguities, and internal contradictions. We state this not as an apology but as a feature of our approach. Most language specifications accumulate contradictions silently over years, edge cases where the spec says one thing and the implementation does another, or where two parts of the spec conflict in ways nobody noticed. These contradictions become load-bearing bugs that can never be fixed without breaking existing code. By designing Concrete around a formally verified kernel from the start, we force these contradictions into the open. When we formalize a feature in Lean, the proof assistant will reject inconsistencies. Features that seem reasonable on paper will turn out to be unsound, and we’ll have to redesign them. This is the point. We’d rather discover that our linearity rules have a hole before a million lines of code depend on the broken behavior. The specification and the formalization will co-evolve. As we prove properties in Lean, we’ll update this document. As we write this document, we’ll discover what needs proving. The goal is convergence: eventually, this specification will be a human-readable projection of a machine-checked artifact. #</a>Current Implementation Status</h3> The compiler is now a full Lean 4 implementation with more than 370 passing end-to-end tests plus a separate SSA-specific suite. Today Concrete has: a staged Lean 4 compiler pipeline: Parse, Resolve, Check, Elab, CoreCanonicalize, CoreCheck, Mono, Lower, SSAVerify, SSACleanup, EmitSSA, clang</li> strict LL(1) parser cleanup landed in the implementation, not just as a design goal</li> explicit cacheable artifact types at each pipeline boundary (Pipeline.lean</code>), with composable runner functions and a shared frontend helper</li> a summary-based frontend where FileSummary</code> and ResolvedImports</code> form the cross-file boundary, with prebuilt function, extern, and impl-method signatures reused across Resolve, Check, and Elab</li> structured diagnostics across all semantic passes with native Except Diagnostics</code> transport, range-capable spans, hint text, and coarse-grained multi-error accumulation</li> SSA optimizations and backend cleanup: constant folding, dead code elimination, CFG cleanup, trivial phi/copy cleanup, and recent lowering fixes around scope handling and string deduplication</li> a four-part low-level trust model: capabilities (semantic effects in public signatures), trusted fn</code>/trusted impl</code> (internal pointer-level unsafety behind a safe API), trusted extern fn</code> (narrow audited foreign bindings), and with(Unsafe)</code> (foreign or semantically dangerous boundaries)</li> capability polymorphism</li> newtype</code> with zero-cost nominal wrappers</li> #[repr(C)]</code>, #[repr(packed)]</code>, #[repr(align(N))]</code>, sizeof::<T>()</code>, and alignof::<T>()</code></li> audit-focused compiler outputs: --report caps|unsafe|layout|interface|mono</code>, with dedicated consistency tests for those reports</li> a built-in test runner (--test</code>) with #[test]</code> tracked through the full IR pipeline</li> a much larger stdlib surface than the earlier drafts: more than 30 modules spanning foundational containers/views, systems modules, formatting/parsing, hashing, randomness, time, and testing</li> HashMap<K, V></code> and HashSet<K></code> with explicit fn-pointer hash/eq rather than hidden trait-object or representation-based dispatch</li> an ongoing builtin-vs-stdlib cleanup: compiler magic is being deliberately shrunk so more of the user-facing surface lives in ordinary stdlib code and traits</li> </ul> What it does not yet have is the final thing that makes the long-term vision unique: a fully formalized kernel connected end to end to the implemented compiler</li> verified elaboration/code generation</li> a mature tooling stack (formatter, package manager, linter)</li> </ul> #</a>Stability Promise</h3> The kernel is versioned separately from the surface language. Once the kernel reaches 1.0, it is frozen. New surface features must elaborate to existing kernel constructs. If a feature can’t be expressed in the kernel, the feature doesn’t ship. #</a>The Core Idea</h2> Most languages treat verification as something bolted on after the fact. You write code, then maybe you write tests, maybe you run a linter, maybe you bring in a theorem prover for critical sections. The language itself remains agnostic about provability. Concrete inverts this relationship. The language is designed around a verified core, a small kernel calculus formalized in Lean 4 with mechanically-checked proofs of progress, preservation, linearity soundness, and effect soundness. The surface language exists only to elaborate into this kernel. #</a>What “Correct” Means</h3> When we say a type-checked program is “correct by construction,” we mean correct with respect to specific properties: Memory safety: no use-after-free, no double-free, no dangling references</li> Resource safety: linear values consumed exactly once, no leaks</li> Effect correctness: declared capabilities match actual effects</li> </ul> We do not guarantee termination. Recursive functions may diverge. We do not guarantee liveness or deadlock freedom. These properties are outside the current verification scope. The kernel proves progress (well-typed programs don’t get stuck) and preservation (types are maintained during evaluation), which together yield memory and resource safety, not total correctness. #</a>The Trust Boundary</h3> The kernel type system and its properties are mechanically checked in Lean. The current compiler is also implemented in Lean 4 end to end. What remains trusted is the Lean proof checker, the Lean compiler implementation that elaborates surface programs and emits code, and the backend toolchain that turns generated LLVM IR into machine code. Verifying the elaborator and code generator is still future work. #</a>Design Principles</h2> From this kernel-centric design, six principles follow: Pure by default — Functions without capability annotations are pure: no side effects, no allocation</li> Explicit capabilities — All effects tracked in function signatures</li> Linear by default — Values consumed exactly once unless marked Copy</code></li> No hidden control flow — All function calls, cleanup, and allocation visible in source</li> Fits in your head — Small enough for one person to fully understand</li> LL(1) grammar — Parseable with single token lookahead, no ambiguity</li> </ol> #</a>The Compilation Pipeline</h2> The compiler is a single Lean 4 codebase end to end. The pipeline looks like this: Source Code (.con) ↓ Parse ↓ Resolve ↓ Check ↓ Elab ↓ CoreCanonicalize ↓ CoreCheck ↓ Mono ↓ Lower ↓ SSAVerify ↓ SSACleanup ↓ EmitSSA (LLVM IR text) ↓ clang / system linker ↓ Native Machine Code </code></pre> Each pass has a narrow job: Parse builds the surface AST with spans using an LL(1) parser.</li> Resolve validates imports, top-level names, type names, enum variants, and other declaration-level references.</li> Check enforces type consistency, linearity, borrowing, capabilities, and FFI-safety boundaries.</li> Elab lowers the surface language into typed Core IR.</li> CoreCheck re-validates the important semantic invariants over the explicit Core representation.</li> Mono specializes generic code into concrete instances.</li> Lower turns Core into explicit SSA blocks and control flow.</li> SSAVerify checks dominance, phi correctness, and structural SSA invariants.</li> SSACleanup performs local simplifications and cleanup before code emission.</li> EmitSSA turns verified SSA into LLVM IR text.</li> </ul> This architecture matters because it keeps the compiler understandable. The old “parse, check, directly emit LLVM” shape is gone. Concrete now has a real semantic boundary at Core IR and a real backend boundary at SSA. The long-term design still includes a smaller verified kernel calculus below the current implementation. The summary-based frontend is in place: FileSummary</code> acts as the declaration-level interface artifact, ResolvedImports</code> is the per-module imported-summary artifact, and Check/Elab share a summary-driven import path. Diagnostics now use native Except Diagnostics</code> transport with range-capable spans, hint text, and coarse-grained multi-error accumulation. The immediate compiler direction is to keep shrinking compiler magic at the builtin boundary, deepen and harden the stdlib surface, and push formalization over the cleaned Core/SSA pipeline. #</a>No Hidden Control Flow</h2> When you read Concrete code, what you see is what executes. No implicit function calls. Operators are not overloaded methods. a + b</code> on integers is primitive addition, not a call to Add::add</code>. There are no implicit conversions that invoke code. No implicit destruction. The compiler never inserts destructor calls. Concrete requires you to write defer destroy(x)</code>. You see the cleanup in the source. No implicit allocation. Allocation happens when you call a function with Alloc</code> capability bound to an allocator. String concatenation, collection growth: if they allocate, you see with(Alloc)</code> in the signature. No invisible error handling. Errors propagate only where ?</code> appears. There are no exceptions unwinding the stack behind your back. The cost is verbosity. The benefit is that reading the code tells you what the code does. For auditing, debugging, and formal verification, this tradeoff is correct. #</a>Types</h2> #</a>Primitives</h3> Bool Int, i8, i16, i32 Uint, u8, u16, u32 Float32, Float64 Char, String Unit </code></pre> #</a>Algebraic Data Types</h3> enum Option<T> { Some { value: T }, None {}, } enum Result<T, E> { Ok { value: T }, Err { error: E }, } enum List<T> { Nil {}, Cons { head: T, tail: List<T> }, } </code></pre> #</a>Records</h3> struct Point { x: Float64, y: Float64, } </code></pre> #</a>Standard Library Types</h3> For domains where precision matters, the standard library includes: Decimal: fixed-point decimal arithmetic for financial calculations</li> BigInt: arbitrary-precision integers</li> BigDecimal: arbitrary-precision decimals</li> </ul> These are planned standard library types, not yet implemented. They will avoid floating-point representation errors in financial systems and cryptographic applications. The current implementation already provides a real low-level stdlib spine: Vec<T></code>, HashMap<K, V></code>, HashSet<K></code>, Deque<T></code>, BinaryHeap<T></code>, OrderedMap<K, V></code>, OrderedSet<K></code>, BitSet</code>, plus systems modules such as fs</code>, env</code>, process</code>, net</code>, fmt</code>, time</code>, rand</code>, parse</code>, and test</code>. The important architectural trend is that these are increasingly ordinary stdlib surfaces rather than compiler-known public APIs. #</a>Linearity and Copy</h2> All values in Concrete are linear by default. A linear value must be consumed exactly once, not zero times (that’s a leak), not twice (that’s a double-free). This follows the same strict direction as Austral: forgetting a value is rejected rather than silently accepted. Consumption happens when you pass the value to a function that takes ownership, return it, destructure it via pattern matching, or explicitly call destroy(x)</code>. fn example!() { let f = open("data.txt") defer destroy(f) let content = read(&f) // destroy(f) runs here because of defer } </code></pre> If f</code> isn’t consumed on all paths, the program is rejected. If you try to use f</code> after moving it, the program is rejected. This is compile-time enforcement, not runtime checking. #</a>The Copy Marker</h3> Some types escape linear restrictions. The rules for Copy</code> are: Copy is explicit and opt-in. You must mark a type as Copy</code>; it is never inferred.</li> Copy is structural. A type can be Copy</code> only if all its fields are Copy</code>.</li> Copy types cannot have destructors. If a type defines destroy</code>, it cannot be Copy</code>.</li> Copy types cannot contain linear fields. A Copy</code> record with a File</code> field is rejected.</li> </ol> struct Copy Point { x: Float64, y: Float64, } </code></pre> The primitive numeric types and Bool</code> are built-in Copy</code> types. String</code> is linear. For generic types, linearity depends on the type parameter: Option<Int></code> is Copy</code> because Int</code> is; Option<File></code> is linear because File</code> is. Copy</code> is not an escape hatch from thinking about resources. It’s a marker for types that have no cleanup requirements and can be freely duplicated. #</a>Destructors</h3> A linear type may define a destructor: struct File { handle: FileHandle, } impl Destroy for File with(File) { fn destroy(self) { close_handle(self.handle); } } </code></pre> The destructor takes ownership of self</code>, may require capabilities, and runs exactly once when explicitly invoked. destroy(x)</code> is only valid if the type defines a destructor. A type without a destructor must be consumed by moving, returning, or destructuring. #</a>Defer</h3> The defer</code> statement schedules cleanup at scope exit, borrowed directly from Zig and Go: fn process_files!() { let f1 = open("a.txt") defer destroy(f1) let f2 = open("b.txt") defer destroy(f2) // When scope exits: // 1. destroy(f2) runs // 2. destroy(f1) runs } </code></pre> Multiple defer</code> statements execute in reverse order (LIFO). defer</code> runs at scope exit including early returns and error propagation. #</a>Defer Reserves the Value</h3> When a value is scheduled with defer destroy(x)</code>, it becomes reserved. The rules: After defer destroy(x)</code>, you cannot move x</code></li> After defer destroy(x)</code>, you cannot destroy x</code> again</li> After defer destroy(x)</code>, you cannot defer destroy(x)</code> again</li> After defer destroy(x)</code>, you cannot create borrows of x</code> that might overlap the deferred destruction point</li> </ol> The value is still owned by the current scope until exit, but it is no longer available for use. This prevents double destruction and dangling borrows. #</a>Borrowing</h2> Borrowing defers consumption without extending lifetime or weakening linearity. References let you use values without consuming them. Concrete’s borrowing model uses lexical regions, but those regions stay out of function signatures in the current surface language. borrow f as fref in R { // fref has type &File // f is unusable in this block let len = length(fref); } // f is usable again </code></pre> Functions simply accept references directly: fn length(file: &File) -> Uint { ... } </code></pre> The checker enforces that a reference created inside a borrow region cannot escape that region. For single-expression borrows, the region is anonymous: let len = length(&f) // borrows f for just this call </code></pre> #</a>Borrowing Rules</h3> While borrowed, the original is unusable</li> Multiple immutable borrows allowed</li> Mutable borrows exclusive: one &mut T</code> at a time, no simultaneous &T</code></li> References cannot escape their region</li> Nested borrows of the same owned value forbidden</li> Derived references can’t outlive the original’s region</li> </ol> #</a>Capabilities</h2> #</a>What Capabilities Are</h3> A capability is a static permission annotation on a function. It declares which effects the function may perform. Capabilities are not runtime values—they cannot be created, passed, stored, or inspected at runtime. They exist only at the type level, checked by the compiler and erased before execution. Capabilities are predefined names. Users cannot define new capabilities or create composite capability types. Function signatures may combine predefined capabilities using +</code> in the with()</code> clause, but only among names exported by the platform’s capability universe. The set of capabilities is fixed per target platform and finite—user code cannot extend it. There is no capability arithmetic, no capability inheritance, no way to forge a capability your caller didn’t have. Capabilities that can be manufactured at runtime aren’t capabilities—they’re tokens. #</a>Purity</h3> Concrete is pure by default, following Austral’s approach to effect tracking. A function without capability annotations cannot perform IO, cannot allocate, cannot mutate external state. It computes a result from its inputs, nothing more. Purity in Concrete has a precise definition: a function is pure if and only if it declares no capabilities and does not require Alloc</code>. Equivalently, purity means an empty capability set. Pure functions may use stack allocation and compile-time constants—these are not effects. Pure functions may diverge—termination is orthogonal to purity. A non-terminating function that performs no IO and touches no heap is still pure. This separates effect-freedom (what Concrete tracks) from totality (which Concrete does not guarantee). Purity enables equational reasoning: a pure function called twice with the same arguments yields the same result. Totality would enable stronger claims about program termination, but enforcing it would require restricting recursion, which conflicts with systems programming. When a function needs effects, it declares them: fn read_file(path: String) with(File) -> String { ... } fn process_data() with(File, Network, Alloc) -> Result { ... } </code></pre> Capabilities propagate monotonically. If f</code> calls g</code>, and g</code> requires File</code>, then f</code> must declare File</code> too. No implicit granting, no ambient authority. The compiler enforces this transitively. #</a>The Std Capability</h3> For application entry points, Concrete provides a shorthand. The !</code> suffix declares the Std</code> capability: fn main!() { println("Hello") } </code></pre> This desugars to fn main() with(Std)</code>. Std</code> includes file operations, network, clock, environment, random, console, process, and allocation, but excludes Unsafe</code>. Library code should prefer explicit capability lists. This is a social convention, not a mechanical enforcement. The compiler won’t reject a library function that uses Std</code>. But explicit capabilities make dependencies auditable. Std</code> is a convenience for applications, not a license for libraries. #</a>Security Model</h3> Capabilities don’t sandbox code. If a dependency declares with(Network)</code>, it gets network access. What they provide is auditability. You can grep for with(Network)</code> and find every function that touches the network. You can verify that your JSON parser has no capabilities. You can review dependency updates by diffing capability declarations. #</a>Capability Polymorphism</h3> Concrete supports capability polymorphism: fn map<T, U, cap C>(list: List<T>, f: fn(T) with(C) -> U) with(C) -> List { ... } </code></pre> A capability variable like C</code> is inferred from the function argument at the call site, then propagated through the caller just like any concrete capability set. This avoids duplicating generic combinators for every effect combination while keeping effect requirements explicit in the type. #</a>Parametricity</h3> Generic functions cannot accidentally become effectful depending on instantiation. A function fn map<T, U>(list: List<T>, f: fn(T) -> U) -> List</code> is pure regardless of what T</code> and U</code> are. If f</code> requires capabilities, that must be declared in the signature. Capabilities are checked before monomorphization. When generic code is specialized to concrete types, capability requirements don’t change. A pure generic function stays pure at every instantiation. #</a>Allocation</h2> Allocation deserves special attention because it’s often invisible. In most languages, many operations allocate behind your back: string concatenation, collection growth. Concrete treats allocation as a capability, with explicit allocator passing inspired by Zig. Functions that allocate declare with(Alloc)</code>. The call site binds which allocator: fn main!() { let arena = Arena.new() defer arena.deinit() let list = create_list<Int>() with(Alloc = arena) push(&mut list, 42) with(Alloc = arena) } </code></pre> Inside with(Alloc)</code>, the bound allocator propagates through nested calls. At the boundary, you see exactly where allocation happens and which allocator serves it. Stack allocation does not require Alloc</code>: fn example() { let x: Int = 42 // stack let arr: [Uint8; 100] = zeroed() // stack } </code></pre> Allocation-free code is provably allocation-free. #</a>Allocator Binding Scope</h3> Allocator binding is lexically scoped. A binding applies within the static extent of the call being evaluated and any nested calls that require with(Alloc)</code>. A nested binding may shadow an outer binding: fn outer() with(Alloc) { inner() // uses outer binding inner() with(Alloc = arena2) // shadows within this call } </code></pre> #</a>Allocator Types</h3> // General-purpose heap allocator let gpa = GeneralPurposeAllocator.new() defer gpa.deinit() // Arena allocator, free everything at once let arena = Arena.new(gpa) defer arena.deinit() // Fixed buffer allocator, no heap let buf: [Uint8; 1024] = zeroed() let fba = FixedBufferAllocator.new(&buf) </code></pre> All allocators implement a common Allocator</code> trait. #</a>Allocator Interface</h3> trait Allocator { fn alloc<T>(&mut self, value: T) -> Result<Heap<T>, AllocError> fn alloc_array<T>(&mut self, count: Uint) -> Result<HeapArray<T>, AllocError> fn free<T>(&mut self, ptr: Heap<T>) -> T fn free_array<T>(&mut self, arr: HeapArray<T>) fn realloc_array<T>(&mut self, arr: HeapArray<T>, new_count: Uint) -> Result<HeapArray<T>, AllocError> } </code></pre> The interface is minimal. alloc</code> returns owned heap memory, not a borrow. alloc_array</code> handles dynamically sized buffers. free</code> consumes heap ownership and returns the stored value. All operations take &mut self</code>: allocators are stateful resources, not ambient services. Custom allocators implement this trait. The standard library allocators (GeneralPurposeAllocator</code>, Arena</code>, FixedBufferAllocator</code>) are implementations, not special cases. #</a>Heap Ownership</h3> Heap allocation is represented explicitly in the type system: let p: Heap<Point> = alloc(Point { x: 1.0, y: 2.0 }) with(Alloc = arena) defer destroy(p) let x = p->x p->y = 4.0 </code></pre> Heap<T></code> is a linear owned type. Access goes through -></code>, which borrows the heap value and makes heap access visible at the use site. HeapArray<T></code> is the dynamically sized counterpart used by collections. #</a>Error Handling</h2> Errors are values, using Result<T, E></code> and the ?</code> operator for propagation: fn parse(input: String) -> Result<Config, ParseError> { ... } fn load_config!() -> Result<Config, Error> { let f = open("config.toml")? defer destroy(f) let content = read(&f) let config = parse(content)? Ok(config) } </code></pre> The ?</code> operator propagates errors. When ?</code> triggers an early return, all defer</code> statements in scope run first. Cleanup happens even on error paths. No exceptions. No panic. #</a>Abort</h3> Abort is immediate process termination, outside normal control flow and outside the language’s semantic model. Following Zig’s approach: Out-of-memory conditions trigger abort</li> Stack overflow triggers abort</li> Explicit abort()</code> terminates immediately</li> Deferred cleanup does not run on abort</li> </ul> defer</code> is for normal control flow, not catastrophic failure. Abort is the escape hatch when Result</code> isn’t enough. The process stops. There are no guarantees about state after abort begins. #</a>What You’re Giving Up</h2> Concrete is not a general-purpose language. It’s for code that must be correct: cryptographic implementations, financial systems, safety-critical software, blockchain infrastructure. No garbage collection. Memory is managed through linear types and explicit destruction. No GC pauses, no unpredictable latency, no hidden memory pressure. No implicit allocation. Allocation requires the Alloc</code> capability. grep with(Alloc)</code> finds every function that might touch the heap. No interior mutability. All mutation flows through &mut</code> references. An immutable reference &T</code> guarantees immutability, no hidden mutation behind an immutable facade. This forbids patterns like shared caches and memoization behind shared references. If you need a cache, pass &mut</code>. If you need lazy initialization, initialize before borrowing. For advanced patterns that genuinely require interior mutability, the standard library provides UnsafeCell<T></code> gated by the Unsafe</code> capability. No reflection, no eval, no runtime metaprogramming. All code paths are determined at compile time. There is no way to inspect types at runtime, call methods by name dynamically, or generate code during execution. If macros are added in a future version, they will be constrained to preserve the “can a machine reason about this?” principle: Hygienic — no accidental variable capture</li> Phase-separated — macro expansion completes before type checking</li> Syntactic — macros transform syntax trees, not strings</li> Capability-tracked — procedural macros that execute arbitrary code at compile time will require capability annotations, extending effect tracking to the compile-time phase</li> </ul> No implicit global state. All global interactions (file system, network, clock, environment) are mediated through capabilities. No variable shadowing. Each variable name is unique within its scope. No null. Optional values use Option<T></code>. No undefined behavior in safe code. Kernel semantics are fully defined and proven sound. The Unsafe</code> capability explicitly reintroduces the possibility of undefined behavior for FFI and low-level operations. No concurrency primitives. The language provides no threads, no async/await, no channels. Concurrency is a library concern. This may change, but any future concurrency model must preserve determinism and linearity, likely through structured or deterministic concurrency. This is a design constraint, not an open question. #</a>Anti-Features Summary</h3> Concrete does not have</th> Rationale</th></tr></thead> Garbage collection</td> Predictable latency, explicit resource management</td></tr> Hidden control flow</td> Auditability, debuggability</td></tr> Hidden allocation</td> Performance visibility, allocator control</td></tr> Interior mutability</td> Simple reasoning, verification tractability</td></tr> Reflection / eval</td> Static analysis, all paths known at compile time</td></tr> Global mutable state</td> Effect tracking, reproducibility</td></tr> Variable shadowing</td> Clarity, fewer subtle bugs</td></tr> Null</td> Type safety via Option<T></code></td></tr> Exceptions</td> Errors as values, explicit propagation</td></tr> Implicit conversions</td> No silent data loss or coercion</td></tr> Operator overloading</td> Operators are primitive, not trait methods</td></tr> Uninitialized variables</td> Memory safety</td></tr> Macros</td> Undecided; if added, will be hygienic and capability-aware</td></tr> Closures</td> Hidden captures are implicit allocation and data flow</td></tr> Concurrency primitives</td> Undecided; must preserve linearity and determinism</td></tr> Undefined behavior (in safe code)</td> Kernel semantics fully defined</td></tr> </tbody></table> #</a>Pattern Matching</h2> Exhaustive pattern matching with linear type awareness: fn describe(opt: Option<Int>) -> String { match opt { Option#Some { value } => string_concat("Got ", int_to_string(value)), Option#None {} => "Nothing" } } </code></pre> Linear types in patterns must be consumed: fn handle!(result: Result<Data, File>) { match result { Result#Ok { value } => use_data(value), Result#Err { error } => destroy(error) } } </code></pre> Borrowing in patterns: fn peek(opt: &Option<Int>) -> Int { match opt { &Option#Some { value } => value, &Option#None {} => 0 } } </code></pre> #</a>Traits</h2> Traits provide bounded polymorphism with explicit static dispatch: trait Printable { fn print(&self) with(Console) } trait Describable { fn describe(&self) -> String } fn print_all<T: Printable>(list: &List<T>) with(Console) { ... } </code></pre> #</a>Receiver Modes and Linear Types</h3> Trait methods take the receiver in one of three forms: &self</code> — borrows the value immutably</li> &mut self</code> — borrows the value mutably</li> self</code> — takes ownership, consuming the value</li> </ul> If a trait method takes self</code>, calling it consumes the value. This follows linear consumption rules: trait Consume { fn consume(self) } fn use_once<T: Consume>(x: T) { x.consume() // x is consumed here // x.consume() // ERROR: x already consumed } </code></pre> A trait implementation for a linear type must respect the receiver mode. An &self</code> method cannot consume the value. An &mut self</code> method cannot let the value escape. A self</code> method consumes it. #</a>Type Inference</h2> Type inference is local only. Function signatures must be fully annotated. Inside bodies, local types may be inferred: fn process(data: List<Int>) with(Alloc) -> List<Int> { let doubled = map(data, double) // return type inferred let filtered = filter(doubled, is_positive) // return type inferred filtered } </code></pre> You can always understand a function’s interface without reading its body. #</a>Modules</h2> pub fn open(path: String) with(File) -> Result<File, IOError> { ... } fn read(file: &File) with(File) -> String { ... } fn validate(path: String) -> Bool { ... } </code></pre> Visibility is pub</code> or private by default. Multi-file modules use mod name;</code> plus import name.{symbol}</code>. #</a>Capabilities as Public Contract</h3> Capabilities are part of a function’s signature and therefore part of the public API contract. Changing the required capability set of a public function is a breaking change. This applies in both directions: adding a capability requirement breaks callers who don’t have it; removing one changes the function’s guarantees. When reviewing dependency updates, diff the capability declarations. A library that adds with(Network)</code> to a function that previously had none is a significant change, even if the types remain identical. mod filesystem; import filesystem.{open, read, write}; </code></pre> #</a>Unsafe, Trusted, and FFI</h2> Concrete splits low-level safety into four layers: Capabilities declare semantic effects in public signatures (with(File)</code>, with(Alloc)</code>). They propagate through the call graph and are auditable with grep</code>.</li> trusted fn</code> / trusted impl</code> mark code that uses raw pointers internally but exposes a safe API. Inside trusted code, raw pointer dereference, assignment, pointer arithmetic, and pointer casts are allowed without leaking Unsafe</code> to callers. The trust boundary is explicit in the source and tracked through the full IR pipeline and audit reports.</li> trusted extern fn</code> marks narrow audited foreign bindings such as libc-style math wrappers. This is intentionally narrower than general FFI and shows up separately in reports.</li> with(Unsafe)</code> gates foreign or semantically dangerous boundaries. Ordinary extern fn</code> calls still require with(Unsafe)</code>, even inside trusted code.</li> </ol> The Unsafe</code> capability gates operations the type system cannot currently verify: foreign function calls, raw pointer dereference (outside trusted code), raw pointer assignment (outside trusted code), and unsafe pointer casts (outside trusted code). Unsafe</code> propagates through the call graph like any other capability. Grep for with(Unsafe)</code> to find all foreign boundaries. Grep for trusted</code> to find all internal trust boundaries. #</a>Raw Pointers</h3> Raw pointers exist for FFI and low-level memory manipulation: *const T // immutable raw pointer *mut T // mutable raw pointer </code></pre> Raw pointers are Copy</code>. They carry no lifetime information and no linearity guarantees. This is safe because: Creating a raw pointer from a reference is safe.</li> Holding a raw pointer is safe. It’s a number.</li> Using a raw pointer requires Unsafe</code>. Dereference, assignment, and unsafe casts are gated.</li> </ul> fn to_ptr<T>(r: &T) -> *const T { return r as *const T; } fn store<T>(ptr: *mut T, value: T) with(Unsafe) { *ptr = value; } </code></pre> The key boundary is deliberate: Safe: reference-to-pointer casts like &x as *const T</code> or &mut x as *mut T</code></li> Unsafe: pointer dereference, pointer assignment, pointer-to-pointer casts, integer-to-pointer casts, pointer-to-integer casts, and other provenance-breaking operations</li> </ul> Copy</code> does not imply usable. Raw pointers can be freely duplicated because they carry no guarantees. Safety is enforced at the point of use, not at the point of creation. #</a>Foreign Functions</h3> Declare foreign functions with extern fn</code>. Calling them normally requires Unsafe</code>: extern fn malloc(size: Uint) -> *mut Unit; extern fn free(ptr: *mut Unit); fn alloc_raw(size: Uint) with(Unsafe) -> *mut Unit { return malloc(size); } </code></pre> The compiler generates calling convention glue and links the symbol. Foreign signatures are restricted to FFI-safe types. Today that means primitive scalars, raw pointers, unit, and #[repr(C)]</code> structs whose fields are themselves FFI-safe. A narrow audited subset can be declared as trusted extern fn</code> so callers do not need with(Unsafe)</code> for pure, well-understood foreign symbols. This is not a general safe-FFI escape hatch; it is a deliberately small carve-out. #</a>Layout and #[repr(C)]</code></h3> Concrete now has an explicit FFI/layout surface: #[repr(C)] struct Header { len: Uint, kind: u32, } </code></pre> The current rules are intentionally strict: #[repr(C)]</code> structs cannot have generics</li> every field of a #[repr(C)]</code> struct must itself be FFI-safe</li> extern fn</code> parameters and returns must be FFI-safe</li> #[repr(packed)]</code> and #[repr(align(N))]</code> exist, but the broader ABI/layout model is still being tightened</li> </ul> This is one of the current implementation frontiers. The language now has a real low-level layout surface, but the long-term goal is to make the ABI model as explicit and mechanically trustworthy as the rest of the language. #</a>Implementation</h2> #</a>Determinism</h3> Concrete aims for bit-for-bit reproducible builds: same source + same compiler = identical binary. No timestamps, random seeds, or environment-dependent data in output. For debugging, deterministic replay: random generation requires Random</code> with explicit seed, system time requires Clock</code>. Same inputs produce identical execution. #</a>The Grammar</h3> LL(1). Every parsing decision with a single token of lookahead. No ambiguity, no backtracking. This is a permanent design constraint, not an implementation detail. Future language evolution is bounded by what LL(1) can express. We accept this constraint for tooling simplicity and error message quality. #</a>Compilation Targets</h3> Native via direct LLVM IR emission today, with SSA as the backend boundary. MLIR and additional backends remain possible later, but the important architectural rule is that they should plug in after SSA rather than creating parallel semantic backend paths. #</a>Tooling</h3> Today Concrete ships with the compiler, a built-in test runner (--test</code>), project metadata, examples, and more than 370 end-to-end tests. The compiler exposes audit-focused inspection modes (--report caps|unsafe|layout|interface|mono</code>) and internal stage outputs (--emit-core</code>, --emit-ssa</code>). The testing strategy has expanded well beyond smoke tests: fuzzing, property tests, trace tests, report-consistency tests, and selected codegen differential tests are now part of the project’s confidence story. A formatter, richer package workflow, linter, and REPL are better described as planned tooling than finished tooling. The standard library now covers more than 30 modules, so the next priority is less “add basics” and more “deepen, harden, and make the public surface cleaner while pushing formalization.” #</a>Profiling and Tracing</h3> Profiling and tracing are first-class: Built into the runtime, not bolted on</li> Low overhead when disabled</li> Structured output for tooling integration</li> </ul> Code is read more often than written, but executed more often than read. Performance visibility matters for systems programming. #</a>What You Can Say About Programs</h2> If a program type-checks: “This function is pure.” No capabilities declared. No side effects, no IO, no allocation. “This resource is used exactly once.” Linear type. No leaks, no double-free, no use-after-free. “These are the only effects this code can perform.” Capability set is explicit and complete. “This code cannot escape the type system.” Unsafe operations require with(Unsafe)</code>. “Allocation happens here, using this allocator.” Call site binds the allocator. “Cleanup happens here.” defer destroy(x)</code> is visible. “This build is reproducible.” Same inputs, same binary. Mechanical guarantees from a type system proven sound in Lean. Not conventions, proofs. #</a>Example</h2> import FileSystem.{open, read, write} import Parse.{parse_csv} fn process_file(input_path: String, output_path: String) with(File, Alloc) -> Result<Unit, Error> { let in_file = open(input_path)? defer destroy(in_file) let content = read(&in_file) let data = parse_csv(content)? let output = transform(&data) let out_file = open(output_path)? defer destroy(out_file) write(&mut out_file, output) Ok(()) } fn transform(data: &List<Row>) -> String { ... } fn main!() { let arena = Arena.new() defer arena.deinit() match process_file("input.csv", "output.txt") with(Alloc = arena) { Ok(()) => println("Done"), Err(e) => println("Error: " + e.message()) } } </code></pre> Everything is visible: resource acquisition, cleanup scheduling, error propagation, allocator binding. #</a>Influences</h2> The kernel calculus is formalized in Lean 4. Coq could serve the same role; we chose Lean for its performance and active development. Austral shaped the type system more than any other language. Linear types in Concrete are strict: every value must be consumed exactly once. The capability system for effect tracking also comes from Austral. From the broader systems-language tradition come borrowing, traits, error handling, and pattern matching. Concrete uses lexical regions instead of lifetime annotations, which keeps the model smaller and more explicit. Zig’s influence shows in explicit allocator passing and defer. Zig functions that allocate take an allocator parameter; Concrete expresses the same idea through with(Alloc)</code> and allocator binding at call sites. Go had defer first. Go also shipped gofmt, which ended style debates by making one canonical format. We plan to ship a formatter. The !</code> syntax for impure functions comes from Roc. fn main!()</code> marks impurity at a glance. Koka, Eff, and Frank are the algebraic effects languages. Concrete’s capabilities are a simplified version of their effect systems. Capability polymorphism is now part of the language design and current implementation, though the overall effect system is still intentionally much smaller and more explicit than those languages. Haskell proved that pure-by-default is practical. Clean had uniqueness types (precursor to linear types) and purity before Haskell did. Cyclone pioneered region-based memory, the research line that led to Rust’s lifetimes and our lexical regions. ATS showed linear types and theorem proving can coexist. Ada/SPARK proved formal verification works in production: avionics, rail, security-critical systems. CompCert and seL4 established that you can mechanically verify real systems software. A verified C compiler and a verified microkernel. That’s the standard we’re aiming for. These ideas work. We’re combining them and proving the combination sound. #</a>Who Should Use This</h2> Concrete trades convenience for explicitness, flexibility for auditability. Prototyping is slower. Some patterns become verbose. You’ll miss interior mutability for certain data structures. But for cryptographic primitives, consensus protocols, financial transaction systems, medical device firmware, the trade is worth it. Strong claims about program behavior, mechanically verified. A language you can trust the way you trust mathematics: not because someone promises it works, but because you can check the proof. #</a>Quick Reference</h2> Annotation</th> Meaning</th></tr></thead> fn foo() -> T</code></td> Pure function, no capabilities</td></tr> fn foo!() -> T</code></td> Shorthand for with(Std)</code></td></tr> fn foo() with(C) -> T</code></td> Requires capability set C</code></td></tr> with(Alloc)</code></td> Function may allocate</td></tr> with(Alloc = a)</code></td> Bind allocator a</code> at call site</td></tr> T</code></td> Linear type, consumed exactly once</td></tr> struct Copy T</code></td> Unrestricted type, freely duplicated</td></tr> &T</code></td> Immutable reference</td></tr> &mut T</code></td> Mutable reference</td></tr> *const T</code> / *mut T</code></td> Raw pointer (unsafe to dereference)</td></tr> borrow x as y in R { }</code></td> Explicit borrow with named region</td></tr> defer expr</code></td> Run expr</code> at scope exit</td></tr> destroy(x)</code></td> Consume via destructor</td></tr> extern fn foo(...)</code></td> Foreign function binding</td></tr> </tbody></table> #</a>Appendix A: Standard Capabilities</h2> The Std</code> capability (accessed via !</code>) bundles these individual capabilities: Capability</th> Gates</th></tr></thead> File</code></td> Open, read, write, close files. Directory operations.</td></tr> Network</code></td> Sockets, HTTP, DNS resolution.</td></tr> Alloc</code></td> Heap allocation. Requires allocator binding at call site.</td></tr> Clock</code></td> System time, monotonic time, sleep.</td></tr> Random</code></td> Random number generation. Requires explicit seed for reproducibility.</td></tr> Env</code></td> Environment variables, command line arguments.</td></tr> Process</code></td> Spawn processes, exit codes, signals.</td></tr> Console</code></td> Stdin, stdout, stderr.</td></tr> </tbody></table> Capabilities not in Std</code>: Capability</th> Gates</th></tr></thead> Unsafe</code></td> Raw pointer operations, FFI calls, transmute, inline assembly. Never implicit.</td></tr> </tbody></table> A function with no capability annotation is pure. A function with !</code> has access to everything except Unsafe</code>. A function with explicit with(File, Alloc)</code> has exactly those capabilities. Capabilities are not hierarchical. Std</code> is a shorthand for a set, not a super-capability. You cannot request “half of Std.” #</a>Appendix B: Open Questions</h2> These are unresolved design decisions: Concurrency No concurrency primitives exist. The language is currently single-threaded. Any future model must preserve: Linearity (no data races from aliasing)</li> Determinism (reproducible execution)</li> Effect tracking (concurrency as capability)</li> </ul> Candidates: structured concurrency (like Trio/libdill), deterministic parallelism (like Haskell’s par</code>), actor model with linear message passing. Not decided. Effect Handlers Capabilities track effects but don’t handle them. Full algebraic effects would allow: fn with_mock_filesystem<T>(f: fn() with(File) -> T) -> T { handle File in f() { open(path) => resume(MockFile.new(path)) read(file) => resume(mock_data) } } </code></pre> This enables testing, sandboxing, effect interception. Significant implementation complexity. Not committed. Module System Current design is still intentionally minimal. Open questions: Parameterized modules (functors)?</li> Module-level capability restrictions?</li> Separate compilation units built on file summaries?</li> How much semantic authority should remain file-local before Core IR?</li> </ul> FFI and ABI Model The implementation now has #[repr(C)]</code>, FFI-safe validation, and explicit unsafe gating, but the ABI model is not finished. Remaining questions: Integer mappings (is Int</code> C’s int</code> or intptr_t</code>?)</li> Complete struct and enum layout guarantees</li> Calling conventions</li> Nullable pointer representation</li> String encoding at boundaries</li> </ul> Variance Generic types have variance implications. List<T></code> is covariant in T</code>. fn(T) -> U</code> is contravariant in T</code>. The spec doesn’t address this. For linear types, variance interacts with consumption. Needs formalization. Macros No macro system. Options: None (keep it simple)</li> Hygienic macros (Scheme-style)</li> Procedural macros (Rust-style)</li> Compile-time evaluation (Zig-style comptime)</li> </ul> Procedural macros would need capability restrictions. Not decided. #</a>Appendix C: Glossary</h2> Affine type: A type whose values can be used at most once. Rust’s ownership model is affine: you can drop a value without consuming it. Capability: A token that grants permission to perform an effect. Functions declare required capabilities; callers must have them. Capabilities propagate: if f</code> calls g</code>, and g</code> needs File</code>, then f</code> needs File</code>. Consumption: Using a linear value in a way that fulfills its “exactly once” obligation. Methods of consumption: pass to a function taking ownership, return, destructure via pattern match, call destroy()</code>. Copy type: A type exempt from linearity. Values can be duplicated freely. Must be explicitly marked. Cannot have destructors or linear fields. Destruction: Consuming a linear value by invoking its destructor. destroy(x)</code> calls the type’s destructor and consumes x</code>. Effect: An observable interaction with the world outside pure computation: IO, allocation, mutation, non-determinism. Concrete tracks effects through capabilities. Elaboration: The compiler phase that transforms checked surface syntax into typed Core IR. In the current compiler, parsing, resolution, checking, elaboration, Core validation, monomorphization, lowering, SSA verification/cleanup, and code emission are separate passes. Kernel: The core calculus formalized in Lean. A small language with mechanically verified properties. The surface language elaborates into it. Lexical region: A scope that bounds reference lifetimes. References created in a region cannot escape it. Unlike Rust’s lifetime parameters, regions are always lexical and never appear in signatures. Linear type: A type whose values must be used exactly once. Not zero (leak), not twice (double-use). Concrete’s default. Purity: Absence of effects. A pure function computes a result from its inputs without IO, allocation, or mutation. In Concrete, functions without capability annotations are pure. Raw pointer: A *const T</code> or *mut T</code> value. Carries no lifetime or linearity information. Safe to create and hold; unsafe to dereference. Reference: A borrowed view of a value. &T</code> for immutable, &mut T</code> for mutable. The original value is inaccessible while borrowed. Region: See lexical region. Std: The standard capability set. Shorthand for File</code>, Network</code>, Alloc</code>, Clock</code>, Random</code>, Env</code>, Process</code>, Console</code>. Excludes Unsafe</code>. Unsafe: The capability that permits operations the type system cannot verify: FFI, raw pointer dereference, transmute. #</a>Appendix D: Comparison Table</h2> Feature</th> Concrete</th> Rust</th> Zig</th> Austral</th> Go</th></tr></thead> Memory safety</td> Linear types</td> Ownership + borrow checker</td> Runtime checks (optional)</td> Linear types</td> GC</td></tr> Linearity</td> Strict (exactly once)</td> Affine (at most once)</td> None</td> Strict</td> None</td></tr> GC</td> None</td> None</td> None</td> None</td> Yes</td></tr> Effect tracking</td> Capabilities</td> None</td> None</td> Capabilities</td> None</td></tr> Pure by default</td> Yes</td> No</td> No</td> Yes</td> No</td></tr> Explicit allocation</td> Capability + binding</td> Global allocator</td> Allocator parameter</td> No</td> GC</td></tr> Null</td> None (Option<T></code>)</td> None (Option<T></code>)</td> Optional (?T</code>)</td> None (Option[T]</code>)</td> Yes (nil</code>)</td></tr> Exceptions</td> None</td> Panic (discouraged)</td> None</td> None</td> Panic</td></tr> Error handling</td> Result</code> + ?</code></td> Result</code> + ?</code></td> Error unions</td> Result</code></td> Multiple returns</td></tr> Lifetime annotations</td> None (lexical regions)</td> Yes</td> None</td> None</td> N/A (GC)</td></tr> Formal verification</td> Kernel in Lean</td> External tools</td> None</td> None</td> None</td></tr> Defer</td> Yes</td> No (RAII)</td> Yes</td> No</td> Yes</td></tr> Interior mutability</td> None</td> Cell</code>, RefCell</code>, etc.</td> Pointers</td> None</td> Pointers</td></tr> Unsafe escape hatch</td> with(Unsafe)</code></td> unsafe</code> blocks</td> No safe/unsafe distinction</td> Unsafe_Module</code></td> No distinction</td></tr> Macros</td> None (undecided)</td> Procedural + declarative</td> Comptime</td> None</td> None</td></tr> Concurrency</td> None (undecided)</td> async</code>, threads, channels</td> Threads, async</td> None</td> Goroutines, channels</td></tr> Formatter</td> Planned</td> rustfmt (separate)</td> zig fmt</td> None</td> gofmt</td></tr> Grammar</td> LL(1)</td> Complex</td> Simple</td> Simple</td> LALR</td></tr> </tbody></table> #</a>Appendix E: Error Messages</h2> These are representative error messages. The actual compiler may differ. Linearity violation: value not consumed error[E0201]: linear value `f` is never consumed --> src/main.con:4:9 | 4 | let f = open("data.txt") | ^ this value has type `File` which is linear | = help: linear values must be consumed exactly once = help: add `defer destroy(f)` or pass `f` to a function that takes ownership </code></pre> Linearity violation: value consumed twice error[E0202]: value `f` consumed twice --> src/main.con:7:12 | 5 | let content = read_all(f) | - first consumption here 6 | 7 | destroy(f) | ^ second consumption here | = help: after passing `f` to `read_all`, you no longer own it </code></pre> Borrow escape error[E0301]: reference cannot escape its region --> src/main.con:3:12 | 2 | borrow data as r in R { | --- region R starts here 3 | return r | ^ cannot return reference with region R 4 | } | - region R ends here | = help: references are only valid within their borrow region </code></pre> Missing capability error[E0401]: function requires capability `Network` which is not available --> src/main.con:8:5 | 8 | fetch(url) | ^^^^^^^^^^ requires `Network` | = note: the current function has capabilities: {File, Alloc} = help: add `Network` to the function's capability declaration: | 2 | fn process(url: String) with(File, Alloc, Network) -> Result<Data, Error> | +++++++++ </code></pre> Mutable borrow conflict error[E0302]: cannot borrow `data` as immutable because it is already borrowed as mutable --> src/main.con:4:17 | 3 | borrow mut data as m in R { | - mutable borrow occurs here 4 | let len = length(&data) | ^^^^^ immutable borrow attempted here | = help: mutable borrows are exclusive; no other borrows allowed </code></pre> Unsafe operation without capability error[E0501]: operation requires `Unsafe` capability --> src/main.con:6:5 | 6 | ptr_read(addr) | ^^^^^^^^^^^^^^ unsafe operation | = note: reading from raw pointers may cause undefined behavior = help: add `Unsafe` to the function's capabilities: | 2 | fn dangerous(addr: *const Int) with(Unsafe) -> Int | ++++++++++++ </code></pre> #</a>References</h2> #</a>Languages</h3> Lean 4</a> — theorem prover and programming language</li> Austral</a> — linear types and capabilities for systems programming Specification</a></li> </ul> </li> Rust</a> — ownership, borrowing, traits</li> Zig</a> — explicit allocators, defer, no hidden control flow</li> Roc</a> — pure functional, !</code> for effects</li> Koka</a> — algebraic effects and handlers</li> Eff</a> — algebraic effects research language</li> Frank</a> — effects as calling conventions</li> Clean</a> — uniqueness types, pure by default</li> ATS</a> — linear types with theorem proving</li> Cyclone</a> — region-based memory for C</li> Ada/SPARK</a> — formal verification in systems programming</li> </ul> #</a>Verified Systems</h3> CompCert</a> — verified C compiler</li> seL4</a> — verified microkernel</li> CertiKOS</a> — verified concurrent OS kernel</li> Iris</a> — higher-order concurrent separation logic</li> </ul> #</a>Papers</h3> Linear Logic</a> — Wadler’s papers on linear logic</li> Linearity and Uniqueness: An Entente Cordiale</a> — linear vs unique vs affine</li> Cyclone</a> — region-based memory safety for C</li> An Introduction to Algebraic Effects and Handlers</a> — Matija Pretnar</li> Capability Myths Demolished</a> — what capabilities actually provide</li> The Next 700 Programming Languages</a> — Landin’s classic</li> Hints on Programming Language Design</a> — Tony Hoare</li> Growing a Language</a> — Guy Steele</li> RustBelt: Securing the Foundations of the Rust Programming Language</a> — formal verification of Rust</li> Stacked Borrows: An Aliasing Model for Rust</a> — Ralf Jung on aliasing</li> Ownership is Theft: Experiences Building an Embedded OS in Rust</a> — Tock OS</li> A History of Haskell: Being Lazy with Class</a> — design decisions</li> Why Functional Programming Matters</a> — John Hughes</li> On the Criteria To Be Used in Decomposing Systems into Modules</a> — Parnas</li> Clean</a> — uniqueness types specification</li> Using Lightweight Formal Methods to Validate a Key-Value Storage Node</a> — practical verification at AWS</li> </ul> #</a>Blog Posts</h3> Language Design Philosophy Worse is Better</a> — Richard Gabriel on simplicity vs correctness</li> The Hundred-Year Language</a> — Paul Graham</li> Less is more: language features</a> — Mark Seemann on constraints</li> Out of the Tar Pit</a> — Moseley and Marks on complexity</li> Design Principles Behind Smalltalk</a> — Dan Ingalls</li> What to Know Before Debating Type Systems</a> — Chris Smith</li> Execution in the Kingdom of Nouns</a> — Steve Yegge</li> </ul> Austral and Linear Types Introducing Austral</a> — Fernando Borretti’s rationale</li> How Austral’s Linear Type Checker Works</a> — implementation decisions</li> How Capabilities Work in Austral</a> — how capabilities compose</li> Type Systems for Memory Safety</a> — survey of approaches</li> Linear types can change the world!</a> — Wadler</li> Retrofitting Linear Types</a> — adding linear types to Haskell</li> </ul> Rust Design Decisions The Problem with Single-threaded Shared Mutability</a> — why Rust forbids it</li> Rust: A unique perspective</a> — ownership from first principles</li> The Edition Guide: Non-Lexical Lifetimes</a> — why Rust moved beyond lexical scopes</li> Polonius: the future of the borrow checker</a> — Niko Matsakis</li> After NLL: Moving from borrowed data</a> — borrow checker limitations</li> Ralf Jung’s Blog</a> — Stacked Borrows, unsafe, formal semantics</li> Learn Rust With Entirely Too Many Linked Lists</a> — ownership through pain</li> The Rustonomicon</a> — dark arts of unsafe Rust</li> </ul> Graydon Hoare (Rust creator) The Rust I Wanted Had No Future</a> — original vision</li> Not Rust</a> — what Rust deliberately avoided</li> What next for compiled languages?</a> — language evolution</li> </ul> Zig Design Decisions Allocgate</a> — why Zig’s allocator design changed</li> What is Zig’s Comptime</a> — compile-time execution design</li> </ul> Effects and Capabilities Algebraic Effects for the Rest of Us</a> — Dan Abramov</li> What Color is Your Function?</a> — Bob Nystrom on effect tracking</li> Structured Concurrency</a> — Nathaniel Smith</li> Eff Programming Language</a> — algebraic effects research language</li> Koka: Programming with Row-polymorphic Effect Types</a> — official book</li> </ul> Roc and Purity Roc FAQ</a> — official FAQ and design rationale</li> Why Roc Uses Platform/App Split</a> — effect isolation design</li> </ul> Go Design Decisions Go at Google: Language Design in the Service of Software Engineering</a> — Rob Pike</li> Simplicity is Complicated</a> — Rob Pike</li> Errors are values</a> — Rob Pike</li> Go Proverbs</a> — design philosophy</li> Toward Go 2</a> — Russ Cox on language evolution</li> </ul> Memory and Allocators Untangling Lifetimes: The Arena Allocator</a> — Ryan Fleury</li> Always Bump Downwards</a> — Nick Fitzgerald</li> Memory Allocation Strategies</a> — Bill Hall’s series</li> </ul> Error Handling Design The Error Model</a> — Joe Duffy on Midori’s approach</li> Error Handling in a Correctness-Critical Rust Project</a> — sled database</li> </ul> Formal Methods in Practice Proofs About Programs</a> — Hillel Wayne</li> Formal Methods Only Solve Half My Problems</a> — Marc Brooker at AWS</li> How AWS Uses Formal Methods</a> — Amazon’s TLA+ experience</li> </ul> Lean 4 Functional Programming in Lean</a> — official book</li> Theorem Proving in Lean 4</a> — official book</li> Metaprogramming in Lean 4</a> — macros and tactics</li> </ul> Type System Design Parse, Don’t Validate</a> — Alexis King</li> Names Are Not Type Safety</a> — Alexis King</li> Types as Axioms, or: Playing God with Static Types</a> — Alexis King</li> The Expression Problem</a> — Philip Wadler</li> </ul> Bob Harper Dynamic languages are static languages</a></li> Modules matter most</a></li> </ul> #</a>Talks</h3> Effects for Less</a> — Alexis King on effects (essential)</li> The Road to Zig 1.0</a> — Andrew Kelley</li> Is It Time to Rewrite the OS in Rust?</a> — Bryan Cantrill</li> Propositions as Types</a> — Philip Wadler</li> Correctness by Construction</a> — Derek Dreyer on RustBelt</li> Simple Made Easy</a> — Rich Hickey</li> Constraints Liberate, Liberties Constrain</a> — Runar Bjarnason</li> Growing a Language</a> — Guy Steele (watch this)</li> Why Algebraic Effects Matter</a> — Daan Leijen</li> Outperforming Imperative with Pure Functional Languages</a> — Richard Feldman</li> Why Roc?</a> — Richard Feldman</li> Preventing the Collapse of Civilization</a> — Jonathan Blow on why new languages matter</li> Ideas about a new programming language for games</a> — Jonathan Blow on Jai</li> Linear Types for Low-latency, High-throughput Systems</a> — Jean-Philippe Bernardy</li> seL4 and Formal Verification</a> — Gernot Heiser</li> </ul> #</a>Books</h3> Types and Programming Languages</a> — Pierce</li> Practical Foundations for Programming Languages</a> — Harper</li> Certified Programming with Dependent Types</a> — Chlipala</li> Software Foundations</a> — interactive Coq textbook</li> Programming Language Foundations in Agda</a> — Wadler and Kokke</li> The Little Typer</a> — Friedman and Christiansen</li> Crafting Interpreters</a> — Bob Nystrom</li> </ul> The Death of the Inner Self 2025-12-23T00:00:00+00:00 The core argument is simple: many features of human life that appear stable and natural are historically produced. As society accelerates, a number of these features begin to lose their function and their permanence. I believe consciousness as we know it is one of them. #</a>Individuality as technology</h2> Life is organized around information that replicates under constraint. Computation generalizes this biological logic. It allows selection and optimization to occur faster and at larger scales by externalizing memory, comparison, and feedback. Problems that once required internal deliberation can be solved through external processes that test, filter, and iterate possibilities. Capital pushes this logic further. It reorganizes social life around continuous feedback, price signals, and competitive selection. As these forces compound, individuality starts to look less like a foundation and more like an interface that emerged to solve earlier coordination problems. Capital behaves as an impersonal intelligence oriented toward speed, abstraction, and self-optimization. As cognition, decision-making, and coordination migrate into automated systems, the inner self loses its structural role. Over time, many assumptions we take for granted are worn down by this acceleration. Individuality and consciousness appear increasingly exposed to this process. #</a>The construction we cannot see</h2> Fish do not realize they live in water. The medium that sustains them is so constant that it disappears from perception. Some of the most important structures are overlooked for the same reason. Individuality and consciousness belong to that category. We tend to treat individuality and consciousness as self-evident facts, as if humans have always experienced themselves as bounded selves with an inner voice, a private mental space, and a continuous narrative identity. Because this experience feels natural, it is assumed to be timeless. However, for most of human history people did not describe themselves as individuals in the modern sense. Decisions were not understood as outcomes of inner deliberation, and agency was not located inside a private interior self. Action was organized through rituals, traditions, kinship, and prescribed roles. Meaning arrived from outside the person rather than from introspection. In many societies outside the Western trajectory, this structure remains largely intact. The idea of a you inside your head observing your own thoughts is therefore a learned construction. It depends on language, habits, metaphors, and social practices that had to be developed and stabilized over time. Inner speech, narrative memory, moral self-examination, and the sense of authorship over action emerged as cultural achievements layered on top of older biological processes. Modern societies actively reproduce this configuration. From early childhood, people are trained to understand themselves as autonomous units with opinions, preferences, goals, and an inner life that belongs only to them. The training is so pervasive that it becomes invisible. Other ways of being human recede from view, even though many have existed and some still persist. #</a>The weakening of the conditions</h2> The conditions that once made individuality functional are weakening. Earlier systems relied on human subjects to think, decide, judge, and take responsibility. Cognition and coordination were constrained by human minds. Individuality emerged as a solution: a stable self enabled long-term planning, moral accounting, and institutional continuity. Earlier societies coordinated without modern consciousness. Contemporary systems increasingly coordinate without modern selves. Decision-making proceeds without inner deliberation. Meaning is delivered through incentives, metrics, and feedback loops. At the cultural level, individuality remains constantly invoked. People are urged to be themselves, express themselves, optimize themselves. Yet the channels for expression arrive pre-shaped, quantified, and monetized. What appears as selfhood increasingly takes the form of managed performance within narrow bounds. #</a>Replacement by degrees</h2> The modern self does not collapse in a single moment. It is replaced function by function, each substitution small enough to go unnoticed. Taste was once formed through a slow, private process: encountering things by accident, sitting with discomfort, learning to love what initially resisted you. Algorithmic recommendation compresses this into a profile that updates in real time. The system knows what you will like before you do. The inner process of forming a preference, the hesitation, the revision, the gradual shaping of sensibility, loses its purpose when an external system performs it faster and with better accuracy. What remains looks like taste but functions as consumption. Judgment follows a similar path. In organizations that once depended on accumulated experience, performance metrics now determine what counts as competent work. The slow formation of professional intuition, the kind that takes years to develop and resists easy articulation, gets flattened against quarterly targets. When the metric becomes the institution’s memory of what the work is for, the judgment it was meant to approximate quietly disappears. People still show up. They optimize what is measured. The rest erodes. Inner deliberation faces the same pressure from a different direction. When an AI assistant can draft your emails, plan your week, summarize your reading, and suggest your next decision, the internal process of thinking through a problem starts to feel unnecessary. Not wrong, just slow. The assistant is not forcing you to stop thinking. It is making thinking feel like friction in a system that rewards speed. Over time, the habit of sustained internal reflection weakens for the same reason any unused capacity weakens: through disuse. Each of these substitutions is individually reasonable. Each solves a real problem. Taken together, they describe a pattern where the functions that once required a self are gradually absorbed by systems that do not. #</a>What is at stake</h2> The modern self once felt inevitable because it solved concrete problems. It enabled abstraction, continuity, and responsibility at scale. Its future usefulness is far less certain. The self depends on performing certain functions, and when those functions migrate outward, the self weakens not through suppression but through redundancy. The question is not whether individuality was real. It was. It produced philosophy, law, science, art, and institutions that reshaped the world. The question is whether it will remain functional as the systems around it absorb more of what it used to do. A coordination technology that no longer coordinates does not persist on sentimentality alone. None of this means the self will vanish. It means the conditions under which it developed are changing, and what comes next may look different enough that the word “individuality” stops pointing at anything recognizable. Whether that transition is a loss, a transformation, or simply the next phase of the same process that produced the self in the first place is not something that can be settled in advance. But it should be named clearly, because what cannot be seen clearly cannot be preserved deliberately. Notes on permanence, time, and ergodicity 2025-12-15T00:00:00+00:00 Ergodic Group</a> is built around a basic observation: some systems improve the longer you stay with them. Repetition sharpens execution, experience carries forward, and judgment builds on itself. At Hermès, a leather worker trains for two years before touching a bag. One artisan makes one bag start to finish, every stitch by hand, fifteen to twenty-four hours of work per piece. This is the opposite of speed at all costs. It is also one of the most successful luxury companies in the world. The constraint is not overhead. It is what the customer is paying for. The broader culture moves in the other direction. Cycles shorten. Signals multiply. Decision horizons shrink. A lot of institutions keep moving while quietly losing the judgment they once had. They stay busy, but they stop getting better. Copying outruns learning. In that environment, endurance tells you something. If a system keeps working under stress for a long time, its structure probably matches reality better than its competitors’. The internet did not flatten everything. It made it easier to see who had substance and who was living off distribution. #</a>Two forms of time</h2> Time operates in human systems in two fundamentally different ways. Measured time is divisible and uniform: schedules, deadlines, accounting periods, discount rates. It can be allocated, optimized, and exchanged. Most planning systems live here. They assume value can be judged apart from history. Lived time works differently. It accumulates. Learning, memory, and judgment develop through it, and each cycle changes the next one. Anything that depends on formation happens here. Snapshots miss the point because the value is in what compounds. In 2001, Boeing moved its headquarters from Seattle to Chicago. The stated reason was to position the company closer to “Wall Street and governments.” Engineers who understood the planes were physically separated from executives who understood the spreadsheets. Over the next two decades, Boeing spent $41.5 billion on stock buybacks while cutting capital expenditure to half of Airbus’s rate. Harry Stonecipher, who took over as CEO, said he wanted Boeing “run like a business rather than a great engineering firm.” The 737 MAX, designed to avoid the cost of pilot retraining, killed 346 people. This is what happens when lived time is forced into measured time. Berkshire Hathaway made the opposite bet. Buffett has refused quarterly earnings guidance since 1996. Shareholders are told to judge the business over decades, not quarters. The result is six decades of compounding judgment, the longest sustained record in American corporate history. Same markets, different use of time. When lived time gets forced into measured time, formation breaks down. Standards do not settle. Judgment does not compound. You only find out what a system really is if you leave it alone long enough to show you. #</a>Formation under constraint</h2> Excellence comes from sustained practice under the right constraints. Errors have to be survivable. People need room to adjust without every bad iteration becoming fatal. Judgment improves when experience carries over from one attempt to the next. At Pixar, every film is terrible for years before it is good. Ed Catmull describes the process as taking movies “from suck to not-suck.” The mechanism is the Braintrust: a group of fellow directors and storytellers who meet every few months to review each film in production. The key detail is that the Braintrust has no authority. The director is not required to take a single suggestion. That keeps candor high without turning feedback into bureaucracy. Most studios kill projects after one bad screening. Pixar treats bad screenings as information, not verdicts. The difference is not talent. It is structure. Formation takes time, and the Braintrust protects that time by separating honest feedback from the power to cancel. #</a>Four domains</h2> Ergodic Group works across four domains: mathematics, code, culture, and craft. Most companies live mostly in one of them. The edge comes from connecting them. Mathematics sets the structure and the constraints. Code turns that structure into action and tests it against reality. Culture lets intent survive changes in personnel. Craft brings the whole thing back to materials, tolerances, and physical consequences. SpaceX shows how these domains work on each other. The math: a technique called lossless convexification lets an onboard computer solve fuel-optimal landing trajectories in real time, computing the exact moment to fire the engines so velocity hits zero at touchdown. The code: autonomous guidance software recomputes trajectories during descent, adjusting for wind and sensor readings, which makes landings on ocean platforms possible. The culture: failures are instrumented, not hidden. Between 2013 and 2016, SpaceX crashed booster after booster, and each crash produced telemetry that led to a specific fix. Hydraulic fluid ran out, so they added more. A throttle valve stuck, so they redesigned it. The craft: when carbon fiber layup produced wrinkles at roughly $200 per kilogram, SpaceX switched Starship to stainless steel at roughly $3 per kilogram. Steel gets stronger at cryogenic temperatures, handles far more heat, and opened reentry profiles that carbon fiber could not. A materials decision changed the vehicle, the software, and the math. The point is not that these domains coexist. It is that learning compounds when they stay connected. #</a>Ergodicity as a filter</h2> Ergodicity describes a situation where repetition improves the usual outcome because learning carries over from one round to the next. Claude Shannon spent fifteen years at Bell Labs before publishing “A Mathematical Theory of Communication” in 1948. He was not being graded on quarterly output. Bell Labs gave researchers something modern organizations rarely give anyone: enough uninterrupted time to get to the bottom of a problem. That setup produced the transistor, information theory, Unix, the laser, and cellular telephony. The transistor did not come from a brainstorm. It came from people with different specialties working near each other for years. When AT&T was broken up in 1984, that model disappeared with it. No later technology company has reproduced the same output. The institution itself held the judgment, and that judgment did not survive disassembly. As acceleration intensifies, most sectors get noisier and more fragile. Coordination gets harder. Institutional memory thins out. Advantages that looked durable turn out to depend on a few people, a few habits, or a distribution edge that disappears. Infrastructure and culture last longer because they are not just products to be sold. They are environments people operate inside. When learning carries forward, time starts working in your favor. #</a>Operation</h2> In 1984, GM and Toyota opened a joint factory in Fremont, California called NUMMI. Toyota sent over four hundred trainers from Japan for months of side-by-side work with American employees. Absenteeism dropped from twenty percent to two percent. Defect rates fell to the lowest in the United States. GM tried to export the lessons. A vice president told employees to “take a picture of every square inch” of NUMMI and replicate it at other plants. It failed everywhere. The visible process looked the same. The results did not. The missing piece was judgment, and judgment does not travel well as a memo. Toyota had not built a checklist. It had built a way of working. Ergodic Group is built on what NUMMI proved and what GM missed. The value is not in the visible process. It is in the judgment that accumulates when people have time to learn, when the links between domains stay intact, and when repetition actually improves the work. The new financial backend of the world 2025-12-09T00:00:00+00:00 By Federico Carrone and Roberto Catalan Ethereum is emerging as a general purpose financial backend that reduces the cost and complexity of building financial services while improving their speed and security. For decades the internet accelerated communication but did not create a neutral system for defining ownership or enforcing obligations. Economic activity moved online without the accompanying machinery of rights, records, and jurisdiction. Ethereum fills this gap by embedding these functions in software and enforcing them through a distributed validator set. Markets depend on property rights, and property rights depend on reliable systems for recording ownership, supporting transfer, and enforcing obligations. Prices then communicate scarcity and preference, enabling coordination at scale. Technological progress has repeatedly lowered the cost of transmitting information and synchronizing action. Ethereum extends this pattern by lowering the cost of establishing and verifying ownership across borders. #</a>From internet native to global infrastructure</h2> Ethereum’s early innovation was the introduction of programmable digital assets with defined economic properties. Issuers could establish monetary rules, engineer scarcity, and integrate assets into applications. Before Ethereum, such experimentation required constructing a network and persuading others to secure it, a process limited to technically sophisticated groups. Ethereum replaced infrastructure duplication with shared security and a general purpose environment, turning issuance from a capital intensive undertaking into a software driven activity. The more consequential development has been the recognition that Ethereum can reconstruct traditional financial services in a form that is more transparent and less operationally burdensome. Financial institutions devote substantial resources to authorization, accounting, monitoring, dispute resolution, and reporting. Consumer interfaces sit atop complex internal systems designed to prevent error and misconduct. Ethereum substitutes a portion of this apparatus with a shared ledger, a programmable execution environment, and cryptographic enforcement. Administrative complexity is reduced because core functions are delegated to software rather than replicated within each institution. Ethereum reduces that burden by providing a shared ledger with real time updates, a programmable space for defining rules, and cryptographic enforcement. It does not remove institutions but changes which parts of the financial stack they must build themselves. Issuance becomes simpler, custody more secure, and administration less dependent on proprietary infrastructure. #</a>Software, trust and the reduction of friction</h2> Some economists describe transaction costs through three frictions: triangulation, transfer and trust. Triangulation concerns how economic actors identify each other and agree on terms. Transfer concerns how value moves between them. Trust concerns the enforcement of obligations. Traditional financial architecture manages these frictions through scale, proprietary systems, and coordination among intermediaries. Ethereum remove middlemen and therefore lowers the three frictions enumerated before. Open marketplaces support discovery of assets and prices. Digital value can settle globally within minutes without the layers of correspondent banking. Obligations can be executed automatically and verified publicly. These capabilities do not eliminate institutional functions but shift part of the work from organizations to software, reducing cost and operational risk. New entrants benefit immediately. They can rely on infrastructure maintained by thousands of engineers rather than building their own systems for settlement, custody, and enforcement. Business logic becomes code. Obligations can be automated. Settlement becomes immediate. Users retain custody. This expands the range of viable business models and allows firms to serve markets that incumbents consider too small or too complex. Having a single global ledger also changes operational dynamics. Many institutions operate multiple databases that require frequent reconciliation and remain vulnerable to error. Ethereum maintains a continuously updated and replicated record that cannot be amended retroactively. Redundancy and recoverability become default properties rather than costly internal functions. Security follows the same pattern. Instead of defending a central database, Ethereum distributes verification among many independent actors. Altering history requires coordination at scale and becomes prohibitively expensive. Confidence arises from system design rather than institutional promises. #</a>New financial services and global reach</h2> These features enable services that resemble established financial activities but operate with different cost structures. International transfers can use digital dollars rather than correspondent networks. Loans can enforce collateral rules in code. Local payment systems can interoperate without proprietary standards. Individuals in unstable economies can store value in digital instruments independent of local monetary fragility. Clearing, custody, reconciliation, monitoring, and enforcement shift from organizational processes into shared software. Companies can focus on product design and distribution rather than maintaining complex internal infrastructure. Scale is achieved by acquiring users, because infrastructure is shared. Value accrues to applications rather than to duplicated internal systems. The impact is most visible in markets with fragile financial systems. In economies with unstable currencies or slow payment networks, Ethereum provides immediate functional gains. In developed markets the benefits appear incremental but accumulate as more instruments and processes become programmable. #</a>Institutional transformation and long term dynamics</h2> Many financial instruments are heterogeneous. Corporate debt is a clear example. Terms differ by maturity, coupon, covenants, collateral, and risk. Trading depends on bilateral negotiation and intermediaries who maintain records and enforce obligations. Ethereum can represent these instruments digitally, track ownership, and execute terms automatically. Contracts retain their specificity, while administration becomes standardized and interoperable. The boundary between what firms must build and what software can enforce is moving. Regulation and legal systems remain central, but the institutions sitting on top of them look different when settlement, custody, and enforcement are handled by shared infrastructure instead of proprietary systems. Ethereum already functions as an alternative financial rail. Multiple independently developed clients, substantial real world usage, an active research community, and a commitment to openness and verification set it apart from other blockchain networks. #</a>Conclusion</h2> Ethereum converts core financial frictions into software functions, and that changes the economics of building and operating financial services. Institutions become lighter and more focused. Firms that adopt Ethereum early will operate at lower cost and gain a head start against competitors still running on legacy systems. Technological transitions begin in niches where incumbents do not meet demand. As systems mature, costs fall and broader adoption becomes feasible. Ethereum followed this path. It began with internet native communities, expanded across emerging markets where users lacked reliable financial tools, and is now positioned to upgrade mainstream markets by making financial companies easier to create and operate. Software is becoming the organizing principle of financial infrastructure. Ethereum makes that concrete. Regulation and institutional adaptation will shape how far it goes, but the economic incentives already point toward systems that are open, verifiable, and resilient. The missing institution of the Internet 2025-12-02T00:00:00+00:00 By Federico Carrone and Roberto Catalan Modern economic systems rest on two foundations: tools that expand productive capacity and institutions that define who controls their output. The internet transformed how information moves, but it did not reconstruct the institutional machinery that governs ownership and exchange. Digital economic life therefore expanded without a durable system of rights, enforcement, or jurisdiction. Blockchain networks, and Ethereum in particular, address this gap by embedding institutional functions in software and enforcing them through economic incentives and cryptographic verification. #</a>Technology, Culture and Institutional Design</h2> Humans build two kinds of things: tools that expand what individuals can do, and institutions that coordinate what groups can do together. Fire, agriculture, medicine and computing are tools. Property rights, contracts, markets and corporate structures are institutions. The two feed each other. Tools expand capacity, institutions channel it into collective action, and the combination compounds over time. #</a>Property Rights and Markets as Social Technologies</h2> People invest when they believe they will keep what they earn. Property rights give that assurance by specifying who owns what, who can use it, and who is excluded. Markets sit on top of these rights and coordinate production through prices. None of this is natural. It is all engineered through law and political settlement. Prices, money and contracts compress information about scarcity and risk so that strangers can trade without needing to trust each other or answer to a central planner. The global expansion of trade in the twentieth century ran on this machinery: neutral jurisdictions, corporate structures, and legal containers that let participants from different regulatory environments collaborate. Whatever you think of it, this infrastructure underwrote the international economic order of the late twentieth century. #</a>The Missing Architecture of Digital Ownership</h2> The internet lowered the cost of communication and commerce across borders, but it did not establish a neutral mechanism for defining and enforcing claims on digital assets. Offline, ownership is adjudicated by courts, enforced by states and geographically bounded. Online, in the absence of a global authority, ownership defaults to either national legal systems or to the platforms that mediate activity. Corporations filled this vacuum by providing infrastructure for identity, communication and exchange. They set terms of access, mediate transactions and retain discretionary control over assets generated within their systems. Users and firms may create content, build businesses and accumulate value, but their rights are contingent on the policies of the platform operator. The experience of Zynga illustrates this dynamic. The company developed a profitable games business on Facebook and briefly achieved a valuation exceeding that of Electronic Arts. Its fortunes deteriorated when Facebook revised its policies and altered its revenue share. Zynga owned its intellectual property and its infrastructure but not the environment on which its business model depended, a common position for firms built on platform economies. In digital markets, platforms function as de facto landlords. This is not an isolated case but a structural feature of platform centered economies: extensive participation paired with limited control. #</a>Ethereum as an Institutional Experiment</h2> Ethereum is a response to this institutional absence. It provides a mechanism for creating, transferring and enforcing digital assets without reliance on corporate or national intermediaries. The system operates as a verifiable computing environment in which rules are encoded in software and enforced collectively by a distributed network. Traditional computing systems require users to trust the operator. Ethereum distributes computation across thousands of machines that execute identical code and verify each other in a continuous process. Outputs are accepted when consensus is reached and misbehavior is economically penalized. Under these conditions, property rights and contractual commitments can be represented as digital objects whose enforcement does not depend on courts or discretionary authority. This architecture automates functions normally performed by institutions. Auditors repeat financial records to detect manipulation. Courts resolve disputes. Regulators impose compliance standards. These systems are essential but costly and slow. Ethereum replicates aspects of verification and enforcement at the system level using software, mathematics and economic incentives. The network is open to participation without authorization and resistant to censorship because no single entity can unilaterally block or rewrite transactions. These properties arise from the structure of the system rather than ideological intent. #</a>The Emergence of a Digital Financial System</h2> The first adopters of Ethereum were technologists experimenting with new mechanisms for ownership and coordination. Most of the culture and products were created for themselves. Over time, a broader range of actors began using the system for financial services. The most consequential development has been the rise of stablecoins, digital representations of fiat currency backed by real world assets. Their combined market capitalization exceeds three hundred billion dollars, with a majority circulating on Ethereum. Transaction volumes on blockchain networks now approach those processed by major payment systems. Stablecoins replicate core financial functions such as store of value and transfer of funds without geographic restrictions and with continuous settlement. Their programmability enabled the construction of lending protocols that allow users to lend and borrow assets with risk parameters enforced in software rather than through institutional mediation. These systems differ from traditional financial infrastructure. Participation is global rather than jurisdictional. Switching costs are low because services are built on interoperable standards. Exit is immediate. Risk is transparent though often misunderstood. Compare that to countries like Argentina, where interoperability between banks and fintech wallets, something as trivial as scanning a QR code, is still an ongoing regulatory battle. Incumbents try to use their market position to avoid being interoperable. On Ethereum, interoperability is structural. Individuals can receive payment, convert assets, provide liquidity and borrow collateralized funds within minutes from a mobile device. In legacy systems, similar transactions take days and incur high fees. Adoption reflects demand for neutral infrastructure in environments where intermediation is unreliable. #</a>Implications</h2> Several areas of financial activity are migrating to blockchain based systems, including remittances, trade finance and private credit. Others, such as corporate debt markets, remain fragmented and costly but exhibit characteristics that may make them suitable for digital reconstruction on top of Ethereum. Plenty can still go wrong. Regulatory uncertainty, operational risk and rough user experience all constrain adoption. Scaling throughput without giving up decentralization remains an open engineering problem. Software vulnerabilities and governance failures have already caused real losses and will cause more. Early evidence suggests that parts of financial intermediation can run at lower cost and with more transparency than existing systems. Whether that continues depends as much on how regulators and incumbents respond as on the technology itself. #</a>Artificial Intelligence and Coordination</h2> Artificial intelligence increases productive capacity by automating tasks but does not resolve questions of ownership, governance or compliance. Output may be generated more efficiently, but disputes over entitlement, liability and compensation persist. Artificial intelligence and blockchains, but in particular Ethereum, are the two biggest innovations in the decades to come. The two technologies solve concrete core primitives of humans: productivity gains and coordination. Artificial intelligence will make people more productive, but it will not eliminate the bureaucratic machinery required to verify and enforce outcomes. Ethereum introduces a technology that complements AI: a system where humans and autonomous agents can coordinate, trade, and settle disputes directly through code, without relying on institutions to prove that everyone followed the rules. #</a>Conclusion</h2> The internet lowered the cost of transmitting information but left digital ownership in the hands of whoever runs the platform. Ethereum reconstructs elements of property rights and contractual enforcement as public infrastructure encoded in software. It may end up as core infrastructure or it may remain a specialized tool. That depends on regulators, incumbents, and whether the engineering problems get solved. But it has already shown that financial coordination can run at a different cost structure, and that digital property can exist without a central administrator. The internet built an economy without institutions. Ethereum is an attempt to build them. Next 10 Years of Ethereum 2025-11-15T00:00:00+00:00 Ethereum's Native Rollup Roadmap with Justin Drake 2025-10-01T00:00:00+00:00 Crypto doctrine 2025-09-25T00:00:00+00:00 #</a>Crypto and the accelerated and chaotic 21st Century</h1> Crypto has been most useful where trust is weakest. In practice, it has found product-market fit in two places: In countries where inflation, capital controls, or censorship are ordinary constraints, crypto gives people and companies tools they actually need.</li> In internet-native communities, crypto provides a financial layer that lets people coordinate, speculate, and build markets at a scale the web did not support before.</li> </ul> People that don’t live in a developing country or that didn’t grow up with the internet have enormous difficulties understanding crypto because they don’t have skin in its game. They believe crypto doesn’t have any “real” use case or that is not serious enough. They are right. The thing is that we are living in a world that’s becoming more absurd. Memes do not only make you laugh anymore, memes are now winning elections. These use cases will grow with time and probably new ones will be found. The world is becoming more chaotic and more divided each day. Crypto benefits from that kind of environment because it reduces the number of places where trust has to be taken on faith. One of crypto’s prime advantages is that it kills many of the middlemen and allows us to coordinate even in the harshest environments. Trust assumptions fall because more of the system is enforced by incentives, compilers, distributed systems, and cryptography. That does not remove politics or disagreement. It just narrows the set of things people need to argue about. Most of us are internet natives. We grew up on IRC, 4chan, Reddit, Hacker News, Twitter, Bitcoin, and Ethereum, and we also have roots in unstable countries. We are the Fremen of crypto, raised in a harsh environment. We know what chaotic societies feel like from the inside, and we know what it takes to build inside them. At the same time, we are builders who like working at the frontier of engineering and scientific change. Open source and decentralization are not just philosophical preferences for crypto. They are practical conditions for the ecosystem to work. Building in the open, helping other people onboard, and creating systems larger than the original project are part of how crypto survives long term. This can look irrational if you assume the only goal is short-term extraction. It is more legible if you assume the goal is to help a new financial and coordination layer persist. Our main objective is to help these new internet highways get built in sustainable ways. Economic sustainability matters, but so do resilience, openness, and the ability to resist the usual drift toward centralization. Centralization is almost always easier in the short run. If pure money were the only objective, there would be simpler ways to make it. We treat money as a tool, not the final point. With or without money, you will find us building. “Top-down management leveraging command-and-control hierarchies are for the mahogany boardrooms of yesteryear. We are navigators, adventurers, and explorers of the future. We are married to the sea” - Yearn’s Blue Pill Zero-Knowledge Proofs and the Economics of Verification 2023-04-13T00:00:00+00:00 Scientific and engineering fields usually move in long stretches of incremental work. Then, every so often, a new tool or idea changes the constraints and the whole field jumps. Most of the time progress comes from thousands of small improvements made by researchers, engineers, and companies. But occasionally something arrives that changes what is practical, not just what is theoretically possible. The public usually notices breakthroughs in areas like aerospace, energy, or AI. Cryptography moves more quietly, even when the consequences are just as large. During the COVID years, the field made real progress, especially in zero-knowledge proofs and other primitives that make verification cheaper and privacy easier to preserve. The bet in this piece is that these advances will matter well beyond cryptography itself. One of the most important changes has been practical speed. Zero-knowledge proofs have existed since the 1980s, but for a long time they lived mostly in papers because the proving costs were too high for ordinary systems. Over the last decade, and especially in the last few years, that changed. Engineers pushed them much closer to real-world use. The financial system still depends on intermediaries: auditors, regulators, accountants, banks, and payment networks. That system works when the institutions inside it are trusted and the surrounding state has enough legitimacy to enforce the rules. Bitcoin introduced a different model: a permissionless monetary network where users can move value without asking an intermediary for access. In places where inflation, capital controls, or institutional weakness are part of daily life, that difference is not theoretical. It is immediate. As trust becomes more uneven, systems that can be independently verified become more attractive. That does not mean social trust disappears. It means more parts of the stack will be built so they rely on less of it. Bitcoin was designed primarily as a monetary asset and settlement network, so expressive computation on top of it has always been limited by design. Ethereum expanded that design space by allowing more complex programs, which is why lending, exchanges, and other financial applications grew there first. But blockchains still impose severe constraints. Computation is expensive, throughput is limited, and the cost of moving meaningful value is often too high. This is where zero-knowledge proofs and related distributed-systems primitives become useful. A zero-knowledge proof lets one party show that a computation was done correctly without revealing the underlying data and without forcing everyone else to rerun the computation. The crucial asymmetry is that proving is expensive, but verification is much cheaper. That is what makes the technique economically meaningful rather than just mathematically elegant. At the beginning it’s difficult to grasp, even for engineers, that this technology is possible. The mathematics behind it, until recently, seemed magical, and that’s why it was called moon math. Thanks to ZKPs, transferring money in systems similar to Bitcoin becomes cheaper and much faster because there is no need for every node to re-execute each transaction. In some architectures, one node can process all the transactions and prove them using ZKPs, while the rest simply verify them, saving valuable computing resources. Among other things, ZKPs enable creating a financial system that doesn’t depend on social trust like traditional finance and that doesn’t depend as much on re-executing algorithms as Bitcoin. Zero Knowledge Proofs facilitate the development of an entirely new range of applications that are executed and proven on a single computer outside the blockchain, with verification happening within Ethereum. The cost of verification is much lower than the cost of proving or executing the computation. Ethereum will evolve from a slow yet secure distributed mainframe, where execution time is shared among all users to run small programs, into a distributed computer that stores and verifies proofs generated externally from the blockchain. Blockchains are not the only systems that benefit from these primitives. As AI-generated content begins to overshadow human-generated content on the internet, ZKPs become useful for verifying that content came from a specific model, system, or approved pipeline. “Proof of humanity” systems are already using ZKPs to verify that a human is accessing specific resources. More broadly, some industries will face growing pressure to prove they are operating correctly rather than asking users to trust them. Online gaming, ad networks, and other opaque intermediaries are obvious candidates. Fully Homomorphic Encryption, a related primitive that enables computation on encrypted data without exposing it, will play a similar role wherever privacy constraints are binding. In the past decade, we have launched applications serving tens of millions of users. We are now focused on helping others build startups around these technologies where the technical advantage is real and the use case is concrete.