# Owed > Owed is a PayBox plugin that lets your agent ask anyone for money, then tells you who has paid. Your agent asks one person, splits a bill or sends an invoice, in USDC, SOL or the user's own currency, and anyone can pay it from a Solana wallet, a Base wallet or their own PayBox agent. Before your agent pays, Owed checks the payee: a domain's DNS record or an .sns name on Solana. Everything runs on mainnet with real funds (Solana: USDC or SOL; Base: USDC). Owed never holds money and charges no fees: every payment goes from the payer's wallet straight to the recipient in one transaction. Owed is submitted to PayBox Chapter 1 and waiting for its listing in the PayBox plugin catalog. Once it is listed: connect PayBox to your agent as an MCP connector (https://api.paybox.sh/mcp) and turn on the Owed plugin in PayBox. Payments your agent proposes are approved by the user with a passkey in PayBox; Owed returns unsigned proposals and never signs anything. Owed is also a remote MCP server at https://www.getowed.xyz/api/mcp (Streamable HTTP, no auth): add that URL to any MCP client, or to PayBox as a remote plugin, to get every Owed tool. Each tool call runs the same plugin bundle PayBox runs, in a fresh process with a 10 second budget. It speaks MCP 2026-07-28 and accepts `initialize` from 2025-11-25, 2025-06-18 and 2025-03-26 clients; replies are JSON, with no session. `pay_link`, `pay_all`, `refund_payment` and `cash_out` return an unsigned PayBox transaction proposal; outside PayBox, sign and send it with your own wallet. ## Tools Owed has twenty-one tools. Eleven are in the PayBox portal build submitted at cecfbd2; `what_do_i_owe`, `pay_all`, `start_ledger`, `add_expense`, `ledger_balances`, `settle_up`, `refund_payment`, `start_pot`, `set_autopay` and `cash_out` are on the remote MCP endpoint above and go into the portal build with its next upload. So do these newer parts of the first eleven: funding plans and chip-in pots in `pay_link`, invoice terms in `create_invoice`, reminders due and statements in `who_owes_me`, overpayments in `match_payments`, refunds in `check_payments` and chasing the part of an invoice that is due now in `write_reminder`. `recipient` and `sender` are the user's own PayBox Solana wallet address (from PayBox's `list_credentials`), or for a Base request their Base (0x) address. - `ask_for_money`: create a payment request and get a short link, a QR code and a ready-to-send message that anyone can pay from a Solana wallet or their own PayBox agent. Inputs: `recipient` (a Solana address, an SNS name like `example.sns`, or a Base 0x address with `chain: "base"`), `amount` (decimal string), `token` (`USDC` or `SOL`), optional `currency` (ISO 4217, one of 38, never USD: `amount` is then in that currency and Owed locks the USDC at a live rate, rounded up; Solana USDC only), `chain` (`solana`, the default, or `base` for USDC on Base), `expires_in_days`, `payer_name`, `for`, `note`, `requester_name`, `from_domain`, `payer` (who should pay, so the request shows up in their `what_do_i_owe` inbox: `{handle, wallet}` with the Solana wallet PayBox `resolve_username` returned for the X handle, `{sns}` or `{wallet}`), `requester_handle` (the user's own X handle; payers see it as not verified by Owed). SNS names are resolved on Solana; `.sol` names are refused (SNS moved to `.sns`), as are tokenized names and lookalike characters. Examples: "ask Priya for 15 USDC for dinner", "ask Priya for ₹1,200 for dinner", "my wallet is bonfida.sns", "bill Alex 20 USDC on Base", "ask @sam for 10 USDC". - `check_payments`: check whether up to 20 requests have been paid, by reading Solana mainnet (and Base, for Base requests). Input: `requests` (Owed ids, Owed links or Solana Pay transfer URLs with a reference). Returns each one's status (`open`, `paid`, `underpaid`, `cancelled`, `expired`, `not_found`, `invalid`, `unknown`) with payer, amount and transaction when paid; a payment the recipient matched with `match_payments` is marked matched, and a payment sent back with `refund_payment` says `refunded` (with `refunded_in_full`) once Solana confirms it. Example: "did Priya pay?" - `pay_link`: pay someone's request (an Owed link or id, any Solana Pay transfer link or QR text, or an SNS name with `amount`; USDC or SOL). Checks the request is still open and the wallet can cover it, then returns an unsigned Solana transaction for the user to approve in PayBox. Inputs: `link`, `sender`, optional `max_amount`, `amount` (only for links without one), `allow_unverified`, `rail` (`solana_pay`, the default, or `x402`: pay an Owed USDC request at its x402 endpoint; PayBox pays it over x402 and the facilitator covers the network fee). Refuses checkout links (Solana Pay transaction requests, except Owed's own pot QR codes), paid requests and amounts above `max_amount`. Also pays a chip-in pot (its board link, its 14-character id or its QR text) with `amount` (or the pot's suggested amount): it checks the pot's id commits to the wallet it pays, that it hasn't ended and that it takes that amount, then makes one contribution right before proposing it. On the x402 rail it checks the request id and the live x402 challenge against the request before proposing the payment. A request made for an SNS name is paid only if the name still points to its wallet. A Base request is paid over x402 from the user's PayBox Base wallet (the facilitator pays the gas), never with a Solana transaction; when that can't be offered, the tool says how to pay it from a Base wallet. If the wallet can't cover it, it proposes nothing and returns a funding plan: the exact PayBox calls that fix it, best first (request_swap SOL→USDC sized at Pyth's price plus 1%; a Base→Solana request_swap to the sender's own wallet; a swap from another token; get_buy_link usdc_sol for the shortfall rounded up to the cent, at least 4.99; or rail x402 when only the fee is short), each ending with pay_link again with the plan's plan_id, plus the same plan as a ```json funding_plan block. Run PayBox check_operation_readiness before each step; the user approves each one. A refused request (paid, cancelled, expired, tampered, sanctioned, a payee that doesn't check out) never gets a plan. Input: optional `plan_id` (only when a plan says so). Example: "pay bonfida.sns 2 USDC". - `verify_payee`: check who a request is from: whether a domain publishes the wallet that gets paid, read from DNS by the plugin itself, or which wallet an SNS name points to on Solana. Inputs: `link`, or `address` and `domain`, or `name` (alone, with an address, or with a link). Verified means the domain or name points to the wallet; it shows who controls it, not that the request is fair. Lookalike spellings and internationalized names come with warnings. - `split_bill`: split a bill into one request per person plus a live board that shows who has paid. Inputs: `recipient`, `total`, `token`, `title`, `people` (2 to 20, each a `name`, an optional set `amount` and an optional `payer`, as in `ask_for_money`; the rest split evenly), optional `currency` (the bill is split in that currency and each share locked to USDC at one rate), `requester_name`, `from_domain`, `requester_handle`. Examples: "split 45 USDC for pizza between Priya, Sam and Alex", "split €45 for dinner". - `create_invoice`: create a printable invoice with line items, total, due date and invoice number, payable from any Solana wallet by QR or link, or by the client's PayBox agent. Inputs: `recipient`, `token`, `business_name`, `client_name`, `items` (1 to 20, each `description`, `quantity`, `unit_price`), `due_date` (YYYY-MM-DD), optional `currency` (unit prices in that currency; the total is locked to USDC), `invoice_number`, `notes`, `from_domain`, `payer` (the client, as in `ask_for_money`), `requester_handle`, and merchant terms: `installments` (`count` 2 to 12, `interval` `monthly` or 7 to 365 days; the first is due on `due_date` and payable at once, each later one opens as its own request 7 days before it is due, and the invoice shows Paid only when all are; refused with `currency`), `early_discount` (`amount` or `percent`, `until` a date: the invoice asks the early price until then and the full price after; paying one cancels the other; an invoice takes installments or an early discount, not both), `late_fee` (`amount` or `percent`: opened once as its own request the day after the due date, only if the invoice wasn't paid on time), `chase` (`{days}`, up to three, for a polite, firm and formal reminder; default 3, 7 and 14 days after the due date; `false` for none). No request ever changes its amount: each term that changes what is owed is a new request. Example: "invoice Acme for 3 hours of consulting at 40 USDC, due Friday", "invoice Acme 1,200 USDC in 3 monthly installments, with a 2% late fee". - `who_owes_me`: show who still owes the user money: every open Owed request, split-bill share and invoice that pays their wallet, plus what was paid in the last 30 days, with totals. Two calls: the first, with `recipient`, returns `message_to_sign`; the user signs it with PayBox `request_wallet_sign` (a passkey approval that moves no money); the second call passes `recipient`, `signed_message` and `signature`. The message is valid for 5 minutes and works once. Anyone can create a request that pays a wallet, so check names and amounts before chasing anyone. Overdue invoices carry `reminder_due` (polite, firm or formal on their chase days, with the exact `write_reminder` call; polite is its `friendly` tone); Owed sends nothing. `statement` (`client`, the name on the invoices or their wallet, and `month`, YYYY-MM) on the second call returns that client's monthly statement instead (invoiced, cancelled, expired, paid and refunded lines, opening and closing balance) with a CSV and a page link valid 10 minutes. Example: "who owes me?", "statement for Acme for September". - `write_reminder`: draft a reminder for someone who hasn't paid: `tone` (`friendly`, `firm` or `formal`) and `channel` (`sms`, `whatsapp` or `email`, which adds a subject), with the pay link and how many days it has been outstanding. Input `request`: an Owed id or link, one split-bill share's link, a split bill's board link (one message for the group naming who still owes) or an invoice link (names the invoice number and due date). It checks Solana first and returns no text if the request is already paid. For an invoice with terms it chases what is due now (the open installment or price), or says nothing is open. Owed sends nothing itself. Example: "remind Priya about dinner". - `ask_every_month`: ask someone for the same amount every month: stores a monthly schedule and opens a new Owed request on that day each month (UTC). Inputs: `recipient`, `amount`, `token`, `payer_name`, `for`, `day_of_month` (1 to 28), optional `months`, `requester_name`, `from_domain`, `payer` (as in `ask_for_money`; every month's request is addressed to them), `requester_handle`. If today is that day, this month's request opens right away. Each month's request is an ordinary Owed request that `check_payments`, `write_reminder` and `pay_link` work on; `who_owes_me` lists every schedule. Monthly requests are in USDC or SOL only (a rate locked today would be wrong next month). Example: "ask Sam for 450 USDC rent on the 1st". - `cancel_request`: cancel one of the user's own requests, split-bill shares or invoices so nobody pays it: its page shows Cancelled and `pay_link` refuses it. Two calls like `who_owes_me`: the first, with `link` and `recipient`, returns `message_to_sign`; the second passes `signed_message` and `signature`. Only the wallet the request pays can cancel it; a paid or partly paid request can't be cancelled. Example: "Priya paid me in cash, cancel her link". - `match_payments`: find payments the user received that Owed never counted (exchanges and some wallets drop the Solana Pay reference, so the money arrives but the request stays open or underpaid). `action` `find` (default): `recipient` plus `requests` (Owed links or ids), or no `requests` to search every open request after a signed ledger message (two calls like `who_owes_me`). Returns candidates: incoming transfers of exactly the amount still due, made after the request and not counted anywhere, each with a confidence, reasons and warnings (two requests with the same amount means Owed can't tell which one a transfer pays, and says so). It marks nothing. `action` `confirm`: `link` and `transaction`; the first call returns `message_to_sign`, the second passes `signed_message` and `signature`; the server re-checks the chain and the request shows "matched by the recipient (no reference on the payment)". `action` `ask_for_rest`: `link` of an underpaid request; creates one request for exactly what is still owed. `find` also lists `overpaid` requests (paid more than they asked), each with the `refund_payment` call that sends the difference back. Example: "Sam says he paid from Coinbase but it still shows open". - `what_do_i_owe`: the payer's inbox: every open Owed request, split-bill share and invoice someone addressed to the user's wallet (by their X handle, .sns name or wallet), oldest first, with who asked, what for, how long it has waited, due dates and totals per token and chain; Base requests are listed apart. Two calls like `who_owes_me`: the first, with `payer` (the user's own PayBox Solana wallet), returns `message_to_sign`; the user signs it with PayBox `request_wallet_sign`; the second passes `payer`, `signed_message` and `signature`. Only the wallet's owner sees its inbox. Anyone can address a request to anyone: names, handles and reasons are the requester's own words, unverified, and first-time requesters are marked. `block` (or `unblock`) with a requester's wallet, passed on both calls, hides (or shows again) every request from it without cancelling anything. `pay_all_ids` lists the Solana requests without a caution. Example: "what do I owe?" - `pay_all`: pay several Owed requests with one approval (one Solana transaction). Inputs: `sender`, `ids` (1 to 20 Owed ids or links, such as the ones from `what_do_i_owe` the user picked), `max_total` (the most USDC the user agreed to send in total), optional `max_total_sol` (SOL requests are paid only when it is set), `include_cautioned` (only when the user named requests that mention a brand word). Every request gets every check `pay_link` runs: the id hashes the server's terms, it is open and not expired, the recipient isn't sanctioned, a domain still publishes the wallet, an .sns name still points to it. Requests that fail, mention a brand word or are on Base are skipped with the reason. It refuses above `max_total` or when the wallet can't cover the total plus fees. One transaction holds 1,232 bytes (about 6 to 9 payments), so it pays the first ones and lists the ids left for the next call. When a request carries the requester's X handle, the preview ends with a handle check: call PayBox `resolve_username` and don't approve if it resolves to a different wallet than the request pays. Short of the total, it returns a funding plan for exactly the requests that passed the checks (as `pay_link` does, without the x402 option: it is one Solana Pay transaction). Optional `plan_id`. Example: "pay them all". - `start_ledger`: start a group ledger for a trip, a house or any shared costs: a running tab that `settle_up` later turns into the fewest Owed requests. Inputs: `owner` (the user's own PayBox Solana wallet; the user is the first member and is paid there), `owner_name`, `title`, `members` (1 to 19 others, each a `name` and an optional `payer` as in `ask_for_money`: `{handle, wallet}` after PayBox `resolve_username`, `{sns}` or `{wallet}`). A member without a wallet can still owe (they get a plain pay link) but can't be paid through Owed. Returns `ledger_id` and the ledger's page. Nothing is owed and nothing lands in anyone's inbox until expenses are added and someone settles up. Example: "start a tab for our Lisbon trip with Priya, Sam and Alex". - `add_expense`: record who paid what in a ledger and how it splits. Inputs: `ledger_id`, `signer` (the user's own PayBox Solana wallet: the owner's or a member's in this ledger), `paid_by` and members by the names the ledger lists, `amount`, optional `currency` (`USDC`, the default, or one of 38 ISO 4217 codes: each share is then locked to USDC at one live rate, rounded up), `description`, `split`: `even` (everyone, or `among`), `shares` (`[{member, shares}]`), `exact` (`[{member, amount}]`) or `items` (a receipt the agent reads itself: every line with who had it, plus `tax` and `tip`, spread over each person's items). Splits are exact in the smallest unit; leftover units go to the first members. Two calls like `who_owes_me`: the first returns who owes what and `message_to_sign`; sign it with PayBox `request_wallet_sign`; call again with the same arguments plus `signed_message` and `signature` (5 minutes, once). Example: "I paid 84.60 EUR for dinner, split evenly". - `ledger_balances`: read-only, no signature. Input: `ledger_id`. Each member's paid, share and net in USDC (the ledger's local currency beside it), the fewest payments that would square everyone, and every settle-up request with its live status. The plugin re-derives every split, balance and the plan, and checks every recorder's signature, before it shows a number; names and descriptions are the members' own words. Example: "who owes what on the trip?" - `settle_up`: turn a ledger's balances into Owed requests: the largest debtor pays the largest creditor until everyone is square, so n people need at most n − 1 payments. Inputs: `ledger_id`, `signer` (the owner's or a member's wallet in the ledger), then `signed_message` and `signature` (two calls like `add_expense`; the signature covers the ledger's version, the number of requests and their USDC total, so it can't settle a ledger that changed since). Each payment is one ordinary Owed USDC request, payable straight to the person owed and addressed to the person who owes it, so it lands in their `what_do_i_owe` as " settle-up". Someone owed who has no wallet in the ledger is listed and skipped. Paid requests count as settled, open ones as pending, cancelled or expired ones as owed again. Example: "settle up the trip". - `start_pot`: start a chip-in pot paid straight to the user's own wallet: a gift, a team dinner, a trip kitty. Inputs: `recipient`, `title`, optional `token` (`USDC`, the default, or `SOL`), `target`, `suggested_amount`, `any_amount` (default true; false takes only the suggested amount and the presets), `x402_presets` (up to 4 USDC amounts, each payable over x402 at its own URL), `deadline` (ISO time) or `deadline_days` (1 to 90, default 30: every pot ends), `note`, `requester_name`, `requester_handle`. Returns the board link (`/pot/`), its QR codes (Solana Pay transaction requests: each scan makes its own contribution, so every one is counted once) and the x402 preset URLs. The pot's id is a hash of the wallet, the token and a nonce the server returns; the tool refuses a reply that doesn't hash. Anyone pays it with `pay_link` and an amount; the board shows the total against the target. Past the deadline every way to pay refuses. Example: "start a pot for Ana's leaving gift, 10 USDC each, target 200". - `set_autopay`: one-tap monthly pay within the user's rule. A payer signs a rule for one requester's wallet: `max_per_request`, `max_per_month` (USDC) and an end (`ends` YYYY-MM-DD, or `months`). Inputs: `payer` (the user's own PayBox Solana wallet), `requester` (`{wallet}`, `{handle, wallet}` after PayBox `resolve_username`, or `{sns}`, resolved on Solana), the limits, then `signed_message` and `signature` (two calls like `who_owes_me`); `revoke` (a rule id, on both calls) ends one. The rule matches the requester's wallet only. `what_do_i_owe` then marks each request `eligible`, `over_limit` or `not_covered` (the month cap counts this month's payments and earlier eligible lines; x402 needs the requester's USDC account) and, for eligible ones, hands over the exact PayBox `pay_x402` call (accepts copied from the request's live 402, checked against the user's signed rule) plus a `pay_link` x402 fallback. Owed never pays anything itself: run the call only inside the user's PayBox limits; if PayBox asks for approval it is one tap a month; over-limit requests are never paid automatically. Example: "pay my landlord's rent request each month, up to 1,500 USDC". - `cash_out`: cash out USDC to the user's bank through MoonPay. Switched off on production until MoonPay live keys are set; it says so. First call (`wallet`, `amount` or `request_ids`, optional `fiat_currency`): MoonPay's sell link for the exact amount, refunds to the wallet. The user finishes MoonPay's checks and starts the sale; second call (`wallet`, `cash_out_id`, `amount`): once MoonPay waits for the deposit, one unsigned USDC transfer from the wallet to the deposit address MoonPay named for that sale, to approve in PayBox. No input takes an address. Example: "cash out the 50 USDC Priya paid me". - `refund_payment`: refund all or part of a payment the user received through Owed: one Solana transfer (USDC or SOL) from the user's wallet back to the wallet that paid the request. Inputs: `link` (the paid request's Owed link or id), `recipient` (the user's own PayBox Solana wallet, the one the request paid), optional `amount` (leave it out to refund everything still refundable), then `signed_message` and `signature`; `refund_id` re-proposes a refund that is still pending. Two calls: the first checks the request is paid to this wallet, how much can still be refunded and who paid, and returns `message_to_sign` (as text with a ```json block, marked as an error because the tool's output schema is PayBox's proposal envelope; nothing moves); the user signs it with PayBox `request_wallet_sign`; the second call returns an unsigned transfer to the payer to approve in PayBox. Refunds never add up to more than was paid, and count once Solana confirms the transfer. Card (MoonPay) and hand-matched payments can't be refunded here. Example: "refund Priya the 5 USDC she overpaid". ## Asking by X handle Owed can't resolve X handles. To ask `@sam`, call PayBox `resolve_username` first, tell the user which Solana wallet the handle resolved to, then pass `payer: {handle, wallet}`. The request shows up in Sam's `what_do_i_owe` inbox, and Sam's agent can pay it there with `pay_link` or `pay_all`. Handles are labels: Owed checks their format and never treats them as verified. The payer is not part of the request id, so ids and the tamper check are unchanged. One transfer settles one request, so a `pay_all` transaction that pays two requests to the same recipient for the same amount counts each once. ## Short balances When the user's wallet can't cover a payment, `pay_link` and `pay_all` return a funding plan instead of a proposal: what the wallet holds, the shortfall, and the PayBox calls that fix it, best first, each step for the user to approve in PayBox, the last one always the same pay call with the plan's `plan_id`, which re-runs every check. Owed can't move money or call PayBox tools itself. Its server records that a plan was offered (sender, request ids, shortfall, option kinds; never balances) and whether it ended in a payment: `GET https://www.getowed.xyz/api/v1/plans/stats`. ## Chip-in pots A pot (`start_pot`) collects contributions for one wallet. Each contribution is an ordinary Owed request (its id hashes its own terms) made when someone pays: a scan of the board's QR code (`solana:https://www.getowed.xyz/api/v1/pay/?amount=`), "Get my link" on the board, a verified x402 payment at `/x/pot//`, or `pay_link`. Nothing is made when a page loads. A contribution expires at the pot's deadline or 24 hours after it was made, whichever is first; a payment that lands anyway still counts, because the chain is the truth. Nobody is ever shown as owing a pot. ## Paid alerts `https://www.getowed.xyz/alerts` links a Telegram chat to the Solana wallet the user's requests pay, after that wallet signs `Owed alerts for at ` (a browser wallet, or PayBox `request_wallet_sign`). The chat then gets one message per request paid to that wallet, on every rail; `/stop` turns it off. The bot is @getowedbot (https://t.me/getowedbot). Email alerts aren't switched on. ## Verified payee A requester proves a domain by publishing their wallet in DNS: a TXT record named `_owed.` with the value `owed-pay=` (one record per wallet). `ask_for_money`, `split_bill` and `create_invoice` take an optional `from_domain`; Owed checks the record before creating the request and the pay page shows "From · verified". Before `pay_link` pays a request that names a domain, the plugin reads the record itself (DNS over HTTPS, cloudflare-dns.com then dns.google) and refuses a wallet the domain doesn't list. Example: `_owed.getowed.xyz` TXT `owed-pay=FN6G4CQkrM55pnT4npu1U8xegZk7AMnp3ApGvkM4cbvs`. ## SNS names An SNS name (`example.sns`, Solana Name Service) can stand in for a Solana wallet: as `recipient` in `ask_for_money`, as `link` in `pay_link` and as `name` in `verify_payee`. Owed resolves it on Solana itself (the name's SOL record, else its owner). The server re-resolves it when a request is made, the pay page on every render ("To example.sns · verified on-chain"), and `pay_link` before every payment. `.sol` names are refused: in August 2026 SNS moved its names to `.sns`, and `.sol` isn't resolvable today. ## Payments without the reference A payment counts only when it carries the request's Solana Pay reference. The pay page's QR is a Solana Pay transaction request (`solana:https://www.getowed.xyz/api/v1/pay/`), so a wallet that scans it signs a transaction Owed built with the reference inside. Exchanges and plain sends don't carry it: `match_payments` finds those and counts one only after the recipient signs that it is theirs. ## Pages - [Home](https://www.getowed.xyz/): what Owed does and how to add it in PayBox. - [Proof](https://www.getowed.xyz/proof): real mainnet payments made from the Owed team's own wallets on every rail (Solana Pay QR, x402, Base), each with its transaction, and what Owed refuses. - `https://www.getowed.xyz/r/`: a request's pay page: QR code, wallet button, live status, receipt once paid. - `https://www.getowed.xyz/g/`: a split bill's board, "N of M paid". - `https://www.getowed.xyz/i/`: a printable invoice; with terms, its installments, both prices, the late fee, refunds and what is due now. - `https://www.getowed.xyz/l/`: a group ledger: members, balances, settle-up requests with live status, and each expense with its recorder's signed message. - `https://www.getowed.xyz/pot/`: a chip-in pot's board: the total against the target, every contribution with its transaction, printable QR codes, and nothing to pay once it has ended. - `https://www.getowed.xyz/alerts`: paid alerts in Telegram (@getowedbot) for the wallet a user's requests pay. - `https://www.getowed.xyz/x/`: the request as an x402 endpoint: any x402 agent can pay it (HTTP 402 with the payment terms). A pot's presets are at `/x/pot//`. - `https://www.getowed.xyz/api/v1/pay/`: the request as a Solana Pay transaction request (what the QR encodes): a wallet fetches the transaction and signs it. ## Read-only API JSON, no auth. Errors are `{"error":{"code","message"}}`. - `GET https://www.getowed.xyz/api/v1/requests/`: a request's terms, status and payment. - `GET https://www.getowed.xyz/api/v1/requests?ids=,`: 1 to 20 requests, each in the shape above, in the order asked; unknown ids in `not_found`. - `POST https://www.getowed.xyz/api/v1/status` with `{"ids":[...]}` (up to 20): current status, checked against the chain. - `GET https://www.getowed.xyz/api/v1/stats`: count and USDC volume of paid requests. - `GET https://www.getowed.xyz/api/v1/plans/stats`: funding plans offered, used and paid (`{offered, used, paid, since}`). - `GET https://www.getowed.xyz/api/v1/ledgers/`: a group ledger: members, expenses with their signatures, balances, the settle-up plan and each settle-up request's status (`?chain=0` skips the chain check). - `GET https://www.getowed.xyz/api/v1/refunds/`: one refund and whether Solana has confirmed it. - `GET https://www.getowed.xyz/api/v1/pots/`: a chip-in pot: its terms (with the nonce its id hashes), the total raised, the contributions and the payment links. ## Source - [GitHub: rajkaria/owed](https://github.com/rajkaria/owed): the plugin (`plugin/`) and this site (`web/`).