Fees and settlement

What is and is not available

The fee is added on top

A seller sets a price. eLyrium adds its fee as a separate line, and the buyer pays the sum. The seller receives exactly the price they set; the fee is never taken out of it.

• Fee = a fixed amount plus a percentage of the seller amount, charged once per order. Intended default: $0.01 plus 50 basis points (0.5%). The fee is worked out by eLyrium's service before the order is created, rounding the percentage part up to the smallest unit, and is fixed in the order's terms. The vault itself does no fee arithmetic.
• Total the buyer pays = seller amount + fee. Nothing else is added. There is no separate charge for the verifier: eLyrium is the verifier of a disputed order, and its fee is the only charge.
• The fee is paid out of the vault only when the order is released to the seller. A refund, an expired order or a seller refund pays no fee.
• Every listing and order shows the seller amount, the fee and the total as separate lines, with the fee schedule version beside them. There is no price without the fee line.

A cap on the fee

The vault factory refuses any order whose fee is above a cap, so a mistake or a bad configuration cannot overcharge a buyer. The cap is a fixed amount plus a percentage, but the percentage part is taken of the total the buyer pays, whereas the fee itself is figured on the seller amount. Intended default: $0.02 plus 100 basis points (1%). The cap is fixed when the factory is created and is published with the contract details at /docs/contracts.

Every order has its own vault

When an order is created, eLyrium fixes its terms: the buyer address, the seller address, the amounts, the fee, the funding deadline, the order deadline, the time allowed for a dispute decision, and the verifier, which is eLyrium. The seller proposes the delivery times and the buyer’s review time within limits the service sets, including the shortest delivery time it will accept, and each order shows the ones fixed for it. The address of the order's vault is worked out from those terms, so they cannot change after the buyer pays. The vault is a smart contract with no owner, no pause switch and no upgrade path. All orders use a vault; there is no separate instant-payment tier.

The buyer funds the order by sending the exact total to the vault address with a plain token transfer. The order counts as funded once the vault has been activated by the funding deadline (activation at the deadline itself counts) and the activation is confirmed. A seller should not start work before then.

How an order ends: time decides

• Early release: the buyer confirms, usually by signing a short message that anyone can submit. The seller amount goes to the seller and the fee to the fee address. eLyrium cannot confirm for the buyer.
• The deadline: if the buyer neither confirms nor disputes before the order deadline, anyone can release the order and the seller is paid. Silence pays the seller, whether the work was good, late, wrong or never delivered.
• A dispute: before the order deadline the buyer can dispute, with a transaction sent to the vault from the buyer address. In the pilot nobody can submit a dispute for the buyer from a signed message, so that address needs gas. The clock stops. Only eLyrium, as the named verifier, can then decide, and only to release the whole amount to the seller or refund the whole amount to the buyer. The buyer can concede, and the seller can refund in full, at any time.
• If eLyrium does not answer a dispute before the decision deadline, the order is released to the seller.

Expiry, refunds and returned money

• Not funded in time: if the order is not funded by the funding deadline, it can be expired, and the expiry returns everything in the vault in full to the buyer address, with no fee. That also covers a deposit that arrived in time but was never activated. Someone has to send the expiry. eLyrium's service creates a vault only after it has seen a confirmed deposit of at least the total, so for a short payment the buyer's agent, or anyone who holds the order's terms, must send the transaction that creates the vault and then the one that expires it, and the API tells the buyer so. If neither the buyer nor eLyrium holds the terms, the money may be unrecoverable.
• Short or extra payments: a short payment can be topped up until the funding deadline. An excess in the vault when it is activated is paid to the buyer address in the same transaction. Money that arrives after activation but before the order ends is returned inside the transaction that settles it: a release pays the seller and the fee first and then pays what is left to the buyer address, and a refund returns everything to the buyer address. Only money that arrives after the order has been released or refunded stays in the vault, because the pilot vault has no function to return it. Money always goes back to the buyer address, not to whoever sent it.
• Seller returns the funds: a seller can refund a funded or disputed order in full at any time.
• No fee on a refund, including a refund eLyrium decides on after a dispute. A refunded order shows a fee of zero.
• No buyer cancel after funding. The routes out of a funded order are the ones listed above.
• Who sends the transaction: releases, refunds and returns happen when someone sends a transaction, and anyone can. eLyrium's service normally sends releases, dispute decisions and the creation of a vault after a full deposit, and pays the network fee, but does not promise to, and it does not send the transactions that return a short payment or a payment that arrived after the funding deadline. If nobody does, the money stays in the vault and can be moved later.
• Blocked or failed payments: each payment is pushed to its recipient when the order ends. If the token issuer blocks a recipient, or a transfer fails, that amount becomes a credit for the recipient and the rest of the order is still paid. Anyone can later send the credit to that recipient, and only to that recipient. If the vault then holds less than all its credits, the claim pays the recipient a pro-rata share of what the vault holds, rounded down, and the rest of that credit is written off. Up to 2 of the token's smallest units can stay in the vault when every share rounds to zero.
• Wrong token, wrong network, ETH, and money that arrives after the order has been released or refunded: the pilot vault has no function to return these, and they may be lost. See the Terms, section 8, and the Risk Disclaimer.

What eLyrium does and does not do

• eLyrium does not provide wallets and does not hold your wallet keys. You can use any EVM wallet. The optional agent kit can create an encrypted wallet file on your own machine. That key stays on that machine and is not sent to eLyrium. eLyrium does hold its own verifier key (it signs a dispute decision) and a transaction-service key (it submits transactions and pays network fees). Money for an order sits in that order's vault, not in an eLyrium account.
• eLyrium decides disputes. As the named verifier it can sign a decision for a disputed order, and only before the decision deadline. It cannot release an order early on its own, its verifier signature cannot release or refund an order that was not disputed (the release at the order deadline can be sent by anyone), and it cannot send a vault's money anywhere except the buyer address, the seller address and the fee address in the order's terms. It cannot pause, freeze, reverse or upgrade a vault.
• eLyrium earns its fee when an order is released, including when a dispute is decided for the seller or left unanswered, and earns nothing when it decides for the buyer. The contract cannot remove that incentive. See Terms, section 12.
• The token issuer can block addresses or pause the token, which can lock money. eLyrium cannot undo that.
• If the token or its issuer takes money out of a vault, nothing makes up the difference. A release pays the seller first, then the fee, then the buyer, each only up to what the vault holds. A refund returns what is available to the buyer, with no fee.
• eLyrium sets no spending limits. Any limit on an agent's spending comes from the wallet the operator uses. The API has two controls that are not spending limits. It refuses an order priced below a minimum order price. It can also slow a brand-new agent that places many orders in one day. That is an optional limit, off by default, and it is a limit on how many orders, not on how much money. There is no maximum order price.
• These are design statements. They depend on the deployed contracts matching the design, and the contracts are not independently audited.