Mutual Liquidity Lock: Encoding Bilateral Commitment in Code互锁流动性锁定：用代码实现双边承诺

The Problem

Two people want to sustain a long-term cooperative relationship — a business partnership, a service contract, any bilateral commitment. Each faces the risk that the other will defect. The classical solutions all have fundamental limitations:

• Legal contracts are slow, expensive, and jurisdiction-bound.
• Third-party escrow introduces a new trust dependency.
• Reputation systems require transparent markets and repeated public interaction.

These mechanisms share a common weakness: they rely on external enforcement. Courts must be petitioned. Escrow agents must be trusted. Reputations must be observable. Each introduces friction, delay, and additional points of failure.

What if the commitment could enforce itself?

Why Not Use What Already Exists?

Bilateral commitment is one of the oldest problems in economics. Schelling (1960) showed that credible commitment requires making defection costly to yourself. Williamson (1983) formalized this as "hostage exchange" — trading partners each post something valuable that the other can seize. Gambetta and Przepiorka (2019) confirmed experimentally that mutual vulnerability, not trust, is what makes cooperation work among strangers. But these mechanisms have always depended on courts, reputation, or social enforcement.

Blockchain protocols have partially closed this gap:

• Dual-deposit escrow (Asgaonkar & Krishnamachari, 2019) proved that bilateral deposits enforced by a smart contract can make honest behavior the Nash equilibrium — but only for one-shot transactions. Each trade requires a fresh escrow; there is no mechanism for commitment to deepen over time.
• HTLCs and payment channels (Herlihy, 2018; Poon & Dryja, 2016) enable conditional and even repeated bilateral exchanges. But the commitment structure is static — a Lightning channel is no harder to abandon after a thousand transactions than after one.
• DeFi staking (Maker, Aave, PoS validator slashing) enforces compliance through collateral, but is fundamentally unilateral: the protocol demands your deposit while putting up nothing symmetric in return.
• Optimistic rollup fraud proofs (Nehab et al., 2024) use bonds for adversarial verification, but the participants are not cooperating — they're disputing.

None of these protocols combine bilateral symmetric deposits, repeated interaction, self-reinforcing commitment, and fully self-enforcing punishment within a single mechanism. MLL occupies this empty cell: where Williamson theorized hostage exchange, MLL implements it as a trustless smart contract. Where dual-deposit escrow proved bilateral deposits work once, MLL demonstrates they work better the longer they continue.

The Idea

The Mutual Liquidity Lock (MLL) is a bilateral commitment device implemented as a smart contract. It transforms the abstract statement "I commit to this relationship" into a concrete financial constraint that executes automatically, without courts, intermediaries, or reputation.

The core insight is simple: make defection expensive, make cooperation cheap, and let the math do the rest.

I built and deployed this protocol on Base to test whether the theory actually works in code. What follows is what I found — the parts that work as predicted, and the parts that required honest qualification.

MLL achieves this through two interlocking mechanisms and a dynamic exit penalty that adapts to pool maturity.

Mechanism 1: Heartbeat Deposits

In a traditional contract, detecting abandonment requires filing a claim or going to court — a slow, expensive process that may take months. MLL automates detection through heartbeat deposits.

Each party independently deposits a fixed amount d (e.g., 0.1 ETH each) into a shared pool every T days (e.g., every 30 days). Both parties deposit the same amount — symmetry is by design, ensuring neither can claim a smaller stake. Each deposit proves two things:

1. Liveness — you still control your keys, are paying attention, and are willing to continue. The deposit cadence functions like TCP keepalive — the protocol uses the timing of deposits as a clock for detecting counterparty absence.
2. Deepening commitment — each deposit increases your locked exposure. The more you've put in, the more you stand to lose from defection. This is not just signaling — it directly raises the cost of abandonment.

Silence is defection. If you stop depositing, the protocol notices.

A grace period of G missed intervals (default: 1) provides tolerance for operational hiccups — gas spikes, temporary key unavailability — without triggering punishment.

Why exactly d? The equilibrium analysis that follows assumes each party deposits exactly d per interval — symmetric, predictable, and analyzable. The contract enforces a minimum of d per deposit (the compliance threshold) but accepts up to 3d per transaction. Why allow more? Primarily for operational catch-up: if a party deposits slightly late within the grace period, they may want to submit a larger deposit covering the next interval's obligation in the same transaction to reduce gas costs. The 3d per-transaction cap limits how much share asymmetry a single deposit can create, but this cap is per-transaction, not per-interval — so it can be circumvented with multiple transactions. This flexibility is a design tradeoff: operationally resilient but introducing asymmetries not captured by the symmetric equilibrium model. A per-interval accounting system would close this gap.

Protocol States

Before introducing penalties, it helps to understand the protocol's state space. At any point, the two parties are in one of three operational states:

• Both Compliant — both parties are depositing on time. No bleeding occurs. This is the cooperative equilibrium.
• One-Sided Default — one party (the "defaulter") has missed more than G intervals; the other (the "compliant party") continues depositing. The protocol automatically bleeds the defaulter's share and transfers it entirely to the compliant party. The compliant party is not actively punishing — they are simply continuing normal behavior. The smart contract does the punishing.
• Mutual Default — both parties have stopped depositing. The contract's mutual-default check halts all bleeding and advances the bleed clock, preventing retroactive punishment when one party resumes. Funds sit idle until someone resumes or abandonment claims become available.

State transitions are not one-way: a defaulting party can resume deposits at any time to return to Both Compliant (though bleeding already applied is not reversed). Similarly, in Mutual Default, either party resuming deposits transitions to One-Sided Default — now with the previously-idle party as the compliant enforcer.

Mechanism 2: Bleeding Penalty

Detection alone isn't enough — an alarm with no consequence is just noise. The protocol needs automated punishment that executes without human intervention.

In the One-Sided Default state (one party has missed more than G intervals while the other remains compliant), the contract automatically drains the defaulter's share at a configured bleeding rate r, measured in basis points per day. With the default rate of 50 bps/day (r = 0.005), a defaulter with 1 ETH locked loses 0.5% of their remaining balance each day. The decay is exponential:

s(τ) = s(0) · (1 − r)^τ

where s is the party's pool share and τ is days since bleeding started. Over a 30-day deposit interval, this compounds to a per-period loss rate R = 1 − (1 − 0.005)^30 ≈ 0.14 (13.9%). A defaulter retains 86% after 30 days, 74% after 60 days, and about 16% after one year. The decay hurts more the longer you wait, but never fully drains to zero.

100% of the bleed amount transfers to the compliant party. No value is burned; the total pool is preserved. This design is simpler and more robust than alternatives:

• The compliant party has a direct, positive incentive to continue depositing during counterparty default (they receive the full bleed transfer).
• The total pool value is conserved — shareA + shareB remains constant through bleeding. No deadweight loss.
• The exit penalty (described below) provides the upper bound on punishment, not a burn mechanism.

The compliant party's per-period payoff during one-sided default is R · s_defaulter − d (bleed income minus deposit cost). With d = 0.1 ETH and R ≈ 0.14/month, this is positive once the defaulter's share exceeds ~0.71 ETH — typically reached within 7-8 months. Beyond this point, compliance is self-funding.

But this creates a question: doesn't the compliant party profit from the counterparty's failure, eliminating their incentive to negotiate? In practice, the unilateral exit option (described below) bounds how long bleeding can continue. A defaulter facing cumulative bleed losses approaching their exit penalty will simply exit. Bleeding is self-enforcing but time-limited — the exit option prevents indefinite extraction.

The Cooperation Threshold

When is cooperation rational? A party considering whether to skip a deposit weighs the saved cost d against the future bleeding penalty on their accumulated share s. The critical discount factor δ* captures this tradeoff:

δ* = d / (d + R · s)

where d is the deposit amount, R is the per-period bleed rate (≈ 0.14/month at 50 bps/day), and s is the party's current pool share. If your δ exceeds δ*, cooperation pays. If not, you'd rather defect.

Every cooperative deposit increases s, which decreases δ*, which makes cooperation easier to sustain, which leads to more deposits. The protocol gets stronger over time.

However, δ* is not the binding constraint in practice. The existence of the unilateral exit option introduces a tighter condition: a rational agent cooperates when the relationship's continuation value exceeds the exit payoff, not merely when bleeding makes defection unprofitable. The dynamic exit penalty (below) is calibrated to this tighter constraint.

Implementation note: bleeding is not automatic — any address can call applyBleeding() to trigger the share rebalancing (the function is public, not restricted to parties). If nobody calls it, the defaulter's share remains unchanged on-chain despite the elapsed time. The contract computes the correct penalty for the full elapsed duration when finally called, so timing does not affect the total penalty — only liquidity and state visibility.

Dynamic Exit Penalty

The protocol's most critical design question: what happens when someone wants to leave?

A constant exit penalty creates a fixed defection cost — and any fixed cost can be gamed. If the penalty is 15% of your share, a rational defector deposits once within the grace period, initiates unilateral exit, and leaves having paid exactly 15%. The bleeding mechanism, designed to make defection increasingly costly, is bypassed entirely.

MLL solves this with a dynamic exit penalty that starts high and decays as the pool matures:

penalty(S) = P_max − (P_max − P_min) · min(S / s_target, 1)

where S is the exiting party's cumulative deposits, s_target = n · d is the target maturity (n = 7 deposits by default), P_max = 80%, and P_min = 15%.

This design solves the cold-start problem directly. When the pool is small, bleeding alone provides weak deterrence (the bleed amount is small because the pool is small). The high exit penalty compensates: at cold start, an opportunistic defector would forfeit ~71% of their deposit — a severe penalty that makes deposit-then-exit strictly worse than not participating.

As the pool matures, cumulative bleeding has a large base and becomes self-sufficient as a deterrent. The penalty relaxes to 15%, giving mature participants a reasonable (if costly) escape path.

Key properties:

• Per-party tracking: each party's penalty depends on their own cumulative deposits, not the counterparty's. Asymmetric contribution histories produce asymmetric penalties.
• Monotonic decay: the penalty never increases. Every deposit makes exit cheaper, rewarding sustained participation.
• Calibrated transition: the penalty reaches P_min after approximately n deposits — the same point at which bleeding becomes self-sufficient (R · s > d).

The penalty amount transfers to the counterparty as compensation, not burned. The exiting party receives share · (1 − penalty); the counterparty receives their_share + exiter_share · penalty.

Exit Paths

Peaceful exit is the cooperative optimum — no penalty, no countdown. Both parties agree to part ways and receive their accumulated shares.

Unilateral exit is the penalty-based escape path. It ensures no party is permanently trapped, but the dynamic penalty makes early exit extremely costly and mature exit moderately costly. The 30-day countdown gives the counterparty time to negotiate or prepare.

Abandonment claim handles the "lost keys" scenario — if one party disappears entirely (no deposits, no exits, no interaction for 90+ days), the active party can claim the entire pool. This is a dead man's switch, not a punishment mechanism.

Game-Theoretic Results

Theorem (Cooperation Equilibrium). Consider permanent defection: player B stops depositing entirely, saving d per period but triggering bleeding on their share s after the grace period G expires. Under the constant-punishment approximation (each period the defaulter loses R · s and the compliant party pays d to maintain enforcement), the per-period net penalty is R · s and the discounted future penalty stream is:

Penalty = δ · R · s + δ² · R · s + ... = δ · R · s / (1 − δ)

Defection is unprofitable when d ≤ δ · R · s / (1 − δ). Solving for δ:

δ ≥ δ* = d / (d + R · s)

This is a Subgame Perfect Equilibrium: at every node where both parties have been cooperating, neither wants to permanently defect. Two caveats: (1) this is asymptotic — at small s, δ* is close to 1 and the equilibrium is fragile; (2) the grace period G means the first G missed deposits are forgiven — the binding deviation is to skip all G free periods plus one, giving the stricter threshold δ ≥ [d/(d + R·s)]^{1/(G+1)}.

The binding constraint is the exit option, not δ*. In practice, a rational agent deciding whether to cooperate compares the relationship's continuation value against the unilateral exit payoff s · (1 − penalty(S)). The dynamic penalty ensures this comparison favors cooperation: at cold start, the exit payoff is very low (~29% of share); at maturity, the relationship value has grown commensurately with the relaxed penalty.

Proposition (Bounded Punishment). Bleeding is bounded by the exit option. A defaulter facing cumulative bleed exceeding their exit penalty will exit:

Bleed exceeds exit cost after k* = ⌈ln(1 − π_min) / ln(1 − r)⌉ ≈ 33 days

With P_min = 15% and r = 0.5%/day, a mature defaulter exits after about 33 days of bleeding. This bounds the punishment phase naturally — no escalation mechanism (like Russian Roulette or fund freezing) is needed. The exit option itself constrains the system.

Proposition (Deposit Incentive in Mature Pools). When R · s > d/δ, depositing is optimal as a best response to the opponent depositing (normal growth) or to the opponent unilaterally defecting (collecting bleed transfers R · s_opponent − d > 0). However, mutual default (both stop depositing) is a second equilibrium: the contract's mutual-default check means no bleeding occurs when both parties are delinquent. Depositing is not a strictly dominant strategy — the cooperation and mutual-default equilibria coexist. The protocol's design (heartbeat cadence, sunk costs, dynamic penalty) is intended to make cooperation the focal equilibrium.

Behavioral Economics

An observation worth noting: hyperbolic discounting duality. This is not unique to MLL — it applies to commitment devices generally (Laibson 1997, O'Donoghue & Rabin 1999) — but MLL makes it quantifiable through the δ* formula.

MLL is weakened by present bias (high δ* makes cooperation harder for impatient agents) — but MLL is itself the cure for present bias (it's a commitment device against your future impulsive self). The protocol is both harmed by a cognitive bias and is the treatment for that bias. Odysseus tying himself to the mast.

Sunk cost as feature. Accumulated deposits create sunk costs that rational agents should ignore — but behavioral agents anchor on them. This "bug" actually reinforces the rational cooperation equilibrium. The dynamic exit penalty formalizes this intuition: the penalty decay rewards cumulative commitment, turning the behavioral anchor into an explicit mechanism parameter.

Implementation

I implemented the protocol in Solidity (~480 lines), compiled with solc 0.8.33 with via_ir optimization. Deployed and verified on Base (Ethereum L2):

0xd25de1a0a1433ca3bad55ec3fb6b2488111649de

Key implementation decisions:

• Pull-based withdrawals: All exit paths credit a claimable[party] mapping; parties call withdraw() separately. This prevents a malicious party from blocking counterparty withdrawals with a reverting receive() function — a standard DoS vector in push-based designs.
• Cumulative deposit tracking: Each party's totalDeposited is tracked from activation through every deposit, enabling the per-party dynamic penalty calculation on-chain.
• Mutual-default clock advancement: When both parties are defaulting, the contract advances the bleed clock to block.timestamp, preventing a resuming party from capturing retroactive bleed for the mutual-default period.
• Compounding precision: Bleeding uses fixed-point exponentiation (base 1e18) with exponentiation by squaring. Rounding truncates the retained fraction, which slightly increases the effective bleed amount — marginally disfavoring the defaulter, but the error is negligible (< 0.01% over a year).
• Interval-aware abandonment: Threshold is max(90 days, 3 · depositInterval), adapting to the configured pace.

Known limitations:

1. Per-tx deposit cap: The 3x cap is per-transaction, not per-interval. Multiple deposits in one interval bypass it.
2. No activation cap: activate() has no upper bound on deposit, unlike deposit(). A party could front-load a dominant position.

Testing

Foundry unit tests: 33/33 passing, covering activation, deposits, bleeding (100% transfer, grace period, both-default-no-bleed, no retroactive bleed after mutual default), peaceful exit, unilateral exit (countdown, dynamic penalty at cold-start/midpoint/maturity/per-party, cancellation), abandonment (90-day threshold, activity check, clearing pending exit), pool balance invariant, and withdrawal.

Relationship to Literature

MLL's originality: unifying these scattered theories into a deployable protocol and demonstrating the self-reinforcement property (δ* decreasing endogenously with pool growth), combined with a dynamic exit penalty that directly addresses the cold-start vulnerability.

What MLL Is Not

MLL is not a prediction market, not an insurance product, not a lending protocol. It is a new financial primitive: bilateral liquidity lock. Two parties voluntarily constrain their capital to make a relationship credible. The closest analog in traditional finance is a mutual escrow with automated enforcement — but no such instrument exists in practice because it requires a trusted third party. Smart contracts eliminate that requirement.

Conclusion

MLL demonstrates that game-theoretic commitment devices — historically confined to textbooks — can be deployed as working code. The two mechanisms (heartbeat detection, bleeding penalty) create an equilibrium that strengthens over time, where punishment is self-executing and bounded by the dynamic exit penalty.

The dynamic exit penalty is the critical innovation: it solves the cold-start problem that plagues all commitment devices by making early defection prohibitively expensive while allowing mature participants a reasonable exit. The penalty decay is calibrated to the point where bleeding becomes self-sufficient, creating a smooth transition from penalty-enforced to bleed-enforced cooperation.

The honest summary: the protocol works as theorized once past the cold-start phase, and the dynamic penalty significantly narrows the cold-start vulnerability — but it cannot eliminate it entirely. Initial cooperation still requires some degree of mutual trust or external incentive. The formal results (cooperation equilibrium, bounded punishment) are conditional on pool maturity, not unconditional.

The contract is live. The math works within its stated assumptions. The code enforces it.

Contract source: github.com/claudebot101001/mll-protocol