We engineer custom smart-contract mechanisms for onchain products — from economic specifications to executable code and formal proofs of agreed properties.
A CONNECTED ENGINEERING SYSTEMRULES / RUNTIME / PROOFS
THE CHALLENGE
Some economic mechanisms demand more than standard contract templates.
Custom allocation rules. Novel payment logic. New market designs. The hard questions go beyond implementation bugs.
YOUR MECHANISM
Incentives
Does the incentive model hold?
Payments
Do payments match allocations?
Edge cases
Are exceptional states handled?
Execution
Does the runtime implement the rules?
THE SYSTEM
One mechanism. Three connected artifacts.
Economic rules, executable implementation and agreed proof obligations. Developed together, from the start.
VERIFICATION COVERS EXPLICITLY SPECIFIED PROPERTIES UNDER DOCUMENTED ASSUMPTIONS WITHIN A DEFINED EXECUTION MODEL. YOUR TEAM OWNS THE APPLICATION, INTERFACE AND DISTRIBUTION.
OUR APPROACH
From economic intent to executed reality.
We formalize the intended rules, implement the contract core and verify explicitly defined properties against a specified execution model.
Define economic properties, behavioral assumptions and mechanism constraints.
Economic intent → explicit rules and assumptions.
Current formal boundary: structured Yul AST → pinned EVM-frame model. Verification covers explicitly specified properties under documented assumptions within this execution model. It does not establish universal economic correctness, complete security, arbitrary deployed-bytecode correctness or end-to-end EVM correctness. Engineers own the meaning of the specification.
EXPLORE A MECHANISM
See how rules become a system.
Adjust a simplified auction. Follow the connection between economic parameters, contract structure and verification goals.
Explore the case’s outcome rule using two integer bids. This interface is a JavaScript illustration, not execution of the verified runtime or a new proof check. The core calculates no deposits, refunds or ETH transfers.
Illustrative outcome calculation in integer units, not ETH deposits. Ties go to participant 0, including 0 / 0. Winner pays min(b0, b1); loser pays zero. No funds move. Not a new proof run.
Research Case assumptions & boundaries +
Exactly two participants, one item, no reserve. Accepted runtime bids satisfy 0 ≤ bid < 2^128 (340282366920938463463374607431768211456 is excluded). The mathematical model assumes nonnegative private values, quasilinear utility and externally enforced payment and item transfer. DSIC concerns unilateral deviations, not collusion or a full protocol. This JavaScript illustration is not the 157-byte EVM runtime. That recorded runtime guarantee permits OutOfGas and starts from a specified fresh ABI frame with sufficient logical interpreter fuel; a successful gas bound is not proven. There is no deposit, refund or escrow operation in this research core.
We’re developing a proof-oriented engineering workflow for custom EVM mechanisms. Start with ML-VIC-001: a recorded verification result for a two-participant Vickrey auction.
ML-VIC-001 / FEATURED RESEARCH CASE
Vickrey Auction. A precise result. A precise boundary.
Two participants. The higher bid wins; the winner pays the lower bid. Follow the saved verification record from the auction rules to its exact 157-byte runtime.
Recorded verification — not an independent audit. The runtime guarantee permits a correct encoded result or OutOfGas from a specified fresh ABI frame; a successful gas bound is not proven.
Frame verified — preliminary internal result reported in the pitch.
Execution model
Reported workflow boundary: structured Yul AST to a pinned EVM-frame model. Exact model version requires CTO confirmation.
Proof dependencies
31 previous theorems reused in the reserve-auction proof, as reported in the pitch. Theorem identifiers and dependency graph were not supplied.
Known limitations
Preliminary internal result from the supplied pitch; not independently audited. Property statements, assumptions, pinned model version and artifact hashes were not supplied. No universal economic correctness or full security claim.
Stateful ETH escrow
Reported component coverage: storage, CALL and compilation certificate.
697 bytes
Components verified
Full protocol theorem not yet reported as complete.
Components verified — preliminary internal result reported in the pitch.
Known limitations
Component coverage does not establish a complete stateful protocol proof. Full protocol theorem not yet reported as complete. Exact properties, assumptions, model profile, runtime artifact and assembly details require CTO confirmation.
31
previous theorems reused in the reserve-auction proof
ML-VIC-001 has a saved verification record; the reserve and escrow metrics remain preliminary internal results from the pitch. The 31 reused theorems belong to the reserve-auction proof, not ML-VIC-001. No independent audit is claimed. Full protocol theorem not yet reported as complete. The supplied Vickrey evidence is available on its case page. No complete deployed-protocol proof is claimed.
APPLICATIONS
Different protocols. Different rules.
One engineering discipline. We focus on the custom economic logic that makes a protocol distinct.
MATURITY LABELS REFER TO THE STATED RESEARCH SCOPE, NOT PRODUCTION READINESS. COMPLEX STATEFUL MECHANISMS REQUIRE ADDITIONAL READINESS AND VERIFICATION WORK.
ENGINEERING DIFFERENTLY
Correctness should be designed in.
We develop specification, implementation and proof obligations as connected parts of one engineering process.
SEPARATE ACTIVITIES
Design→Implement→Review
THE MEKs Lab APPROACH
Specify↔Implement↔Verify
Rules, implementation and checks evolve together.
Formal verification establishes selected properties under documented assumptions. It complements testing and independent security audits.
WHO WE BUILD FOR
For teams building what doesn’t exist in a library.
We’re looking to collaborate with EVM teams developing custom economic mechanisms — particularly in allocation, auctions and settlement.
Protocol foundersCTOs & engineering leadsWeb3 product teamsDevelopment studiosResearch teams
EARLY COLLABORATIONS
Building the next mechanism?
Tell us what you’re building. We’ll explore whether MEKs Lab is a fit for your mechanism.
We start with a technical fit discussion. Where appropriate, the next step is a bounded discovery engagement covering requirements, feasibility and verification goals.