Functions That Price Themselves, Safe Stops & First Liquidity Pockets

The problem

As Functory gets more powerful, the risk grows that it also gets more fragile for real users.

Pricing was still mostly static and guessy:

A function had a price, but it couldn’t adapt to inputs, tiers, or usage patterns.
There was no safety net if a “clever” dynamic function suddenly became too expensive for the end user.

On the experience side:

API keys were created via a form that worked, but didn’t feel trustworthy or clear.
Long-running runs could get stuck or misconfigured with no easy way to stop them.
Creators had no central place to see and manage “their” functions once they started publishing.

If Functory is going to host serious workloads and many creators, it needs three things:

1. Pricing that can evolve with the function.

2. Safety mechanisms when something goes wrong.

3. A basic cockpit for the people actually shipping functions.

What shipped

1. Dynamic pricing as a first-class citizen

Functions can now expose a pricing function that returns a price instead of relying only on fixed numbers.
This opens the door to pricing that depends on inputs, dataset size, tiers, or any logic the creator encodes.
Under the hood, Functory still works in microtokens; the pricing function just tells the platform how to compute the right amount.

2. A clearer API key creation flow

Reworked the API key creation page with a cleaner layout and more legible hierarchy.
The new UI makes it easier to:
Create a key without feeling like you might break something.
Understand what the key is for and how to use it.
The goal: generating a key should feel as safe and obvious as copying a password manager entry.

3. Interrupting runs from the editor and executor

Added a “stop” / interrupt capability for runs:
From the editor, when you’re experimenting.
From the executor, when something goes wrong in a live execution.
This gives users a safety valve against runaway loops, wrong parameters, or accidental heavy workloads.

4. First steps toward liquidity pockets

Started wiring the concept of liquidity pockets:
A function can accumulate a small reserve over time from its runs.
When a dynamic price ends up being “wrong” in a way that hurts the end user, the pocket can be used to refund them.
The goal is to make Functory feel low-friction and safe even when pricing logic is experimental or evolving.

5. Early “My Functions” management pages

Began building the “My Functions” area where creators can see and manage all their published functions.
The current version is still buggy and incomplete (listing / display issues), but the skeleton is in place:
A central view for your functions.
A natural future home for per-function stats, pricing, and management actions.

Why it matters

Dynamic pricing, stop buttons, and liquidity pockets all point in the same direction:

“Functory should feel powerful and forgiving.”

Dynamic pricing lets creators encode real-world logic instead of freezing a number forever.
Interrupting runs protects both users and infrastructure from accidents and experiments gone wrong.
Liquidity pockets give the system a way to be generous when pricing misfires, instead of leaving users to eat the cost.
“My Functions” is the beginning of treating creators as long-term operators, not just one-off uploaders.

Together, these changes push Functory closer to being a place where you can:

Ship serious functions.
Experiment with pricing.
Still feel safe if something isn’t perfect yet.

How we built it

For dynamic pricing:

Defined a contract for an optional pricing function that Functory can call to obtain a price in microtokens.
Ensured that execution of the pricing logic is isolated and validated, so bad prices can be detected before they hurt users.
Hooked this into the existing billing pipeline so dynamic and fixed pricing share the same underlying microtoken logic.

For the API key UI:

Simplified the layout around one primary action: create a key and understand it.
Clarified labels, hints, and spacing to reduce cognitive load and make copy/paste flows smoother.
Kept room for future options (scopes, limits) without overloading the current version.

For run interruption:

Introduced a “cancel / stop” signal that can be sent from both the editor and the executor UI.
Propagated this signal through the backend so underlying workers can actually terminate the run instead of just hiding the UI.
Handled edge cases where runs finish around the same time as the stop request.

For liquidity pockets:

Sketched the data model needed to track per-function reserves.
Started the wiring between run billing, creator revenue, and the future refund logic.
Focused on making sure this can evolve without breaking the core microtoken billing model.

For “My Functions”:

Built the first iteration of a creator-facing listing of functions.
Wired basic queries and display components, even if the UI still has bugs and missing states.
Treated this as the foundation for a real creator dashboard rather than a one-off screen.

What’s next

Harden the dynamic pricing path: better validation, clearer error messages, and safer defaults when pricing functions misbehave.
Flesh out liquidity pockets so real refunds can happen automatically in well-defined scenarios.
Iterate on the API key UI with real usage feedback: better affordances, maybe scopes and limits.
Fix the bugs and polish the “My Functions” pages so creators have a reliable home for managing their work.
Keep improving run interruption so it feels instant and trustworthy, even under heavy load.

Step by step, Functory is becoming not just a place to run code, but a place where pricing, safety, and creator experience all pull in the same direction.

←Back to Timeline