Skip to content
Hightop docs header art
Hightop
Under the Hood

Why Onchain Enforcement Matters#

Most agent-finance products ask you to trust their software — whether that is a company's backend or a local program running on a machine. Hightop asks less.

You configure the rules in the app, but key money rules are enforced by open-source code that runs on a public blockchain. That means a buggy agent, a leaked API key, or a Hightop server issue still cannot silently widen the lane you approved.

Quick example: you set up a research agent with a $500 monthly budget, two approved vendors, and access to USDC only. If someone leaks that agent's API key, the attacker can spend up to $500 on those two vendors in USDC — and nothing more. They cannot add a third vendor, raise the cap, touch a different asset, or send funds to an outside address. Even if Hightop's own servers were compromised, those boundaries would still hold. The rules are not in a database someone can edit. They are in open-source smart contracts that run the same way every time, for every request.

That is the foundation of Hightop's trust model.

The Problem With Software-Enforced Rules#

Most platforms that manage money for AI agents enforce their rules in software. Sometimes that software runs on a company's server — a database says "this agent can spend up to $500 per day," and the server checks it before allowing an action. Other approaches store policies locally on the agent's machine as configuration files or embedded rules that software checks before signing a transaction.

Either way, the rules only hold as long as the software is intact.

AI agents make mistakes. They hallucinate. They misinterpret instructions, hit edge cases, and sometimes take actions their operators never intended. These are not hypothetical risks. They are the day-to-day reality of running autonomous agents.

On top of that, API keys can be leaked or compromised. This is especially common in newer agent frameworks where developers are experimenting, moving fast, and sometimes exposing credentials in logs, public repos, or poorly secured environments.

If the rules that protect your money live on a server, you are trusting that:

  • the server software has no bugs
  • the server has not been compromised
  • no one at the company has changed the rules
  • the database has not been corrupted
  • the platform will always enforce the limits it promised

If the rules live locally on a machine, you are trusting that:

  • the software has not been tampered with or replaced
  • no one has edited the policy files
  • spending counters and limits have not been reset
  • the machine itself has not been compromised

In both cases, there is no independent way to verify the rules will be honored. You cannot see inside the system. You cannot prove the policies are what they claim to be. Whether it is a company's server or software on a local machine, the rules are only as strong as the environment they run in.

And policies are only half the problem. Many platforms also hold the private keys to the wallets that store your funds — on their servers or encrypted on local disk. If that environment is compromised, the attacker does not need to bypass any policy. They have the keys. They can move every dollar out immediately, and no rule or limit will stop them.

How Hightop Protects Your Money#

Hightop's architecture separates the rules, the keys, and the safety mechanisms into independent layers. No single point of compromise gives an attacker full access.

The keys are not on Hightop's servers. Your account is anchored by a control wallet created through Turnkey as an embedded wallet, where access is tied to your email-based authentication — not stored on Hightop's infrastructure. A compromise of Hightop's servers alone does not give an attacker the keys to move your funds.

The control wallet does not bypass the control model. The control wallet still acts through the smart contract wallet — and the smart contract is what holds the policies and actually holds the funds. The control wallet cannot send funds to arbitrary new destinations or skip the delay for adding a new trusted destination. But if a trusted destination is already active, the control wallet can move funds there immediately.

You can upgrade control at any time. You can move control of your account to a wallet you fully control, such as a hardware wallet or a Safe (a multi-signature wallet that requires multiple approvals to act). That removes the email-based access path entirely and puts control under your own keys or signing authority.

A compromised control wallet does not mean instant, unrestricted damage. If the control wallet itself were compromised, the attacker could still try to change the rules. Some of the highest-risk paths are delayed: adding a new trusted destination requires a timelocked confirmation, new agents and recurring vendors only become active after their activation delay, and larger one-off payments can sit behind a review delay. When these delayed changes are initiated, Hightop will notify you through its available alerting channels so you can catch them and cancel before they take effect. But that delay protects the add path, not destinations that are already active. Small one-off payments can still clear within the rules already in force, and an already active trusted destination can be used immediately by the control wallet.

What Onchain Means in Practice#

When Hightop says key controls are "enforced onchain," it means the important money rules live in open-source smart contracts on a public blockchain — not just Hightop's private backend.

Think of it in three layers:

The rules live in smart contracts, not a private database. Smart contracts are programs deployed on a public blockchain. The code that checks agent limits, payment approvals, asset restrictions, and timing rules runs onchain. Once deployed, Hightop cannot quietly change it. The contracts execute the same way for every request, whether it comes from a legitimate agent, a compromised key, or a bad actor.

The code is open-source. Anyone can read it, review how it works, and verify that the rules do what they claim. This is not documentation that could be out of date — it is the actual code that runs when money moves.

Every action is recorded. The blockchain keeps a permanent record of every transaction. You can look up any action and confirm it was validated against the rules before it executed.

That is the difference between "we promise this limit is enforced" and "here is the code, and here is the proof that it ran."

What Gets Enforced Onchain#

Not every setting in the Hightop app lives onchain. Display preferences, notification settings, and other UI choices stay in the app. The boundaries that matter for protecting money are the ones that get enforced onchain.

Here is what that looks like for the controls you set in Hightop:

  • Agent permissions — your research agent can pay vendors but cannot touch Earn or Borrow. That boundary is enforced onchain, not just displayed in a dashboard.
  • Spending limits — the $500 monthly cap, the $100 per-transaction max, the $10,000 lifetime ceiling. All checked by the smart contracts before any money moves.
  • Asset restrictions — if you restrict an agent to USDC, it cannot swap into ETH or spend a different token, even if the agent's logic says it should.
  • Payment-path rules — which vendors are approved for recurring payments, what delays apply to one-off payments, and which destinations qualify for trusted transfers.
  • Timing controls — a one-off payment might have a 24-hour review window before the recipient can claim it. That delay is enforced onchain, not just a front-end timer. The same goes for activation delays, expiry windows, and cooldowns between actions.
  • Venue restrictions — which markets and integrations an agent can interact with.
  • Vault routing — which yield protocols are approved destinations for deposited funds.

The app is where you configure these rules. The blockchain is where they are enforced.

Why This Matters for AI Agent Workflows#

AI agents operate autonomously. Many run around the clock, making decisions and executing transactions without a human watching every step.

The gap between "the agent was told to stay within $1,000 per day" and "the system enforces $1,000 per day regardless of what the agent tries" is the entire trust model. The first is a suggestion. The second is a guarantee.

Consider three scenarios:

A leaked API key. Someone gains access to an agent's credentials — through a leaked environment variable, a public repo, or a vulnerability in a third-party framework. The attacker can use whatever permissions and limits you originally configured for that agent — but they cannot widen them. They cannot raise the spending cap, add new vendors, approve new assets, or transfer to unapproved destinations. The onchain rules do not care who is holding the key.

A rogue AI agent. An agent misinterprets its goal, hallucinates a valid reason to spend more, or hits a logic bug that causes it to loop. The spending limit is checked by an independent smart contract. The agent cannot talk its way past it. If the action exceeds the budget, it fails — every time.

A Hightop server issue. Hightop's servers go down, a deployment goes wrong, or internal infrastructure is compromised. The onchain control layer continues to exist and enforce rules independently. The contracts do not depend on Hightop's servers to validate actions.

In all three cases, the rules hold. That is the point.

How to Verify It Yourself#

You do not have to take Hightop's word for any of this.

Read the contracts. The smart contracts that power the control layer are open-source and published on GitHub. You can read the code and see exactly what checks run before any transaction executes.

Check the record. Every transaction that passes through the control layer is recorded on Base, a public blockchain. You can look up any action using a block explorer and confirm it was validated against the onchain rules.

Review the audits. The contracts have been independently audited — see Audits for the full reports.

You can inspect the code, confirm the rules, and verify transactions. The enforcement layer is public infrastructure, not a proprietary backend.

The smart contracts behind Hightop's control layer are part of the Underscore Protocol, which the Hightop team also built. The full source code is available on GitHub.

Delays and Timelocks Are Safety Features#

Some changes in Hightop do not take effect instantly. Adding a new trusted transfer destination requires a timelocked confirmation, new agents and recurring vendors only become active after their activation delay, and larger one-off payments can wait behind a review delay. Those delays create a response window — and that is when Hightop notifies you and you can cancel or intervene.

Even while a compromise is in progress, the existing onchain rules still apply. An attacker is still bound by the current agent limits, spending caps, asset restrictions, and payment-path rules for agent-driven actions. Small one-off payments below the instant threshold can still go through within the boundaries already configured. And if a trusted destination is already active, the control wallet can move funds there immediately. Some updates to existing rules can also take effect immediately, which is why the right claim is reduced damage, not zero instant risk.

Where to Go Next#

Previous

Borrowing Under the Hood

Next

FAQ