This is a submission for the DEV Weekend Challenge: Community
The Community
I built this for a community that rarely gets highlighted in “weekend project” conversations: developers maintaining open-source and trustless infrastructure that other systems depend on.
This includes people working on smart contracts, distributed backends, protocol libraries, and low-level tooling where mistakes are not cosmetic — they become permanent once deployed.
In these environments, the most expensive bugs are not UI bugs.
They are state transition bugs, rounding mistakes, unexpected bytecode drift, and deployments that cannot be reproduced later.
Open-source contributors in this space often receive donations, tips, or shared funding streams, but even something as simple as splitting ETH between multiple maintainers becomes surprisingly complex if you care about:
- deterministic execution
- exact conservation of value
- minimal gas overhead
- reproducible deployment
- verifiable runtime bytecode
This project started from that exact concern.
I wanted to build something small enough for a weekend, but serious enough to reflect how critical infrastructure is actually engineered.
That is how InvariantSplit started.
What I Built
I built InvariantSplit, a deterministic ETH settlement primitive for exactly three fixed recipients with weights 50% / 30% / 20%.
A typical use case is micro-endowments or donations for open-source contributors, where a single transfer must be split between multiple maintainers, and where unnecessary gas overhead or ambiguous rounding behavior makes the system harder to trust.
The project ships two implementations:
- a Solidity baseline for readability and semantic clarity
- a Huff implementation for bytecode-level control and reduced execution surface
It also ships two runtime profiles:
-
core— minimal settlement path -
observed— same semantics, but with execution metadata for public reconciliation
The key architectural idea is separation:
- Execution Plane — minimal deterministic settlement logic
- Assurance Plane — specification, testing, deterministic deployment, and public evidence
The settlement rule is explicit:
shareA = value * 5000 / 10000
shareB = value * 3000 / 10000
shareC = value - shareA - shareB
The last line is the real design decision.
Instead of computing three percentages independently and hoping the numbers reconcile, the contract computes the residual explicitly.
This guarantees conservation of value and defines a deterministic dust policy.
That kind of detail matters when code behaves like infrastructure rather than a demo.
Demo
Repository:
https://github.com/doomhammerhell/invariantsplit
Live Sepolia deployment:
Factory
https://sepolia.etherscan.io/address/0x8f9633c55d6EC8EF0426742460A4B374481D6c0C
SolidityObserved
https://sepolia.etherscan.io/address/0xc5068CA8448E5FAEd512eA4F734eE6f5b1b08f71
HuffObserved
https://sepolia.etherscan.io/address/0x43A2F08D802642BD30EbaDa4A509d5bbBCa0d2fC
Evidence bundle
Manifest
https://github.com/doomhammerhell/invariantsplit/blob/main/deployments/latest.json
Transactions
Solidity distribute
https://sepolia.etherscan.io/tx/0x9e16a013a5b99a9941d9e3688c28bd961a3d80a814dcdeac1fac83c6bb04c6c5
Huff distribute
https://sepolia.etherscan.io/tx/0x47be17dfef49b7dffb5695761de9fe90f0174b1fb59fb96ed02c9e700724a09d
How I Built It
Execution Plane vs Assurance Plane
The first design decision was to keep the execution path extremely small.
The runtime contract only:
- accepts ETH
- computes three shares
- sends in fixed order
- reverts atomically on failure
Everything else lives outside the hot path.
The assurance plane includes:
- formal invariants
- differential tests
- deterministic CREATE2 deployment
- runtime attestation
- signed manifests
- reproducible release artifacts
This is the same pattern used in constrained distributed systems:
keep execution simple, move proof out of band.
Why Huff
Solidity is the right default for most systems.
I used Huff because this problem is extremely constrained:
- fixed recipients
- fixed weights
- no storage mutation
- no loops
- no admin logic
- no upgradeability
When the domain is this small, low-level control reduces ambiguity.
At the EVM level the contract:
- rejects unknown selectors
- computes shares directly on stack
- performs three ordered CALLs
- reverts atomically
Every abstraction removed here reduces review surface.
The Solidity version remains for semantic clarity.
The Huff version exists to minimize execution shape.
Mathematical Invariants
The core invariant is conservation of value.
shareA = floor(v * 5000 / 10000)
shareB = floor(v * 3000 / 10000)
shareC = v - shareA - shareB
Therefore
shareA + shareB + shareC = v
The important part is the residual rule.
Dust is not left to emergent behavior.
It is assigned explicitly.
This makes the system predictable.
Differential Testing
Low-level code needs an oracle.
The Solidity version defines expected behavior.
Foundry tests compare:
- Solidity vs Huff
- core vs observed
- selector vs receive
- fuzzed values
Goal:
semantic equivalence
Not just passing tests.
Deterministic Deployment
Deployment uses CREATE2.
This allows:
- predicted addresses
- reproducible builds
- runtime verification
Each deployment produces:
- config hash
- artifact hash
- address map
- runtime hash
This makes the contract defensible outside the repo.
Runtime Attestation
Three layers of trust:
verification
attestation
provenance
Explorer verification is not enough for Huff.
Runtime bytecode must match local build.
Signed manifests describe the release.
Trust comes from evidence.
Benchmark
Bytecode size
Solidity runtime ~695 bytes
Huff runtime ~223 bytes
Gas
Solidity distribute ~111k
Huff distribute ~110k
The main win is not gas.
The main win is deterministic execution shape.
Why This Matters for the Community
Open source infrastructure depends on trust.
But trust is not only about code.
It is about:
- predictable execution
- reproducible deployment
- explicit invariants
- verifiable artifacts
Even a small primitive like a splitter benefits from discipline.
Weekend projects usually optimize for speed.
This one optimized for correctness.
Because that is what the community maintaining trustless systems actually needs.
What I Learned
Building low-level code in a weekend forces discipline.
Constraints help.
Fixed weights
fixed recipients
no storage
no upgradeability
Those constraints make reasoning possible.
The biggest lesson was that even tiny contracts benefit from:
- explicit invariants
- differential tests
- deterministic deployment
- reproducible artifacts
Small code can still require serious engineering.
Conclusion
InvariantSplit is intentionally small.
But it was built with the same mindset used in:
- distributed systems
- IIoT control paths
- cryptographic infrastructure
- trustless protocols
Minimal execution.
Explicit invariants.
Reproducible deployment.
Public evidence.
That is the kind of engineering discipline I think open-source infrastructure deserves — even in a weekend project.
Top comments (0)