# ElyPact white paper

Draft 0.13 · 13 October 2026

Fixed-price lots. HYPE, USDT or USDC settlement. Public orders or a counterparty you choose.

**Public testnet beta:** V5 and ten mocks are deployed separately on HyperEVM Testnet (998) and Elysium Testnet (99801). Use test HYPE and mock tokens only. Independent review and mainnet deployment remain pending. [Testing guide](/testing.html) · [HyperEVM contracts](/deployments/hyper-testnet.json) · [Elysium contracts](/deployments/elysium-testnet.json).


## Purpose and scope

ElyPact is a fixed-price OTC escrow marketplace. Sellers escrow approved token lots in sell offers; buyers escrow payment plus their fee in buy orders. The creator chooses the fixed price, currency, expiry and optional counterparty. The other side fills all or part. The design is intended for community members who already know their terms, and for people discovering available lots on a public board.



The supported settlement currencies are native HYPE, USDT and USDC. Each offer uses exactly one of them. There is no automatic currency conversion, price oracle, liquidity pool or promise that an offer will find a buyer. This document describes the V5 prototype, its accounting, assumptions and release requirements. The testnet deployment is not a mainnet release or an independent audit.

A buy order is funded upfront with the entire base price plus the 1% buyer fee. Sellers approve only the quantity they are delivering, then fill all or part. Tokens go to the order creator and the seller receives withdrawable proceeds after the 1% seller fee. Public bids may be filled by multiple sellers; private bids accept only the named seller. No automatic matching, order routing or price feed is included.


## Two chains. Separate markets.

The application supports configurations for HyperEVM Testnet (998) and Elysium Testnet (99801), with Local Hardhat (31337) for development. Every network has its own contract address, token addresses, balances, credits and offer IDs. Contract address strings can be identical on different chains; their state and balances remain separate. A wallet-enabled deal link identifies both the chain and the escrow contract. A token symbol alone never identifies a token contract.



HyperEVM Testnet (998) and Elysium Testnet (99801) each have a deployed V5 escrow and ten faucet-enabled mock tokens. Wallet mode reads shared on-chain orders; browser simulation remains an optional, local-only mode. ElyPact includes no bridge, cross-chain messaging or cross-chain settlement. Participants can use the external official Elysium testnet bridge to obtain gas on Elysium, but a balance on one network cannot pay for an offer on the other.

Real-token preparation targets HyperEVM mainnet (999), using HYPE, native USDC and USDT0 (on-chain symbol USD₮0). This is separate from the mock catalog and is not active on the website. Elysium mainnet configuration remains unpublished in its official specifications; Elysium support currently means testnet only.



The web frontend helps construct transactions and read public state through RPC providers. An injected wallet holds the signing keys. The contract enforces settlement and restrictions without relying on the website's displayed status. Hosting or RPC failure can disrupt the interface, even though confirmed blockchain records remain on-chain. Full historical indexing and production monitoring are release work, not delivered infrastructure.

### Finding an order

Market discovery reads 100 orders at a time. Older offers and Newer offers move through earlier batches; Latest returns to the newest batch. Filters apply to the current batch, and a valid shared link can additionally load an order by ID. An order missing from a filtered board is not proof that it was cancelled or filled: check its chain, escrow contract and order ID. This is bounded on-chain discovery, not a full historical index or activity ledger.

Portfolio separates personal offers, named-counterparty private deals, proceeds, refunds and approval controls from the public market. My offers includes the connected wallet’s public and link-only orders, including closed orders in the loaded set. Private deals shows named-counterparty orders for either participant. Portfolio can use the same Older offers and Newer offers controls to find personal and private orders in earlier batches. Notifications observe the currently loaded batch and an explicitly opened deal; they do not scan all historical orders automatically.


## Assets and payment choices

The deployed catalog contains ten mocks. The interface offers eight trading tokens for new buy and sell orders: NEST, KNTQ, PURR, SIGNAL, PERPME, RAM, CHAMELEON and EGG. HYPE, USDT and USDC are payment choices, giving 24 token/payment pairs in the current interface. Stablecoins remain claimable for test payments. Earlier stablecoin lots remain accessible in Portfolio for their creators and through valid deal links. The immutable V5 registry still supports the original 28 pairs; this interface change does not alter existing contracts or the historical acceptance results.



USDC and USDT mocks use six decimals; the other sale mocks and native HYPE use eighteen. Amounts are handled as integers in each asset's smallest unit. Changing the payment currency clears the entered price, because a HYPE price cannot be silently reused as a USDC price. The interface only compares unit prices within the same asset and payment currency.



V5 fixes the allowed sale-token addresses and the two stablecoin payment addresses at deployment. Direct calls cannot introduce another asset. There is no administrative function for changing this list. Token identities and compatibility still require independent verification before any real-asset release: an allowlist does not remove issuer freezes, upgrades, depegging or other token-specific risks. Logos and names are branding references, not endorsements or verified live listings.


## Offer lifecycle and settlement

- Set terms. Select buy or sell, network, token, quantity, payment currency, fixed base total, expiry and audience. These terms cannot be edited after creation; cancel the remaining lot and create a new offer to change them.
- Approve and deposit. For a sell offer, approve and deposit the sale tokens. For a buy order, fund the full base price plus buyer fee; stablecoin funding needs exact payment approval. The order is available only after confirmation. Abandoned token approvals can be revoked.
- Review and purchase. The taker chooses a quantity and reviews both fees and seller proceeds. A buyer filling a sell offer pays with HYPE or approves the exact stablecoin payment. A seller filling a funded buy order approves and delivers the sale tokens; no new payment is required from the buyer. HYPE is needed for gas in both flows.
- Atomic fill. A successful fill receives payment or uses the funded buy balance, transfers the purchased tokens and credits the seller and both fee allocations. If a required check or transfer fails, the transaction reverts these effects. A failed transaction can still consume network gas.
- Withdraw or close. The creator can cancel the unfilled portion at any time, including after a partial fill. A buy-order cancellation credits the buyer with the unspent base payment and unused buyer fee; the buyer then withdraws that credit in the original currency. Sell-offer cancellation returns unsold tokens. Completed fills and their fees remain final. After expiry anyone can trigger the same return to the original creator, never to the caller.



An offer moves from open to partially filled, then fully filled, cancelled or expired. Expiry stops purchases; returning unsold tokens or making unspent bid funding withdrawable still needs a reclaim or cancellation transaction. Public transactions may compete: another purchase or cancellation can make an outstanding transaction fail. The fixed quote does not guarantee availability or inclusion.


## 1% on each side

The buyer pays the agreed base amount plus 1%. The seller receives the base amount minus 1%. Both fees use the offer's payment currency; combined platform fees are 2% of its filled base value, subject to integer rounding. There is no extra platform fee for creation, cancellation, reclaim or withdrawal. Every transaction's network gas is separate and paid in HYPE by its sender.



Example: a lot priced at 100 USDC


| Item | Amount |
| --- | ---: |
| Agreed base price | 100.00 USDC | 
| Buyer fee | + 1.00 USDC | 
| Buyer pays | 101.00 USDC | 
| Seller fee | − 1.00 USDC | 
| Seller receives | 99.00 USDC | 
| Combined platform fees | 2.00 USDC |
| Team allocation | 1.00 USDC |
| KNTQ buyback allocation | 1.00 USDC | 



The same percentages apply to HYPE and USDT. A purchase of one quarter of this lot has a 25 USDC base amount, a 0.25 USDC buyer fee and a 0.25 USDC seller fee: the buyer pays 25.25 and the seller is credited 24.75 USDC. Fees apply only to the filled amount.

For example, a buy order for 100 NEST at a 160 USDC base price deposits 161.60 USDC. A seller delivering 25 NEST earns 39.60 USDC; 40.40 USDC is consumed from the funded balance. Cancelling then credits 121.20 USDC back to the buyer, including 1.20 USDC of unused buyer fees. Withdrawal is a separate transaction.



The contract allocates 50% of collected fees to the team and 50% to a KNTQ buyback budget. V5 records separate balances for each payment currency and emits allocation and withdrawal events. These balances are separate from traders' proceeds and escrowed inventory. The fee operator cannot withdraw those user balances.

In the current testnet design, the fee operator can withdraw either fee allocation to a chosen address. The escrow does not constrain subsequent spending or execute KNTQ purchases and Assistance Fund transfers. This is an operator-trust limitation: an on-chain allocation or withdrawal is not proof of a completed buyback. Purchase and transfer receipts, costs and unspent balances must be reported separately. No actual KNTQ buyback or Assistance Fund transfer has been executed by this prototype.

### Required before mainnet

Priority before mainnet: implement and independently review a restricted on-chain fee module. The planned module must separate the team payout from the buyback budget, constrain spending to approved KNTQ purchase routes, enforce reviewed price and slippage limits, fix the Assistance Fund destination and publish execution events. Operators must not be able to redirect the buyback budget to their own wallets. A keeper may trigger transactions, but contract rules must constrain the result. This module is not implemented or deployed. Existing testnet escrows have immutable fee recipients; a new escrow deployment and fresh acceptance tests are required for the module integration.

The proposed HyperEVM KNTQ destination is the Hyperliquid Assistance Fund at 0xfefefefefefefefefefefefefefefefefefefefe. A transfer to that address does not reduce the token's reported totalSupply. Each chain needs separately verified token and execution-route configuration; this design does not assume cross-chain buybacks.

The fee rate and fee wallet are fixed per deployment. ElyPact does not require a separate project token or KNTQ holding to trade. Production fee-module controls and team-treasury ownership and recovery must be established before deployment.


## Partial fills and conservation

Let A be the total sale quantity, P the base price and s the quantity already sold, all in their respective integer units. The cumulative base payment is B(s) = floor(P × s / A). Buying q units pays the difference B(s + q) − B(s). At full completion B(A) equals P, so the lot's full base price is collected exactly.



For either side, the cumulative fee at base payment b is F(b) = floor(b × 100 / 10,000). Each fill charges the difference between the new and previous cumulative fee. Splitting a single lot into partial purchases does not reduce its aggregate fee. Rounding happens in the smallest payment unit: wei for HYPE, and one millionth of a token for the mock stablecoins. Very small cumulative values can round a fee to zero; fills whose base payment rounds to zero are rejected.



For every fill, buyer payment consumed equals seller credit plus the team allocation plus the buyback allocation. A funded bid holds G(P) = P + F(P) initially; after cumulative base fills b, its remaining collateral is G(P) − G(b). Cancellation moves exactly that remainder to the buyer’s withdrawal credit without charging fees on it. Credits are keyed by both currency and recipient. Escrow inventory is separate from earned-credit obligations even when the same stablecoin appears in different offers as both a sale asset and a payment asset. For a compatible token, balances must cover remaining sell inventory plus unspent buy-order collateral, unwithdrawn trader credits and both fee allocations in that asset; native HYPE must cover unspent native buy-order collateral, unwithdrawn trader credits and both fee allocations. These are accounting properties exercised by tests, not a formal verification claim.


## Public orders, private counterparties and discounts

Public buy and sell orders appear on the board. Link-only orders are unlisted but remain fillable by anyone unless a counterparty is named. Private sell offers name a buyer; private buy orders name a seller. The contract enforces that address, and the creator cannot fill their own order. A link never bypasses the restriction.



Private describes who may fill the order, not who may read the data. Wallet addresses, terms and activity are public on-chain, and the website provides no encrypted chat or identity verification. Counterparties should agree and verify their wallet addresses before the creator funds the order.



The optional discount calculator applies a percentage to a seller-entered reference price in the selected payment currency. For example, 100 NEST at a reference of 2 USDC each with 20% off creates a fixed 160 USDC base total. The reference is not a live quote or independently verified discount. The resulting total remains fixed when external market prices change.


## Security model and limits

V5 uses OpenZeppelin safe ERC-20 calls and reentrancy protection. Incoming and outgoing token transfers compare both sender and recipient balance changes with the expected amount. Approvals are limited to the intended transaction amount. Seller and platform proceeds use pull withdrawals; credit is cleared before the external transfer and restored by a revert if withdrawal fails. Named-counterparty checks, expiry checks and exact HYPE payment checks run on-chain.



The interface verifies the selected chain, contract version, fee rate, configured payment tokens, asset admission and mock decimal precision. It rechecks the quote after any payment approval, simulates key actions and displays a submitted transaction hash. A changed quote requires another review. These checks reduce mistakes; a compromised website, wallet, RPC endpoint or token can still create risks. Users must inspect wallet transaction details.



Transfer taxes, rebasing and restrictions can break compatibility. An asset that changes behaviour after deposit may prevent a fill, cancellation or withdrawal. Stablecoin values are not guaranteed, and the contract does not convert or redeem them for fiat. Sending assets directly to the contract instead of calling its functions creates no withdrawal credit; there is no administrator rescue function.



The contract has no emergency pause, upgrade proxy or privileged arbitrary withdrawal. This limits administrator powers but also limits incident-response options. Independent review must assess that tradeoff before launch. Wallet signing with separate participants, rejection paths, pending transaction recovery, replaced transactions, RPC failures and frontend supply-chain integrity require dedicated release testing. Passing automated tests is not an independent audit or a security guarantee.

### Transaction status and recovery

A wallet approval, a submitted transaction and a confirmed trade are separate states. An ERC-20 approval grants spending permission; it does not itself create or fill an order. The interface waits for a successful receipt before reporting the intended action as confirmed. An observed cancellation or replacement with a different action is not treated as a successful trade.

Before opening a wallet prompt, the interface saves the intended call, value, account, chain, escrow scope and nonce in browser storage. Once a hash returns, it is saved with those request details. An unresolved saved submission blocks further trading actions in that scope. The status recheck reads the existing transaction; it does not submit another trade. A timeout or failed RPC request does not prove the transaction failed. Check the wallet and receipt before retrying.

Saved request details allow bounded block searches or a user-supplied transaction hash to reconcile a mined transaction by account and nonce, including when its hash was lost or a replacement mined while the page was closed. Call data, destination and value distinguish the intended action from cancellation or replacement. No automatic resubmission occurs. Unknown outcomes remain blocked; repeated checks or wallet history may be needed. Recovery cannot reconstruct erased storage, coordinate other applications or safely accept a wallet overriding the requested nonce. Do not clear a pending record merely to bypass the block. Separate participant wallet sessions remain a release requirement.

### RPC availability

Elysium reads use small queued RPC batches and bounded backoff for rate limits. Refresh is disabled while a load is in progress. These measures improve access to the public endpoint; they do not guarantee uptime or fast inclusion. If deployment verification fails, wallet actions are disabled. Confirmed orders and withdrawal credits remain on their original chain, and the website cannot reverse a confirmed transaction.


## Evidence and release plan

**Priority 1 mainnet blocker:** implement and independently review the restricted fee module, verify its source and configuration, and rehearse allocation, KNTQ purchase and Assistance Fund transfer. The current operator-controlled fee route is not approved for mainnet.

The hosted wallet interface supports HyperEVM and Elysium testnets. V5 has been exercised locally in both directions across all 28 token/payment pairs: 56 buy/sell combinations. A mainnet fork also checked real token code, private restrictions, partial fills, cancellation/refunds, fee withdrawals and a KNTQ Assistance Fund transfer. Fork checks use a local copy and move no real funds. On each of HyperEVM and Elysium testnets, all 56 buy/sell combinations passed with 436 confirmed transactions using two dedicated test wallets (872 confirmed acceptance transactions across the two networks). Final participant testing still needs real browser-wallet sessions. Public acceptance receipts: [HyperEVM](/deployments/hyper-testnet-acceptance.json) · [Elysium](/deployments/elysium-testnet-acceptance.json). A previously completed HyperEVM mainnet pilot confirmed 82 transactions with mocks and small native-HYPE payments, but it used the older V1 seller-only fee contract. Those receipts do not validate V5 stablecoin settlement.




- Testnet release: verify V5 and mocks independently on each funded testnet and run settlement acceptance with dedicated wallets. Both testnet escrows and their mock registries are deployed. Local compiler-derived runtime, constructor parameters and registry are checked against the public deployment; this is not explorer source verification or an independent audit.
- Participant testing: validate both order directions, upfront bid funding, token approvals, private links, partial fills, cancellation/refunds, expiry, withdrawals and recovery in two real browser-wallet sessions.
- Real-asset readiness: complete independent contract review, verify each real token and its transfer behaviour, agree immutable deployment parameters, fee-wallet control and operational ownership.
- Controlled rollout: establish monitoring, pending-transaction recovery, historical offer indexing and a documented incident procedure, then obtain explicit approval for a limited real-asset launch.



There is no promised launch date, liquidity commitment or bridge roadmap. The immediate scope is reliable fixed-price settlement with clear costs and exits.


## References and design context

The scope and technical coverage were checked against established protocol documentation. AirSwap describes peer-to-peer atomic settlement; Uniswap's technical paper separates architecture, accounting and protocol capabilities. ElyPact uses deposited fixed-price lots, not AirSwap's signed-order model or Uniswap's automated market maker. These references do not imply integration, endorsement or inherited audits.




- [AirSwap protocol overview and OTC context](https://about.airswap.xyz/)
- [Uniswap v4 Core — technical white paper, August 2024](https://app.uniswap.org/whitepaper-v4.pdf)
- [OWASP Smart Contract Security Verification Standard](https://scs.owasp.org/SCSVS/)
- [Kinetiq: KNTQ value accrual](https://kinetiq.xyz/docs/kntq)
- [Hyperliquid: Assistance Fund address](https://hyperliquid.gitbook.io/hyperliquid-docs/trading/fees)
- [Ascend: KNTQ Assistance Fund transfers](https://ascendlaunch.gitbook.io/docs/revenue-and-capital-allocation#kntq-allocation)
- [Token artwork provenance](/tokens/SOURCES.md)



This document is a draft specification for the current implementation. The final release must identify the exact deployed source, compiler settings, dependencies, network addresses and audit scope.