Financial conditions that act on Arc.
A reusable financial automation layer that turns persistent financial conditions into permissioned onchain actions built on Arc Mainnet, and designed for a post-quantum future.
- Protocol fee
- 0.05%
- on execution only
- Subscription
- None
- no setup fee
- Custody
- Yours
- revocable anytime
Condition → Permission → Action
One reusable shape underneath everything. Change what the condition watches or what the action does, and the rest of the machinery is unchanged.
Condition
A persistent financial state, stored on Arc and evaluated on-chain until it becomes true.
Permission
A bounded authority you grant in advance: one amount, one destination, revocable at any time.
Action
The single authorized thing that happens when the condition is met, as a real Arc transaction.
A condition, not a payment
You are not scheduling a transfer. You are describing a financial state, once, and binding it to an action that only runs when that state is reached.
- 01
Define
Describe a financial condition and the single action it may perform. It is stored on Arc, not on a server.
- 02
Monitor
The condition is evaluated against live Arc Mainnet state. The predicate is a view function on-chain, so nobody has to be trusted to report it honestly.
- 03
Trigger
When it becomes true the condition latches, so a value that simply stays past the threshold fires once, not once per poll.
- 04
Act
The authorized action executes as a real Arc Mainnet transaction, bounded by the permission you granted.
Balance Guard is the first condition type, not the product
upKEEP is a condition engine. A condition is a generic subject, operator and threshold, interpreted by a registered evaluator and bound to an action. Adding a new condition type means deploying one small view contract and registering it.
V1 enables one pair: balance below, transfer USDC. Dashed items are designed for, not built.
Evaluators are the extension point
An evaluator answers two questions: is this true, and has it recovered. It is a view function, so it cannot move money, write state or re-enter. That is what makes it safe to make it pluggable.
Actions deliberately are not
An action decides what upKEEP may do with your funds, so each new action type is added explicitly in the executor where it is auditable, rather than something an admin can register quietly.
Evaluated on-chain
Because the predicate is readable on-chain, the executor re-checks it in the same transaction that moves the funds. The off-chain monitor only decides when to ask, never whether the answer is yes.
upKEEP never holds your keys
You deploy a vault, fund it with the amount you are willing to automate, and name one destination and one ceiling. That is the entire permission. There is no unlimited approval anywhere in the system.
- Transfer a fixed USDC amount
- To one approved recipient
- Only when the condition is true
- Move any other amount
- Send anywhere else
- Touch funds outside the vault
- Act after you pause or revoke
Pause, resume or revoke at any time. Withdrawal always works, even while paused.
Designed for a post-quantum future
Authorization standards will change. upKEEP is built so that when they do, your financial conditions do not have to be rebuilt, they keep running under a new mechanism.
Authorization is a layer, not a hardcoded scheme
A condition is never coupled to a signature scheme. The mechanism that proves a caller may act sits behind an interface, so a new one is added rather than migrated to.
Staged migration, not a flag day
Old and new authorization mechanisms run side by side. You move your own vault when you choose; nobody is switched over beneath you, and an admin cannot do it for you.
The condition survives the change
Migrating keeps the condition's threshold, action, trigger history and funds exactly as they were. Only how it is authorized changes.
upKEEP implements no cryptography and makes no post-quantum security claim. This describes how authorization can be replaced, not what protects it today. Arc runs an SLH-DSA-SHA2-128s verification precompile on Mainnet; post-quantum transaction signing remains a future Arc milestone, so Arc accounts are not post-quantum secure today and upKEEP does not suggest otherwise.
The same three slots, different financial workflows
Conditional treasury automation is not a new idea. What upKEEP packages is the condition itself as reusable infrastructure — one shape that extends beyond balance monitoring, with the engine underneath unchanged.
Treasury automation
The Balance Guard flow, running today.
Agent budgets
Same condition and action types. Only the values differ, so this needs no new code.
Automated payouts
The opposite direction, running on the same deployed evaluator. A catalog entry, not a second contract.
Spending controls
Needs a spend-rate evaluator and a pause action. Neither is built.
Three of these run on the engine as it exists today, on one deployed evaluator: the second needs only different values, the third only the opposite operator. The last is designed for, not built, and the product marks it that way everywhere it appears.
Developers can build on it too
The deepest kind of reuse is not one team running more workflows — it is other teams not having to rebuild the monitoring and execution layer at all. upKEEP ships as a TypeScript SDK, and this dashboard is simply its first consumer.
The SDK is written, tested and in use — every condition on this site is created through it. You can import it from the repository now.
Published to npm, so any Arc builder can npm install @upkeep/sdk and bind their own conditions to their own actions.
The dashboard is a reference implementation
upKEEP ships as a TypeScript SDK over the contracts. This site uses exactly the same client any other Arc application would - there is no private path around it.
One call to create a condition
Amounts are strings or bigints of native wei. A JS number is rejected, because it cannot represent every USDC amount exactly.
Arc's gas floor handled for you
Arc silently drops transactions under 20 Gwei with no receipt and no error. Every SDK write clamps to the documented floor so that never happens to you.
import { createUpkeepClient } from '@upkeep/sdk';
const upkeep = createUpkeepClient({
addresses,
walletClient,
});
const condition = await upkeep.conditions.create({
wallet: treasury,
type: 'BALANCE_BELOW',
asset: 'USDC',
threshold: '5000',
vault,
action: {
type: 'TRANSFER_USDC',
amount: '1000',
recipient: reserveWallet,
},
});
// -> { conditionId, transactionHash, explorerUrl }Set a condition once. Stop watching the balance.
Start with a small amount on Arc Mainnet and watch a real condition fire a real transaction.
Reusable automation · Permissioned execution · Post-quantum-ready architecture · Built for Arc Mainnet