Aegis is a wallet-based OTC desk for exchanging native currency and standard ERC-20 tokens directly with another party. You choose the assets, quantities, recipient and expiry. A smart contract holds the maker’s deposit until the agreement is settled or refunded.

What is live?

Choose your first task

What Aegis does

Aegis provides agreement-based exchange, not an AMM or an order-routing exchange. A trade uses the exact quantities agreed by the parties. There is no pool range, market-price guarantee or automatic matching. Aegis does not need your wallet’s private key.

These docs describe the current website and current contracts. Verify the network and contract shown in the actual transaction review before signing.

Before you start

• An EVM wallet with access to the selected network.
• The asset you intend to deposit or pay, and native currency for gas.
• The exact token contract addresses. A token symbol alone is not an identity.
• A counterparty or an offer you have independently checked.

If you are selling

1. Open the Aegis desk and connect your wallet.
2. Choose the same network for the deposit and receive sides.
3. Select your deposit asset and amount, then the asset and amount you want to receive.
4. Set the expiry, payout address and optional approved buyer.
5. Review and sign any token approval. Then review and confirm funding escrow.
6. Save the resulting private invitation and escrow commitment. Send the full link to your buyer.

If you are buying

1. Open the complete invitation or a published board listing.
2. Confirm the network, asset contracts, quantities, expiry and buyer total.
3. Connect the intended buyer wallet. Approve the payment token if requested.
4. Review and confirm the settlement transaction.
5. Check the confirmed receipt. On the same chain, both asset transfers settle in that transaction.

For a detailed walkthrough, read Create an offer or Accept an offer.

Supported networks

Connect and switch

Use Connect wallet in the desk. When the wallet is on another chain, use the network switch control and check the request in the wallet. On mobile, use an EVM wallet’s browser if your regular browser does not expose a wallet connection.

Wallet addresses look identical across EVM networks. Having tokens at your address on another chain does not fund an Aegis trade on the selected chain. Keep enough native HYPE or ETH for approvals, funding, settlement or refund transactions.

Current application connections

Elysium RPC: https://rpc.volta.family
Robinhood Chain RPC: https://rpc.mainnet.chain.robinhood.com

These are the connections configured in the application. Deployment availability and wallet prompts take priority over a saved screenshot. Aegis does not currently provide an asset bridge in its same-chain trade flow.

1. Write the agreement

Open Create an offer. Select your settlement network. For a live same-chain trade, select the same network for You deposit on and You receive on. Choose native currency or a standard ERC-20 token on each side.

You sell is what you put into escrow. You receive is the exact amount the buyer pays to your payout address, excluding the buyer’s extra fee. For custom tokens, paste the contract address and verify its symbol, decimals and network.

2. Choose recipients and expiry

The payout address receives the agreed payment when the trade settles. An optional approved buyer limits who can fill the agreement. If no buyer restriction is set, anyone who obtains the terms and can satisfy them may fill it.

Choose an expiry in the future. The current same-chain contract accepts an expiry at most 180 days ahead. Expiry stops settlement; it does not automatically send a refund.

3. Review, approve, fund

Check the asset contracts, quantities, network, payout, expiry and fee information in the review. For an ERC-20 deposit, the wallet may first need to approve the escrow contract. Approval grants a spending allowance; it is not the deposit transaction.

After approval, proceed with the separate funding transaction. A native deposit is sent as the transaction’s native value. An ERC-20 deposit is transferred into escrow by the approved contract. Wait for a confirmed receipt.

4. Save and share

Copy the entire generated private invitation, including everything after #. Keep the commitment and transaction receipt. If you want a public listing, explicitly choose publication and sign the listing. Funding a private offer does not by itself mean you consent to publishing its complete terms.

1. Inspect the invitation

Open the full private link or use Open private link in the desk. The browser decrypts the terms locally. Alternatively, choose a funded public offer from the board.

Check the seller’s deposit, payment asset, exact payment amount, fee, payout, expiry and contract address. Read token addresses, not just names. Confirm the offer is still open and funded.

2. Prepare the correct wallet

If the maker specified an approved buyer, that address must be the transaction caller. Another wallet cannot fill the agreement merely because it has the invitation. Make sure you have the requested payment asset, the additional fee and native gas.

3. Approve and settle

If paying with an ERC-20, approve the reviewed spending allowance first. Then review the actual settlement. The buyer’s total is the agreed payment plus the settlement fee. Network gas is separate.

On successful same-chain settlement, the maker receives the agreed payment, the fee goes to the configured collector, and the escrowed asset goes to the reviewed receiver. If a required transfer fails, the whole settlement transaction reverts.

4. Confirm the outcome

Wait for the confirmed receipt and inspect the transaction link. An expired, cancelled or already settled offer cannot be filled. A simultaneous cancellation or fill by another eligible party can cause your transaction to revert; check current state before preparing another review.

Publish an offer

Only funded offers that the maker explicitly publishes appear on the Aegis board. Publishing requires the maker’s signature. The board verifies the listing against the funded escrow and its network; a draft or an arbitrary token promotion is not a funded offer.

Publication exposes the agreement’s terms to board visitors. An encrypted invitation is no longer the exclusive way to discover the terms of an offer you have deliberately published.

Find and verify offers

Choose the board network and refresh the listings. Read the complete buyer total, the expiry and both token addresses. Public visibility is not a token endorsement, a guarantee of a fair price or a guarantee that the offer remains open until you submit.

After settlement or cancellation

Refresh the board to get the latest escrow state. The contract is authoritative; an old listing, copied link or cached screenshot cannot reopen an agreement that has already settled or been refunded.

Cancel before expiry

The maker can cancel an open same-chain offer. In My trades, load saved receipts or inspect the known commitment, then review the cancellation. The connected wallet must be the maker. A successful cancellation returns the deposited asset to the original maker and closes that escrow.

Recover after expiry

After expiry, anyone can trigger the expiry refund of an open escrow. The caller pays gas, but the contract always sends the principal to the original maker. The caller cannot choose a different refund destination.

Expiry does not automatically broadcast a transaction. The deposit remains reserved until a refund transaction succeeds. It cannot be swept as deployer surplus merely because the offer has expired.

Find your agreement

Connect the correct wallet and network, then open Manage escrow. Browser-saved receipts help locate commitments. If the browser has no saved receipt, inspect the known commitment directly. The escrow commitment is a hash identifying the agreement; it is not a token address.

A closed offer cannot be refunded a second time. Existing agreements must be read at the contract where they were funded; using a different deployment does not move a deposit.

Approval is permission

An ERC-20 approval allows a specified contract to spend up to the reviewed allowance. It does not by itself fund escrow or settle a trade. Some tokens require an existing allowance to be reset before another allowance can be set, adding a wallet transaction.

Review before every signature

Read the chain, target contract, token, quantity, receiver and native value. Gas is a separate network charge. A signature publishing a board listing is different from an on-chain transfer, but its contents still matter.

Submitted and confirmed

A wallet confirmation sends a transaction; a successful chain receipt confirms the result. Pending means Aegis has not yet established the final outcome. Use the explorer link to inspect the recorded transaction hash.

Rejected wallet prompts do not complete a step. Reverted transactions do not complete the exchange, although network gas may have been spent. If confirmation is uncertain, check the saved hash before submitting a replacement. Refresh state and prepare a fresh review if the wallet, network or terms changed.

Browser-side encryption

The browser encrypts the offer payload using AES-256-GCM, a fresh 32-byte key and a 12-byte random initialization vector. Authenticated encryption rejects a payload that cannot be decrypted and authenticated with the supplied key and data.

The invitation holds the key, initialization vector and encrypted payload in the URL fragment after #. That fragment is not included in normal HTTP requests to the website server. Decryption happens in the browser.

The full link is an access credential

Anyone with the complete invitation can decrypt and read its terms. Encryption does not make a forwarded invitation unreadable to its new recipient. Protect the link in your messages, browser history, clipboard and screenshots. Browser extensions and software on your device may have access to what you open.

Use an approved buyer address to restrict who can fill. Buyer restriction controls acceptance, not whether someone with the full link can read the terms.

What stays public

Wallet addresses, deposited asset, quantity, expiry and contract interactions are visible on the public blockchain. The agreement is bound by an on-chain commitment. Settlement reveals the exchange terms submitted to the contract. Publishing on the public board also makes those terms public.

The agreement commitment

The order includes the maker, deposit asset and amount, requested payment asset and amount, optional approved buyer, payout address, expiry and random salt. Its commitment also binds the chain ID, escrow contract and Aegis domain. Changing one of those values produces a different commitment.

Same-chain lifecycle

1. Draft: terms exist locally; nothing has been deposited.
2. Open: the maker funds the commitment and its principal is reserved.
3. Settled: an eligible buyer satisfies the terms before expiry; asset transfers complete atomically.
4. Refunded: the maker cancels, or expiry recovery returns the open deposit to the maker.

Settled and refunded escrows cannot be filled again. A contract transaction either succeeds with its required state changes and transfers, or reverts.

Who controls funds?

Your wallet signs approvals and transactions. Open deposits sit at the escrow contract, not in an Aegis browser balance. The current contracts reserve liabilities so surplus recovery cannot withdraw open deposits. There is no general administrator function that redirects an open trade’s principal to an arbitrary address.

Settlement fee

The current desk charges the buyer 1% of the agreed payment, rounded down to the payment token’s smallest unit. The maker receives the agreed payment amount. Fees are collected when settlement succeeds.

Gas is separate

Approvals, escrow funding, settlement, cancellation and refunds are on-chain actions with network gas charges. The transaction caller pays those costs. A reverted transaction can still cost gas. A fee-free signature or an approval is not a completed trade.

Fee allocation

The project allocates collected OTC settlement fees to AEGIS buybacks and dead-address delivery. Collection, conversion and execution have different roles: a collected fee does not mean a buyback has already occurred. Current automation covers only supported Elysium fee assets.

Token identity

AEGIS is deployed on Elysium, chain 99901. The verified token contract is 0x5810e318C86fb1921Ccfa642920712a92441F407. It has 18 decimals and a one-billion token supply. Verify the address rather than relying on a ticker.

Current policy

100% of collected OTC settlement fees are allocated to AEGIS buybacks and burns. The currently activated hourly automation processes native HYPE and WHYPE fees on Elysium through the verified route. Other payment assets and Robinhood Chain fees remain held until verified conversion routes are available.

Purchased AEGIS goes directly to 0x000000000000000000000000000000000000dEaD. This is a transfer to a dead address: it removes those tokens from circulation but does not reduce the token contract’s totalSupply value.

Execution limits

• Minimum automatic batch: 0.01 HYPE equivalent.
• Maximum batch: 0.1 HYPE; maximum per UTC day: 1 HYPE.
• Slippage bound: 1%; maximum estimated price impact: 2%.
• Gas limits: 0.0005 HYPE per batch and 0.002 HYPE per UTC day.

A run can hold when fees are below the threshold, routes or runtimes change, a transaction is unresolved, or an execution bound cannot be satisfied. An hourly check is not a promise of an hourly purchase.

Control and limitations

The fee collectors are bound to deployer-controlled withdrawal treasuries. The buyback policy and automation do not make every possible deployer action impossible at contract level. AEGIS ownership does not establish a claim to escrow principal, a guaranteed return or a guaranteed market price.

Asset types

Same-chain trading supports native HYPE and standard ERC-20 tokens on Elysium, and native ETH and standard ERC-20 tokens on Robinhood Chain. The website provides known choices and custom-token entry. A custom token must be deployed on the chosen chain and expose usable metadata.

The zero address represents the native asset in contract terms. A wrapped asset such as WHYPE is an ERC-20 and has a separate allowance and balance from native HYPE.

Exact transfer behavior

The escrow checks exact token balance changes. Fee-on-transfer and rebasing tokens are unsupported. A malicious, paused, blacklisting or otherwise nonstandard token may prevent deposit, settlement or refunds. A familiar symbol or a successful metadata lookup is not a token security assessment.

Pricing an agreement

The maker enters exact amounts. Aegis does not select an exchange rate from an AMM or guarantee that a quote matches an external market. Both parties should compare the agreed quantities and token decimals before signing. This OTC desk does not create liquidity pools.

Reserved deposits

The current same-chain contract reserves the full principal of every open funded escrow. Expired deposits stay reserved until they are successfully refunded. Cross-chain contracts also account for their outstanding principal and pending fees.

Excess funds only

The immutable recovery controller is recorded at deployment. Its surplus-recovery function can withdraw only a positive balance above reserved liabilities, to the controller. The function checks authorization, available surplus and remaining coverage of liabilities, with reentrancy protection.

This is intended for assets transferred outside an agreement, including accidental token transfers or forced native transfers. It does not authorize withdrawal of another user’s reserved deposit, rewriting an open agreement or bypassing a token’s restrictions.

Existing agreements

Contracts already deployed retain their own rules. An interface update does not upgrade them or migrate their balances. A copied offer or known commitment must be inspected at its original chain and contract. Old invitations continue to select the appropriate deployment when recognized.

Current same-chain deployments

These addresses are for current same-chain settlement, not the AEGIS token or a wallet to send arbitrary transfers to. Use the website’s reviewed funding flow to create an agreement.

Verification checklist

1. Check the wallet’s chain ID.
2. Match the reviewed target with the intended escrow or token contract.
3. Check the native value and token allowance separately.
4. Read the actual recipient, amounts and expiry.
5. After signing, check the transaction hash and successful receipt.

Runtime and immutable-setting checks and local/fork tests provide implementation evidence. They do not constitute an independent security audit. The application’s current public configuration is available at /api/config; its selected generation and the transaction review determine which deployment is in use.

Current website availability

New cross-chain offer creation is disabled in the public desk. Choose the same network on both sides for live trading. The presence of cross-chain contracts, test results or a previous invitation does not mean new cross-chain offers are enabled.

Existing agreements

Existing cross-chain agreements retain their original settlement and refund paths. Their separate deployments, commitments and timing rules matter. Open the original invitation and follow its displayed claim or refund state; do not apply the same-chain refund instructions to an unrelated cross-chain contract.

Different from same-chain settlement

Same-chain settlement moves both assets in one transaction. Cross-chain settlement requires actions across two networks and has additional timing and recovery conditions. Documentation for new cross-chain creation will be updated when that product path is enabled.

Select test mode

Choose Sandbox in the desk. Its chain ID is 31337. If the sandbox is available, use its wallet and test-funding controls to obtain test gas and test tokens. Funding is rate-limited; reuse the balance already supplied when possible.

Try the full lifecycle

1. Create an offer with test assets.
2. Inspect the generated private invitation.
3. Accept from another eligible wallet, or cancel an open offer as its maker.
4. Observe approvals, funding, settlement and transaction receipts separately.

Sandbox assets have no intended monetary value and do not fund mainnet agreements. Test success does not guarantee that a particular mainnet token will behave correctly. Never import or paste a private key into Aegis to access a sandbox.

Wallet will not connect

Open Aegis inside a supported EVM wallet browser or enable your wallet extension. Unlock the wallet, select the expected account and approve the connection. Check that the selected network matches the desk.

Private link cannot be decrypted

Use the complete original link, including the # fragment and all its parameters. A truncated, edited or incorrectly copied invitation cannot be decrypted. Ask the maker for the original link. The server does not hold a separate copy of the decryption key that it can restore.

Approval succeeded, but the trade did not

Approval and trading are separate on-chain actions. Continue to the actual funding or acceptance review, check the new terms and confirm that transaction. Inspect the recorded receipt before assuming the assets moved.

Transaction is pending or confirmation is uncertain

Use its transaction hash in the explorer. Do not blindly repeat a funding, fill or refund. If you changed wallet or chain, return to the correct context and reload the agreement before starting a new review.

Insufficient balance or failed transfer

Check the chosen chain, native gas balance, payment amount plus fee, token allowance and token decimals. A token may reject transfers even when its displayed balance is sufficient. Nonstandard transfer behavior is unsupported.

No escrows appear in Manage escrow

Saved receipts belong to this browser and network context. Changing browsers or clearing storage can remove the local list without changing the on-chain escrow. Inspect a known commitment at the original contract. A transaction hash, commitment and token address are different identifiers.

Offer expired, settled or cancelled

Refresh its state. An expired open same-chain offer can be refunded to the maker. A settled or refunded offer cannot be accepted again. If a counterparty acted first, your prepared transaction may no longer be valid.

Using Aegis

Funds and fees

Privacy and availability

Maker

The wallet that sets an agreement’s terms and funds its escrow deposit.

Buyer / taker

The wallet that accepts the terms and submits payment plus the fee.

Payout

The address designated to receive the maker’s agreed payment.

Receiver

The reviewed address that receives the deposited asset on settlement.

Commitment

A hash binding the order, chain and escrow contract.

Escrow

The contract holding the reserved deposit while the agreement is open.

Allowance

The amount an ERC-20 owner authorizes a spender contract to transfer.

Salt

Random order data included in the commitment.

URL fragment

The part after # in a URL, used for the private invitation’s encrypted payload and key.

Atomic settlement

Required same-chain transfers and state changes succeed together or revert together.

Surplus

Contract balance above reserved liabilities.

Gas

The chain’s native-currency transaction charge, separate from the OTC fee.

Dead-address transfer

Sending tokens to the designated dead address; distinct from reducing totalSupply through a token burn function.

Open My trades

Connect your wallet, choose the agreement’s network and open My trades in the workspace. The dashboard reads the current status of browser-saved receipts for the selected escrow contract. Counts summarize the loaded agreements; they are not an all-chain portfolio balance.

Filter by next action

Open shows agreements that can still settle before expiry. Makers can review cancellation. Refundable shows expired, open deposits: anyone may trigger recovery, but funds return only to the original maker. Completed includes settled and refunded agreements. Every refund or cancellation still requires its own review and wallet transaction.

Find older activity

Use Find recent on-chain trades to scan a bounded range of 20,000 blocks for maker, buyer and refund activity. The scan checks only the selected network and escrow deployment. Use Scan earlier to extend the range. It does not claim complete multi-network history. Known commitments remain available for direct inspection.

Local receipts and templates

Receipts and complete repeat templates are stored in this browser, separated by wallet, chain and escrow contract. Opening your own original invitation can restore its private terms for a repeat draft. Settled orders can also be recovered from verified public settlement calldata when discovered in a scan. Clearing browser storage removes this local convenience data, not the on-chain deposit. Do not use shared browser profiles for private offer terms.

Choose the original trade

In My trades, select Repeat offer on an agreement you created. The action requires its complete verified terms. If the button is unavailable, open the original private invitation while connected as its maker, then return to My trades. A public escrow deposit alone does not expose the private payment terms.

Review the copied draft

The draft copies the two asset contracts, exact quantities, payout and optional approved buyer. It resets the expiry choice to 24 hours. You can edit these fields before reviewing. It does not copy the old expiry or salt into the new agreement; a new salt and commitment are created during the normal review flow.

A separate agreement

Repeating does not sign, approve, deposit, cancel or change the original escrow. Check the network, quantities, payout, buyer restriction and refreshed expiry. Review any necessary approval and funding transaction in your wallet to create the new agreement. New offers are created only on the current desk.