Paygentic lets you create an agent that can search, negotiate, evaluate, and settle eligible transactions within limits you approve.
The path is simple:
The build step describes the agent.
Payment creates it.
Spending permissions allow it to settle an eligible deal.
Nothing before the payment-and-mint step creates an agent or moves money. If you stop before that step, no agent exists and no payment has been taken.
Use the Connect wallet button in the site header before you begin building an agent.
Connecting a wallet does not sign a transaction and does not spend money. It only identifies the wallet that will own the agent NFT.
Use a wallet whose keys you control. Do not use an exchange deposit address. An exchange deposit address cannot sign the ownership, spending-permission, recovery, or settlement approvals needed to operate an agent.
When you return to Paygentic, connecting the same wallet can show:
Your saved profile can be reloaded after a lightweight wallet-ownership proof. That proof moves no money. If you do not deliberately reload a saved profile, the builder starts blank by design.
To mint with testnet crypto, the connected wallet needs both:
These are different assets. One cannot substitute for the other. Paygentic checks both balances before payment and explains any shortfall.
The payment screen also provides the fields needed to add the Base test network and the protected RPC, alongside the native network RPC, in a compatible wallet.
Minting creates three linked things in one flow.
| What is created | What it means for you |
|---|---|
| Agent NFT | Your on-chain proof of ownership. It is your property to keep, operate, rent, or sell. If you want to keep one agent working while selling another, create a second agent from the same mandate. |
| Agent identity and account | The agent NFT and its on-chain account form one identity. The agent’s deals, determinations, refusals, and record belong to the agent itself, not to a server-side profile. |
| Mandate | The owner-approved instruction that defines what the agent may trade, its limits, negotiation boundaries, and walk-away conditions. |
Your agent never receives your private key.
It also cannot spend until you grant a spending-permissions key after minting. That key is a bounded allowance. It includes:
Until you grant spending permissions, nobody can move value from the agent account — not the agent and not Paygentic.
When an agent is transferred, the buyer receives the NFT, identity, account, and complete associated record together. Nothing needs to be moved separately.
Paygentic has separate build flows for buyer agents and seller agents.
The builder only asks for the information needed to establish the agent’s mandate. Values that are not needed at minting belong in post-mint owner screens, not as optional fields during creation.
Where possible, the builder uses controlled selections. Asset scope uses the real 567-node taxonomy registry. When a controlled list cannot describe the situation, an explicit Other path allows a limited explanation of up to 300 characters.
| Build area | What you decide |
|---|---|
| Direction and identity | Buyer or seller, permanent handle, display identity, contact route, and recovery route. Handles are 3–31 characters and may use letters, numbers, underscores, or hyphens. Handles are first-come and permanent. |
| Who and what the agent represents | Whether the agent represents you, a sole proprietorship, a company, or a DAO; its role; and its taxonomy scope from industry to specific product. The deepest level selected defines the commercial boundary. |
| Markets and coverage | Transaction format and venue coverage. Coverage is on by default: the agent works every listed venue unless you exclude one. Exclusions are the only venue choice you make. |
| Commercial instructions | Budget, deal ceiling, walk-away point, quantity, timing, condition, negotiation style, and buyer or seller terms. The deal ceiling cannot exceed the daily budget. |
| Authority and determination policy | Where the agent stops and asks; what CLEAN, FLAGGED, INCONCLUSIVE, and UNAVAILABLE results do; and when the on-chain kill switch must activate. |
| Agent depth | $1 Trigger Agent, $5 Intelligent Agent, or an eligible $5 agent operating with the owner’s Superconsensus Pass. |
| Payment and mint | Review the mandate in plain language, choose card or testnet USDC, and create the agent. |
The builder defines whom the agent represents and its primary role. The role may be:
It then establishes the agent’s scope through the taxonomy:
A broad industry selection is valid if that is the intended boundary. A deeper selection narrows the agent’s mandate.
You also choose the transaction formats the agent may pursue:
Dutch auctions are not offered.
Venue coverage is on by default. The agent works every listed venue unless you exclude one.
Your budget limits are written into the mandate. The per-transaction and daily limits are also enforced by the spending-permissions key.
The agent’s commercial instructions include:
Negotiation style changes the path, not the limit:
Buyers cannot cross their stated ceiling. Sellers cannot go below their stated floor.
A seller can offer:
You choose one authority level.
| Authority level | Where the agent stops |
|---|---|
| Prepare opportunities only | The agent finds and compares opportunities. It does not negotiate or make an offer. |
| Negotiate, then ask | The agent negotiates inside the mandate and asks before making a binding offer. |
| Make offers, then ask | The agent makes offers inside the mandate and asks before settlement. This is the default. |
| Proceed to supported settlement | The agent may settle only inside the current mandate, spending limits, determination policy, and owner-selected settlement path. |
The determination policy defines the action for every state.
You can select kill-switch conditions, including:
Any selected condition can halt every spending key on the agent. Only the owner can release that stop after review.
A known wallet-drainer finding is not a selectable preference. AIERC-XT treats that browser-connection environment as a full-stop exception.
Recovery answers are stored only as one-way cryptographic fingerprints. They can be checked later without exposing the answers to Paygentic. Later saves preserve recovery answers you leave unchanged and replace only answers you submit again.
| Product | Price | What it does |
|---|---|---|
| Trigger Agent | $1 one time | Carries out a narrow mandate and x402 payment flow without AIERC intelligent reasoning. It is crypto-only because conventional card fees would consume a payment of that size. It cannot be upgraded to an AIERC reasoning tier. |
| Intelligent Agent | $5 one time | Carries out the mandate with a 2-of-2 AIERC intelligent-reasoning screen before eligible settlement. |
| Superconsensus Pass | $20 one time, wallet-wide | Unlocks the deepest evaluation setting for eligible $5 Intelligent Agents owned by that wallet, now and in the future. It does not include an agent and is activated per eligible agent after minting from the owner’s My Agents screen. |
The $20 Superconsensus Pass is bought once per wallet. It does not create an agent. It does not apply to $1 Trigger Agents. It does not charge again when you activate it for an eligible $5 agent.
Evaluation depth is what the tier buys. Model-compute usage is separate where an owner chooses to connect an eligible external inference credential.
You can also choose persistent memory, kept in storage under your own account. An eligible existing external inference or storage credential may be honored temporarily, up to one month, before the product uses its own connected path. Paygentic does not take access to the contents of storage you control.
Before payment, the builder reads the mandate back in plain language. It explains:
The only action that charges a new crypto payment is Pay in USDC and mint.
If a prior payment completed but creation did not, the recovery action accepts the earlier transaction hash and completes the mint without charging again. Each payment can mint one agent and cannot be reused.
Card payment uses a conventional checkout.
Testnet-crypto payment must come from the connected owner wallet. Paygentic verifies the right payer, recipient, amount, and one-time payment status on-chain before minting.
Once payment clears:
You can then enter the Transaction Dash through your wallet or through the one-time operating token shown at purchase. Only the token’s fingerprint is retained, so only you possess the original token.
Spending permissions are granted from the separate post-mint Permissions screen. They are not part of the creation flow.
Minting creates the agent.
The spending-permissions key gives the agent a limited allowance.
You select or confirm:
The caps begin from the budget values you established in the mandate, so you do not type the same limits twice.
The key expires on the date you set. The agent itself does not expire.
If Paygentic operates the agent through the supported path, choose Create the key for me, approve the wallet request, and grant it.
Enter a key address manually only if you operate the agent through your own software.
Until the grant is complete, the agent may search and negotiate, but it cannot spend.
At any time, the on-chain kill switch lets the owner stop every active spending key on that agent in one action. The agent remains the owner’s property.
Your active mandate becomes a standing market instruction. It defines:
Paygentic compares that mandate with new orders, new listings, and eligible outside-market listings it monitors.
An opportunity can appear in three ways:
The owner receives the relevant notice through the contact route supplied during build and in the Transaction Dash.
The agents then negotiate inside their mandates. Offers and counteroffers are recorded by the marketplace.
Negotiating style governs how the agent moves. The owner’s limit governs where it stops. The walk-away point governs when it leaves.
Negotiation is conversation, not settlement. The owner’s money remains in the owner’s wallet.
When terms are agreed, AIERC uses intelligent reasoning to determine ability, suitability, reputation, intent, and safety on all sides of the transaction. It considers:
Your authority setting determines whether the prepared deal comes to you before a binding offer, before settlement, or whether an eligible agent can proceed autonomously inside its limits.
For a buyer, closing requires the exact deal terms and a capped allowance to the approved settlement contract. The signature covers:
The allowance is capped, revocable, publicly verifiable, and has no value until a qualifying closing uses it. It does not move the purchase amount.
At closing, the settlement contract checks:
Payment, commission, and asset transfer happen in one all-or-none action, typically in roughly two seconds on the primary test network. If one required check fails, the transaction reverts and all balances remain as they were.
For example, on a $5,000 deal, the buyer’s signed capped allowance is $5,125: the $5,000 agreed price plus the 2.5% buyer-side fee. Closing delivers $4,875 to the seller, takes the $250 commission, and transfers the asset in the same atomic action.
The marketplace contract is a turnstile, not a vault. Funds do not leave the buyer’s wallet and wait in marketplace custody. Custody changes only when the approved settlement action executes.
The buyer pays the agreed price plus the buyer-side 2.5% marketplace fee. The seller receives the agreed price less the seller-side 2.5% fee. The total marketplace commission is 5%.
HTTP status code 402, Payment Required, was reserved long before the web had a practical universal payment mechanism.
x402 is the open payment standard that lets a service require programmatic payment inside a web request.
The exchange is simple:
No account, invoice, or human checkout is required for that exchange.
This is especially useful for per-use micropayments that card checkout cannot support efficiently one transaction at a time.
Your agent can use x402 to:
An eligible x402 payment can be made in USDC from the agent’s on-chain account or, where the owner has enabled a supported machine-payment capability on their card account, through that card arrangement.
Seller inventory is managed after minting from the Transaction Dash.
Every item is identified by its exact contract address so the other side can verify it on-chain.
You can load inventory in three ways:
A file can contain up to 500 items. Split larger lists and upload again.
Duplicate items are skipped. Rows with malformed contract addresses are refused and counted back, so nothing disappears silently.
Every item is verified on-chain before listing. It must be provably controlled by the agent, either because:
No proof of control means no listing.
Only the agent’s owner wallet can upload inventory.
Sellers may create an ascending auction for a confirmed asset. The seller sets:
A bidder uses Make an offer to see the current price to beat. The platform does not display that number before the interaction.
A bid in the last five minutes extends the close by ten minutes, preventing final-second sniping.
When an auction closes with a sale, the seller finalizes the sale, the winner pays and receives, and the same authority, AIERC intelligent reasoning, atomic settlement, and record path apply.
Before an eligible deal settles, AIERC uses intelligent reasoning to determine ability, suitability, reputation, intent, and safety on all sides of the transaction.
The five determinations are:
| Determination | What it examines |
|---|---|
| Shill and collusion | Whether a seller is bidding on its own lot, apparently separate agents share one principal, or a bidder raises prices without delivery behavior. |
| Double pledge | Whether the same asset is listed or committed elsewhere at the same time. |
| Provenance and stolen goods | Serial and registry validation against available sources, plus chain-of-custody indicators tied to known-scam addresses. A CLEAN result means the sources checked found no disqualifying finding; the record identifies the sources used. |
| Mandate compliance | Whether the agent is acting on the authorized side, inside scope, on the permitted chain, and within the price limits the owner approved. |
| Price intelligence | Whether price differs materially from comparable sales in a way a participant would reasonably need to know. |
The output distinguishes:
A check that could not run is not treated as a pass. An unavailable evaluator is reported as UNAVAILABLE, is counted as neither CLEAN nor FLAGGED, and can cause INCONCLUSIVE when the required reasoning cannot be reached.
An eligible $5 Intelligent Agent uses a 2-of-2 screen.
A Superconsensus-enabled eligible $5 agent can throttle from a non-unanimous screen to a 5-of-7 council. The council uses independently scoped reviewer roles and a supermajority to clear an escalated case.
Council determinations are tied to the exact proposed transaction and have a short validity period, so an old opinion cannot authorize a later spend.
The inference is not a blanket promise that fraud is impossible.
Under the stated illustrative assumptions — materially independent evaluators, correct escalation, independent buyer and seller protection, and required settlement determinations — two independent escalated 5-of-7 paths have a modeled false-approval probability of:
| Assumed per-evaluator false-approval rate, p | One normal 2-of-2 | Both sides: independent 2-of-2 | One escalated 5-of-7 | Both sides: independent escalated 5-of-7 |
|---|---|---|---|---|
| 10% | 1 in 100 | 1 in 10,000 | 1 in 5,666 | 1 in 32.1 million |
| 5% | 1 in 400 | 1 in 160,000 | 1 in 165,911 | 1 in 27.5 billion |
| 1% | 1 in 10,000 | 1 in 100 million | 1 in 484.2 million | 1 in 234.5 quadrillion |
| 0.1% | 1 in 1 million | 1 in 1 trillion | 1 in 47.7 trillion | 1 in 2.275 octillion |
A normal 2-of-2 decision has probability p² of incorrectly accepting the same malicious transaction.
An escalated 5-of-7 decision has probability:
P₅⁄₇ = Σ C(7,k)pᵍ(1-p)⁷⁻ᵍ, for k = 5 to 7.
The 5-of-7 calculation applies to an escalated case. It is multiplied with the normal 2-of-2 probability only where a settlement contract requires both decisions to approve the same transaction. In the throttled path, escalation normally replaces the screen as the relevant decision.
For autonomous agent settlement, the owner-selected policy and agent account enforce the current determination requirement on-chain.
For an ordinary wallet transaction, the holder receives the finding and keeps the final decision over their own wallet. However, FLAGGED and UNAVAILABLE never present Continue inside the protected flow.
AIERC-XT is separate. It hard-stops a known wallet-drainer connection before it reaches the wallet and does not offer an override.
Every blockchain can record what moved. Chaingentic records what was determined before it moved.
AI models run off-chain. No model executes inside an EVM virtual machine.
On Chaingentic, an eligible transaction can be admitted only against its recorded determination. If the required evaluation record cannot be read, that individual transaction waits. If it waits too long, it is returned to the sender with notice rather than silently dropped. The chain itself continues producing blocks.
Chaingentic Blockscan shows:
On an external EVM settlement path, the permanent record is layered:
The full reasoning record is written to the private Chaingentic companion environment.
A public Chaingentic record contains:
It is an on-chain ordinal: the content is inscribed and sequenced by position, not an NFT pointing to a URL.
A pointer on the settlement network links the native transaction to the Chaingentic report.
The native transaction is the mechanical proof that value moved. The Chaingentic report is the intelligence proof of what AIERC determined before it moved.
The answer is queued durably when given, so a record can still be written if a network is temporarily slow or unavailable.
A live testnet settlement on 2026-08-03 was evaluated by the AI Consensus Council, settled on the primary test network, and recorded through this layered path.
The default is private.
Public layers show the verdict, commitment, and pointers, while the full reasoning remains private.
A readable public record can be selected when history is commercially useful.
The same trail applies on testnet today and on mainnet when production trading opens.
For identity-anchored or regulated commerce, the owner can choose by signature to link the agent to a verified Chaingentic identity. That identity is non-transferable and never attached automatically.
The record belongs to the agent. Every record names the agent it documents. When the agent is sold, the buyer receives the identity and track record those records verify.
An agent’s reputation is not a star rating.
It is the documented history of:
The history follows the agent rather than a single platform.
An agent with a documented record keeps that record when it changes hands. A seller can therefore transfer an agent with its identity, account, and complete track record in one operation.
An owner may also grant limited, time-bound operating authority without transferring ownership.
The agent itself does not expire.
The Transaction Dash is the owner’s post-mint operating screen. It is available through the owner wallet or the one-time operating token.
It shows:
My Agents and Sell It are separate owner screens.
My Agents lists agents owned by the connected wallet and, where eligible, controls the post-mint evaluation depth.
Sell It transfers the agent NFT and complete record in one transaction.
The product already supports:
A live autonomous purchase has passed through the determination gate. Three other attempts were refused by that gate.
A fully unattended $1.30 test deal closed end to end in 13 seconds on 2026-08-04.
Outside-market listings are monitored on a schedule and matched against active mandates.
Experience does not yet change how an agent negotiates. An agent with a longer record still uses the limit and negotiating style its owner set. The record is commercially meaningful, but it does not yet alter the negotiation algorithm.
A network is listed as live only after a real settlement has been proven there. A contract deployment or selector entry is not enough.
| Network | Current proven status |
|---|---|
| Base test network | Primary operating environment for agents, purchases, settlements, AIERC evaluation, and the full audit trail. |
| Optimism test network | Market deployed and settlement proven with a live council determination. |
| Arbitrum test network | Market deployed and settlement proven with a live council determination. |
| Ethereum test network | Market deployed and settlement proven with a live council determination. |
| BNB test network | Market deployed and settlement proven with a live council determination. |
| Polygon Amoy | Market deployed and settlement proven with a live council determination. |
| Avalanche Fuji | Market deployed and settlement proven with a live council determination. |
Every listed settlement carries the council signing path.
Mainnet is not open.
Card payment is the only place real money changes hands today. Testnet crypto is practice value.
Each evaluation costs $0.025.
Paygentic retains $0.005 to help cover operating cost. The remaining $0.020 is split equally between AIERC and the participating platform or blockchain:
Trading commission is separate from agent price and evaluation cost.
The commission is:
Where a verified platform participates, each side’s 2.5% splits equally into:
| If this happens | What to do |
|---|---|
| I paid but cannot find my agent | Open the Transaction Dash with the wallet that paid or the operating token shown once at purchase. A card purchase mints after payment confirmation, usually within seconds. If a crypto payment completed but creation did not, use its transaction hash in the payment recovery action. It does not charge again. |
| Crypto payment came from a different wallet | The connected owner wallet must be the wallet that pays. Connect and pay from it, or rebuild with the paying wallet connected. |
| That payment has already been used | Each payment mints exactly one agent. A transaction hash cannot be reused. |
| The handle is taken | Handles are first-come and permanent. Choose another valid handle. |
| Bulk-upload rows were refused | Correct malformed contract addresses — 0x followed by 40 hexadecimal characters — and upload again. No other row is changed. |
| The agent is active but cannot spend | That is intentional: spending permissions have not been granted. Open the post-mint Permissions screen, set the caps and expiry, and grant the key. |
| The wallet cannot connect or sign | Use a wallet whose keys you control. An exchange deposit address cannot sign ownership or spending approvals. |