Setpoint

Live app: https://setpoint-neon.vercel.app

Social Account: https://x.com/setpointxyz
Architecture: https://github.com/karagozemin/setpoint/blob/main/docs/ARCHITECTURE.md

SETPOINT — SAFETY AND EXECUTION ORCHESTRATION FOR ONCHAIN VAULT REBALANCES

WHAT IS SETPOINT?

Setpoint is a safety and execution orchestration layer that turns a vault’s target portfolio into transactions that can safely execute under current onchain conditions.

A vault manager may already know exactly what allocation they want to reach.

The hard part is execution.

Liquidity changes.

Quotes expire.

Balances move after every confirmed transaction.

One leg can succeed while another fails.

Residual exposure has to be recalculated.

Trade sizing that works in deep liquidity can fail in a thinner market.

And every intermediate vault state still has to respect the vault’s own accounting, policy and risk constraints.

Setpoint sits between portfolio policy and swap execution.

It reads the confirmed vault state, target allocation, oracle data, current liquidity and vault-specific constraints, then answers one question:

What can safely execute now?

Its operating principle is simple:

Don’t optimize what isn’t broken.

Don’t execute what cannot be proven safe.

HOW SETPOINT WORKS

For every rebalance, Setpoint starts from confirmed onchain state.

It then:

1. validates the requested portfolio policy and target weights;

2. checks authoritative price freshness;

3. reads current liquidity and executable routes;

4. constructs the simplest coherent full rebalance;

5. preflights the plan against vault and liquidity constraints;

6. exact-simulates the real vault calldata;

7. returns a typed execution decision;

8. rechecks state immediately before signing;

9. submits only an authorized plan;

10. waits for confirmation and re-reads the resulting state before planning again.

Every analysis ends in one of three explicit outcomes.

FAST_PATH

The complete rebalance passes policy, liquidity and exact-vault simulation checks.

Setpoint does not add unnecessary complexity when the simple execution already works.

The full rebalance can proceed.

ADAPTIVE_FALLBACK

The complete rebalance cannot safely execute because of an explicitly recoverable execution or liquidity constraint.

Instead of forcing the original batch or abandoning the rebalance entirely, Setpoint searches for a smaller executable set of trades that can still make safe, provable progress toward the target.

That adaptive plan must independently pass the same liquidity, policy and exact-simulation gates before it can be signed.

NO_TRADE

If prices are stale, policy is invalid, routes are unsupported, liquidity evidence is insufficient, simulation fails for an unknown reason, or execution cannot satisfy the configured constraints, Setpoint refuses to trade.

Failing closed is part of the product.

WHY THIS PROBLEM MATTERS

Most execution infrastructure is very good at answering a single-swap question:

How should I execute this trade?

A portfolio rebalance asks a different question:

How do I move an entire vault from its current state toward a target state while the state itself changes during execution?

A multi-asset rebalance may involve several dependent trades.

After the first transaction confirms, the portfolio is no longer the portfolio that existed when the original plan was calculated.

Balances are different.

Liquidity may be different.

Quotes may be stale.

The remaining portfolio delta is different.

Setpoint treats those state transitions as first-class execution constraints instead of assuming that a list of independently generated swaps remains valid from start to finish.

REAL ONCHAIN EXECUTION — NOT A STATIC DEMO

Setpoint is deployed on Robinhood Chain Testnet.

The public application contains a real wallet-owned execution environment.

A user can:

• connect an injected wallet;

• create their own onchain Setpoint vault;

• receive a bounded testnet portfolio;

• inspect confirmed portfolio state;

• define and store a new target allocation onchain;

• analyze the rebalance against current deployed-pool liquidity;

• receive a FAST_PATH, ADAPTIVE_FALLBACK or NO_TRADE decision;

• exact-simulate the actual rebalance calldata;

• sign the transaction through their own wallet;

• wait for onchain confirmation;

• and inspect the confirmed post-execution portfolio.

These are real testnet transactions.

They are not simulated interface events.

The connected wallet controls the vault it creates.

The browser does not hold or receive the user’s private key.

Setpoint does not bypass vault authorization or onchain execution guards.

REAL EXECUTION EVIDENCE

The final acceptance flow was executed against the deployed Setpoint contracts on Robinhood Chain Testnet.

A real wallet:

• created an onchain vault;

• stored a new target allocation;

• read current liquidity;

• constructed the rebalance;

• exact-simulated the vault call;

• submitted the real transaction;

• waited for confirmation;

• and re-read the resulting portfolio state.

The accepted four-leg FAST_PATH reduced confirmed portfolio drift from:

45.00% → approximately 0.028%

The resulting state was read from the chain after confirmation rather than inferred from the execution plan.

The deployment record contains the Setpoint factory, oracle, swap adapter, sandbox assets, liquidity pools, user vaults, deployment transactions and accepted rebalance transactions.

WHY ROBINHOOD CHAIN

Setpoint’s initial wedge is multi-asset and tokenized-asset vaults.

These systems do not only need a good individual swap.

They need to move an entire portfolio toward target weights while preserving accounting, policy and execution constraints across multiple state changes.

That makes Robinhood Chain a natural environment for Setpoint.

Tokenized assets introduce portfolio-management and rebalance workflows where the gap between:

“this is the allocation I want”

and

“these are the transactions that can safely execute now”

becomes especially visible.

Setpoint’s first external benchmark used the real rebalance interface of an existing Robinhood Chain testnet index vault.

EXTERNAL ROBINHOOD CHAIN COMPATIBILITY

The application also includes live compatibility and monitoring for several independent Robinhood Chain vault architectures:

• Vimen Agentic MAG7

• HISS Vault V2

• Fides Frontier

• RWA Index

• MAG7 Index Vault

• Wield RWA Vault

These integrations demonstrate that Setpoint can reason about different vault architectures without pretending they all expose the same accounting or authority model.

Each adapter preserves the protocol’s native:

• holdings and accounting model;

• oracle state;

• execution policy;

• authorization rules;

• rebalance constraints;

• and available capabilities.

These projects are independent technical integrations and compatibility surfaces.

They are not presented as Setpoint customers, partners or endorsements.

BUILT THROUGH REAL USER RESEARCH

Setpoint did not begin with the architecture shown today.

The initial hypothesis was cross-portfolio netting:

match opposing rebalance flows between vaults internally, then route only the remaining exposure to external liquidity.

Before building deeply around that architecture, I discussed the idea with Arbitrum mentors including Swagtimus, Ben Greenberg and Jess.

Their feedback pushed me to stop adding architecture and validate the painful workflow first.

I then spoke with people closer to real vault, liquidity and execution systems, including Gauntlet, CoW contributors, 0x Developer Support, a Robinhood Chain index-vault builder and other operators.

Those conversations challenged the original hypothesis.

Different vaults rebalance on different schedules.

Opposing portfolio flows are not guaranteed to exist.

Waiting for another intent can create additional execution risk instead of removing it.

The more consistent signal appeared elsewhere:

the difficult part is safely turning an intended portfolio state into executable actions while liquidity and vault state are changing underneath the rebalance.

One vault builder specifically described static per-leg sizing as too conservative when liquidity is deep and too aggressive when liquidity is thin.

That feedback directly influenced Setpoint’s adaptive execution work.

Other feedback emphasized that intermediate vault states must remain priceable and that the remaining portfolio delta should be recomputed after confirmed execution rather than treating a multi-step rebalance as an opaque atomic assumption.

That research shaped Setpoint’s current product boundary:

portfolio policy stays with the vault or manager;

swap execution stays with the execution venue;

Setpoint orchestrates the safety-critical path between them.

LIVE LIQUIDITY, NOT HISTORICAL DEMO DATA

Setpoint does not use historical benchmark artifacts to make live execution decisions.

In the Setpoint Sandbox, executable quotes come from real deployed constant-product pools with finite reserves.

The live execution adapter reads current reserves, samples available liquidity and converts those observations into state-bound solver inputs.

Setpoint then:

• constructs a candidate plan;

• checks the relevant vault and policy constraints;

• exact-simulates the actual vault call;

• and verifies that the observed state is still valid before execution.

If confirmed state changes, the previous plan is discarded.

After successful execution, Setpoint reads the confirmed state again before making any further decision.

Historical fork and security evidence remain available separately in the Evidence section.

They never substitute for current chain state in the live execution path.

WHY THE HYBRID MODEL EXISTS

Setpoint deliberately does not run a complex adaptive solver on every rebalance.

The simplest coherent execution is attempted first.

If it is safe and executable, Setpoint uses it.

Only when that complete rebalance fails for an explicitly recoverable execution or liquidity reason does Setpoint activate adaptive execution.

This creates a simple rule:

FAST_PATH when simple execution works.

ADAPTIVE_FALLBACK when safe progress is still possible.

NO_TRADE when it is not.

Setpoint does not optimize merely for the sake of producing a more complicated plan.

STATE-BOUND EXECUTION

A rebalance plan is valid only for the state from which it was produced.

Before execution, Setpoint binds analysis to observed chain state.

Immediately before signing, it rechecks the relevant state and repeats account-specific exact simulation.

After transaction confirmation, the previous plan is considered consumed.

Setpoint re-reads confirmed balances and portfolio state rather than treating predicted state as reality.

This prevents a stale analysis from silently becoming an execution instruction after the underlying vault or liquidity environment has changed.

SAFETY MODEL

Setpoint is designed to fail closed.

Execution is blocked when:

• authoritative prices are stale;

• target policy is invalid;

• an asset or route is unsupported;

• current liquidity cannot satisfy the configured execution floor;

• the candidate does not improve the portfolio correctly;

• the configured NAV-loss bound would be violated;

• exact vault simulation fails;

• execution authorization is missing;

• or the observed state has changed since analysis.

Adaptive fallback is not activated by arbitrary errors.

Only explicitly classified recoverable execution failures can enter the fallback path.

Unknown failures stop execution.

SECURITY AND FAILURE EVIDENCE

The repository includes dedicated failure demonstrations for:

• stale prices;

• invalid portfolio policy;

• unsupported routes;

• unsafe residual liquidity;

• and unknown execution reverts.

The documented security suite currently holds:

11 / 11 security invariants

These include guarantees that:

• stale prices cannot produce executable plans;

• invalid policy cannot execute;

• unsupported routes cannot execute;

• unknown reverts cannot activate adaptive fallback;

• failed full plans are never submitted;

• adaptive plans require exact simulation;

• unsafe residual execution is refused;

• confirmed state is re-read;

• prior plans are invalidated after state changes;

• UI presentation cannot override execution policy;

• and authorization remains enforced by the underlying execution environment.

PUBLIC SANDBOX HARDENING

The public Setpoint Sandbox also includes protections specifically designed to keep the hackathon execution environment usable.

These include:

• one seeded vault per wallet;

• a bounded global seeded-vault budget;

• shared testnet liquidity sized against that maximum budget;

• immutable sandbox reference prices;

• permissionless timestamp renewal;

• and an automated oracle heartbeat.

Permissionless oracle refresh can renew only approved reference timestamps.

It cannot choose or manipulate the underlying reference prices.

If oracle freshness is genuinely lost, Setpoint still fails closed with STALE_PRICE.

The sandbox assets are test-only and have no production value.

TECHNICAL ARCHITECTURE

Setpoint deliberately separates four planes.

1. DECISION CORE

Chain-independent logic for:

• policy validation;

• baseline rebalance construction;

• liquidity-aware sizing;

• adaptive execution;

• hybrid mode selection;

• and typed execution evidence.

2. SETPOINT EXECUTION ENVIRONMENT

Solidity contracts for:

• wallet-owned vaults;

• target allocations;

• sandbox assets;

• oracle references;

• finite-liquidity pools;

• restricted swap routing;

• vault-level execution guards;

• and real onchain rebalance execution.

3. LIVE INTEGRATION LAYER

Protocol-specific adapters that read current Robinhood Chain vault state while preserving each protocol’s own accounting and authorization model.

Setpoint does not fabricate a universal execution interface when one does not exist.

4. HISTORICAL EVIDENCE LAYER

Versioned fork, benchmark and security evidence used to reproduce previous solver behavior and failure cases.

This layer is isolated from live execution.

Historical evidence cannot become live trading input.

NO HIDDEN SECOND PLANNER

The frontend does not independently calculate rebalance decisions.

The UI does not choose whether a result is FAST_PATH, ADAPTIVE_FALLBACK or NO_TRADE.

Those decisions come from the execution core.

This keeps presentation logic separate from the safety-critical decision boundary.

CURRENT VALIDATION

The final release has passed:

• 99 / 99 TypeScript tests

• 14 / 14 Foundry smart-contract tests

• fuzz testing

• 11 / 11 documented security invariants

• live external-integration smoke tests

• sandbox deployment and bytecode verification

• oracle freshness checks

• liquidity and route smoke tests

• production build validation

• real-wallet Robinhood Chain Testnet end-to-end execution

• desktop and mobile production checks

The accepted baseline planner remained frozen during the final product-hardening stage rather than being tuned simply to produce favorable demo outcomes.

Architecture:

https://github.com/karagozemin/setpoint/blob/main/docs/ARCHITECTURE.md

WHAT SETPOINT IS — AND WHAT IT IS NOT

Setpoint is not:

• a DEX;

• a custody layer;

• an investment strategy;

• a replacement for vault accounting;

• a promise of globally optimal execution;

• or a system that forces every rebalance to complete.

Setpoint is the orchestration layer that asks a narrower question:

Given this vault’s confirmed state, intended portfolio policy, current liquidity and execution constraints — what can safely execute now?

If the complete rebalance is safe, execute it simply.

If the full batch breaks but smaller progress can still be proven safe, adapt.

If neither is safe, refuse the trade.

THAT IS SETPOINT

policy → live state → safe execution

Rebalance the vault, not the risk.

Setpoint changed significantly during the hackathon.

The initial product hypothesis was cross-portfolio netting: match opposing rebalance flows between vaults internally, then route only the remaining exposure to external liquidity.

Before committing deeply to that architecture, I shared the idea with Arbitrum mentors including Swagtimus, Ben Greenberg and Jess. Their feedback pushed me to validate a narrower user problem before adding more architecture.

I then spoke with people across vault management, liquidity and execution, including Gauntlet, CoW contributors, 0x Developer Support, a Robinhood Chain index-vault builder and other operators.

That research challenged the original hypothesis.

Vaults rebalance on different cadences, opposing portfolio flows do not reliably arrive at the same time, and waiting for another intent can introduce additional execution risk.

Cross-portfolio netting therefore stopped being the core product.

The conversations instead surfaced recurring execution problems:

• liquidity can change between legs

• quotes can become stale

• one transaction can succeed while another fails

• residual portfolio exposure must be recomputed

• static trade sizing can be too conservative in deep liquidity and too aggressive in thin liquidity

• intermediate vault states still need to remain valid and priceable

The research also produced useful negative validation. One liquidity operator told me that ordinary portfolio rebalancing had rarely been painful for them, while LP range management was a much clearer operational pain point. That helped me avoid treating every type of rebalance as the same problem.

The stronger wedge became much narrower:

safety and execution orchestration between vault policy and swap execution.

I then benchmarked the solver against the rebalance interface of an existing Robinhood Chain testnet index vault instead of developing only against synthetic examples.

The implementation evolved through several stages.

1. Reproduced the external vault rebalance flow on a fork and built a deterministic baseline planner.

2. Added constraint-aware sizing and adaptive execution logic.

3. Introduced the hybrid execution model used today:

try the simplest complete rebalance first;

activate adaptive execution only after an explicitly recoverable failure;

otherwise fail closed.

4. Added security and failure evidence for stale prices, invalid targets, unsupported routes, unsafe liquidity and unknown reverts.

5. Replaced the original evidence-oriented interface with a live product that reads current chain state.

6. Added live monitoring and compatibility adapters for several independent Robinhood Chain vault architectures.

7. Built and deployed Setpoint’s own Robinhood Chain Testnet execution environment with:

• wallet-owned vaults

• onchain target allocations

• timestamped oracle references

• finite-liquidity constant-product pools

• route-restricted swap execution

• exact vault simulation

• confirmed-state re-reading after execution

8. Completed full real-wallet end-to-end executions on Robinhood Chain Testnet.

In the latest acceptance flow, a real four-leg rebalance reduced confirmed allocation drift from:

45.00% → approximately 0.028%

9. Performed a final product and security acceptance review.

That review identified two public-demo availability risks:

• shared-liquidity griefing

• manual oracle upkeep

Both were addressed before submission through:

• a bounded global sandbox seed budget

• substantially deeper shared testnet liquidity

• immutable sandbox reference prices

• permissionless timestamp renewal

• an automated oracle heartbeat

The final validation suite passes:

• 99/99 TypeScript tests

• 14/14 Foundry contract tests with fuzz coverage

• 11/11 documented security invariants

• live integration smoke tests

• sandbox deployment and bytecode checks

• real Robinhood Chain Testnet end-to-end execution

The accepted core solver remained frozen during the final product-hardening phase rather than being tuned to produce favorable demo outcomes.

The biggest change during the hackathon was not another feature.

It was killing the original hypothesis after user research, narrowing the problem, and moving from a fork-based solver prototype into a real onchain product with verifiable execution.

Not yet, It's created with this open house