Building a Prop AMM with Claude

As we approach the age of superhuman coding agents, it is becoming increasingly clear that the majority of mechanism design and smart contract work will be done in a collaborative loop between humans and LLMs (featured as prediction 18 in my 2026 predictions). In the interest of pulling forward this prediction a few months, I will walk through how a high context person can design a Prop AMM with Opus 4.5, where it excels, and where it falls short.

Defining Prop AMMs

In the world of traditional finance, the majority of price discovery happens on order books. They allow the market to aggregate preferences for buying and selling using both price and time priority. Historically, these have been sufficient to express pricing preferences. However, onchain systems have highly constrained execution environments, meaning they can get outcompeted on two dimensions:

• Traditional order books are expensive to iterate over. Updating a simple price array is cheap and can be evaluated at time of swap.
• After a user swap, Prop AMMs can update custom callbacks to move around liquidity based on available information or state onchain.

In general, we can compare the designs across a few dimensions.

Given this set of tradeoffs and no upstream player forcing standardization onto the market makers, Prop AMMs have broadly outcompeted order books on Solana. Now most of the competition is between various Prop AMM designs making the design loop for these systems increasingly important.

Building a Toy Prop AMM

The simplest possible Prop AMM is one that provides liquidity linearly between two values on opposite sides of the order book.

In our example, given a fair value for SOL of $200, a liquidity provider offers linear liquidity from 194-199 and 201-206. On the offer side of the book the trader is providing 10 SOL of liquidity and on the bid side they are providing 2000 USDC.

You can quickly observe some properties of this system. The SOL is being offered at an average price of 203.5 so it would take 2035 USDC to clear the offer. How do we compute the marginal swap?

class BookSide(BaseModel):
    quantity: float
    lower_price: float
    upper_price: float

    @property
    def liquidity_per_price_unit(self) -> float:
        return self.quantity / (self.upper_price - self.lower_price)

    def buy_exact_in(self, notional: float) -> float:
        quantity_bought = self.liquidity_per_price_unit * (math.sqrt(self.lower_price
            ** 2 + 2 * notional / self.liquidity_per_price_unit) - self.lower_price)
        self.lower_price += quantity_bought / self.liquidity_per_price_unit
        self.quantity -= quantity_bought
        return quantity_bought

    def buy_exact_out(self, quantity: float) -> float:
        notional_bought = quantity * self.lower_price + quantity ** 2 / (2 * self
            .liquidity_per_price_unit)
        self.lower_price += quantity / self.liquidity_per_price_unit
        self.quantity -= quantity
        return notional_bought

A More General Liquidity Curve

The toy model above uses a single linear range for each side of the book. A natural extension is to use multiple price points, creating a piecewise linear curve that can approximate more complex liquidity distributions.

I worked with Opus to design a more general liquidity curve that has 7 points per side of the book. This system also improves on the previous design by using the quantity from a swap to replenish liquidity on the other side of the book. These small improvements make for a reasonably flexible Prop AMM that a sophisticated market maker could use to compete onchain.

Next, I used Claude Code to mock this program, deploy it on mainnet, and build a simple GUI to test it with real money. You can see it below. The source code is available here. This took roughly 6-8 hours with Claude Code, and a significant amount of custom instruction around Solana contract development, but I wrote zero lines of the code myself (this exercise greatly increased my desire to use a high-quality AI auditor). The program has 150 CU oracle updates, which is within range of state of the art.

Axes of Improvement

There are three axes on which to improve the Prop AMM architecture.

• Off-chain fair value generation and quoting logic
• Parameterization of the liquidity curve
• Post-fill callback logic

The majority of the work on these systems falls under the first bullet point. Much more computation can be done off-chain. Also, it is much easier to update a trading system than a smart contract. However, there is still a meaningful amount of improvement to squeeze out of the other two axes.

To test Claude's ability to come up with novel designs, I gave it some light guidance and then asked it to mock up some potential improvements. You can see three of them explained below. They are not terrible but they are not above the level of a competent market maker. The key to improving this process in the future is to add a verification loop where the model can validate its ideas.

Conclusion

The loop of designing, deploying, and iterating on a Prop AMM with Claude Code is imperfect but about 10x more efficient than it was 12 months ago.

Strengths

• The model is able to fill in the details of high-level design ideas relatively consistently.
• The smart contract development and deployment loop requires minimal oversight.
• It is much easier to develop systems when the model spits out graphics to explain its thinking.
• Validating the system with real money is a high-quality reward signal.

Weaknesses

• There is no auditing loop here that gives me confidence in the correctness of the contract even with tests.
• The model is not as creative as I would like when thinking about novel designs.