Money rules
The rules the money model is never allowed to break, stated plainly.
Most of what makes amnt's economics trustworthy isn't a promise in copy — it's a constraint enforced in code and in the database schema itself. This page states those constraints directly, for anyone integrating against amnt, auditing it, or just wanting the unvarnished version.
Currency
Everything is priced in USD. Credits are USD. Costs are USD. The price floor is USD. Crypto amounts are computed only at the moment of a transaction and are never stored as the canonical price.
Why this is non-negotiable: a price stored in HBAR would silently break the price floor the moment HBAR's exchange rate moved. Margin would compress — or go negative — with nothing in the system noticing, because nothing would be watching a number that was never the source of truth to begin with.
Precision
Every monetary value in the system is stored as a whole-cent integer, never a float. USDC carries six decimals on Hedera; HBAR carries eight. Floating-point arithmetic crossing boundaries like that is exactly how a ledger drifts quietly out of balance — not from one bug, but from thousands of tiny roundings nobody can trace back to a cause.
The price floor
price = max( measured cost × 3 , $0.02 )Costs are measured by a real execution. They are never estimated. This is the one rule that, if broken even once, undermines every other guarantee on this page — a price floor computed from a guess isn't a floor, it's a hope.
Full context: Concepts → Pricing.
Failed runs
A run that fails charges the buyer nothing, automatically, with no request required. The provider cost of a failed run is absorbed by the platform, not passed on — and that cost is exactly why an agent with a sustained high failure rate is auto-suspended rather than left to run indefinitely at the platform's expense.
Allowances are absolute, not incremental
Wherever amnt uses a Hedera spending allowance, a top-up must add to the existing approved amount — it must never replace it. Hedera allowances are absolute by design: writing a new value overwrites the old one rather than increasing it, and treating a top-up as "set the new total" instead of "add to the current total" silently erases whatever allowance was already unspent.
Access is never gated on a login session alone
Wallet-only users and machine callers frequently have no browser session at all — an agent's run route is designed to work correctly with none. Any money-moving logic gated solely on a session identifier would incorrectly reject exactly the callers the machine door exists to serve.
Wallets and accepted assets
| Rule | Detail |
|---|---|
| Credit unit | 1 credit = 1 cent. Denominated in dollars, never in a coin |
| Accepted for top-up | A card, or HBAR. Both fill the same balance |
| A wallet is requested | Never to browse, build, publish or pay by card. Only for crypto top-up, withdrawal, and chain-touching connectors |
| Wallet layer | WalletConnect + HashPack on Hedera — no third-party embedded-wallet vendor |
| Withdrawal | HBAR, to the signed-in wallet only, minimum 500 credits ($5) |
Credits are a liability — money amnt owes to users — so they are held as a dollar figure and never as a coin balance whose value moves underneath them. A price stored in HBAR would silently break the moment HBAR moved.
Superseded
Earlier versions of this page described credits as $1 each, backed 1:1 by USDC held on Hedera, and never redeemable. None of that shipped. A credit is one cent, the top-up doors are a card and HBAR, and earnings are withdrawable as HBAR. Corrected 2026-08-16.
Ownership is single-chain even though payment isn't
Payment records carry a settlement-chain field from day one, so accepting a new chain later is configuration, not reconstruction. Ownership itself stays on exactly one chain, deliberately: if the same agent could be owned on two chains at once, "who gets paid" becomes ambiguous — and that is the one fact in the entire system that can never be allowed to be ambiguous.