2381 lines
232 KiB
Text
2381 lines
232 KiB
Text
# Morphit — complete FAQ (English)
|
||
|
||
> Non-custodial peer-to-peer fiat↔BTC/XMR/BLURT/USDT/USDC/DAI/BCH/LTC/DASH/DOGE/ZEC/ARRR/DCR/SOL/ETH/XRP marketplace.
|
||
> No KYC. No custody. No arbitration. Federated, open-source.
|
||
> Translations available at https://morphit.io/faq?lang=<code>
|
||
> where <code> ∈ {en, es, de, pl, fr, it, ru, fa, zh-CN, zh-HK}.
|
||
|
||
---
|
||
|
||
## Why does Morphit use the AGPL-3.0 license?
|
||
|
||
**FAQ key:** `why_agpl`
|
||
|
||
So that no one — not a corporation, not a government, not even us — can take Morphit, lock it up, and quietly turn it against the people using it. The license guarantees that every running copy of Morphit stays open and inspectable. Everything else here is built on that.
|
||
|
||
**The one rule it adds.** If you run Morphit as a public service and you change the code, you have to share your changes with the people using it. That's the whole deal. Run an instance, rebrand it, rewrite every word on the screen, add features, charge for it — all fine, and encouraged. The only thing you can't do is run a *secret, modified* version. If your instance can reach users, your users can read its source. For a privacy tool that's the whole game: it's how anyone can confirm the instance they're on is the real Morphit and not a backdoored look-alike. Freedom you can't verify is just a promise — this turns it into something you can check.
|
||
|
||
**Why not a "freer" license?** Permissive licenses (MIT, BSD, Apache) ask for nothing in return, which sounds freer — until you notice it also lets anyone take Morphit, bolt on hidden tracking, close the source, and sell it back to your neighbors as a polished surveillance app, with no one the wiser. A license that permits your own capture isn't protecting your freedom; it's protecting whoever wants to cage you. The plain GPL has the same hole for network software: it only triggers when you hand someone a program to download, not when you run a modified copy on your own server — which is exactly how people use Morphit. The AGPL closes that hole. And no license at all is the worst of the lot: say nothing, and copyright law defaults to *all rights reserved* — no one may legally fork it or run their own instance. Silence isn't freedom; it's a locked door.
|
||
|
||
**For agorists especially.** Here's the honest tension: the AGPL leans on copyright, and copyright is a creature of the State. The purist position is to claim nothing — drop it into the public domain and walk away. We think that hands a gift to the exact people you're trying to escape: the well-funded actors who'll take it, close it, wire it into the surveillance machine, and call it convenient. Pure intentions, captured tool. Copyleft is the judo move — it takes the State's own instrument and turns it against enclosure. We're not begging the State for protection; we're using its own rules to make this commons permanently un-takeable. Every fork stays open. Every instance stays inspectable. Nobody gets to build a cage out of our code. That's not making peace with the system — it's the system finally working for the counter-economy instead of against it.
|
||
|
||
**The bigger picture.** The point was never to win an argument with the beast — it's to make it obsolete. The more people who run their own instances, and talk others into running even more, the less there is for any central power to control: tools it can't surveil, markets it can't see, exchange it can't tax or stop. That's what renders the apparatus pointless. It won't be graceful — when control slips, the first reflex is always to grab harder, with more rules and more force. But coercion is expensive and futility is exhausting, and sooner or later the beast does what bullies do once no one's afraid: it loses interest and goes off to find something more productive to do. So fork Morphit. Make it yours. Stand up an instance, and talk three friends into standing up three more. The license is here to guarantee one thing — that every one of those instances stays free, open, and impossible to quietly turn against the people who use it.
|
||
|
||
*Morphit is released under the GNU Affero General Public License, version 3. This is our reasoning, not legal advice.*
|
||
|
||
---
|
||
|
||
## What is Morphit?
|
||
|
||
**FAQ key:** `what_is_morphit`
|
||
|
||
Morphit is a P2P marketplace where people trade cash for cryptocurrency (Bitcoin, Monero, Blurt, USDT, USD Coin (USDC), Dai, Bitcoin Cash, Litecoin, Dash, Dogecoin, Zcash, Pirate Chain, Decred, Solana, Ethereum, and XRP) directly with each other. Barter goods/services too. Morphit never touches your assets and never asks anything about you. It's a bulletin board service (BBS), not a bank.
|
||
|
||
---
|
||
|
||
## Is it safe?
|
||
|
||
**FAQ key:** `is_it_safe`
|
||
|
||
Much safer than platforms that hold your funds — because Morphit can't lose or freeze what it never had. The real risk is your trading partner, so always check their reputation score before agreeing to trade.
|
||
|
||
Reputation is everything; even when the only thing that Morphit "knows" about them is that their name is @scooby. If you want to build your reputation around the name @dingleberry, go for it. Morphit shows the completed trades, feedback, and how long a user has been around.
|
||
|
||
---
|
||
|
||
## How is Morphit different from LocalBitcoins or LocalMonero?
|
||
|
||
**FAQ key:** `vs_others`
|
||
|
||
Short version: Morphit goes further on decentralization, privacy, and non-custody than either of them — and deliberately does less in exchange.
|
||
|
||
LocalBitcoins (RIP, 2023) and LocalMonero (closed 2024) were centralized companies with custodial escrow. When a trade went wrong, their human arbitrators held the coins and decided who got them. When the companies shut down — by regulator pressure or business decision — their entire user base, reputations, dispute history, and ongoing trades vanished overnight. Morphit cannot be shut down in the same way: there are no central arbitrators, no custodial wallets, no company bank account to freeze. Every order lives on-chain, every trade is peer-to-peer, and anyone can run an indexer or frontend. Multiple instances on four networks (clearnet, Tor, Lokinet, I2P) mean blocking one node does nothing.
|
||
|
||
On privacy: Morphit pushes harder than either of them on transport, storage, and chat.
|
||
• Transport: four parallel networks, all first-class (not just an 'onion mode').
|
||
• Storage: nothing about you lives on Morphit's servers — keys are in your browser, orders are on-chain, chats are on-chain as ciphertext only. You can move to any device with just your 12-word seed.
|
||
• Chat: end-to-end encrypted using X25519 key agreement plus ChaCha20-Poly1305 (from libsodium), with a per-message ephemeral key. LocalBitcoins/LocalMonero chats were visible to staff. Morphit chat is encrypted on your device, stored as ciphertext on the blockchain, and decryptable only by the two participants — operators and chain observers see nothing. We deliberately chose a simple, fast, low-bundle-weight ECIES design.
|
||
|
||
On non-custody: LocalBitcoins/LocalMonero held your coins during a trade. Morphit never touches them at any point, period — the seller sends directly to the buyer when payment is confirmed. That is more trust placed on reputation, less on cryptography; honest about the tradeoff.
|
||
|
||
On arbitration: LocalBitcoins/LocalMonero arbitrators could overrule feedback. Morphit has no arbitrator role at all; feedback is permanent and signed on chain. If you scam someone, your public key carries that feedback forever; you cannot appeal to a human. That's a strong disincentive for repeat scammers and zero protection for first-time ones — hence the emphasis on checking account age and reputation.
|
||
|
||
What Morphit doesn't have that they did: escrow, human arbitration, per-market moderation. **Morphit will never offer any of these.** Reintroducing escrow, multisig, or arbitration would reintroduce the middleman this project exists to remove. Morphit's advantage is that it's lean, portable, browser-native, fully decentralized at every layer, and impossible to shut down — and its tradeoff is that you trade on immutable, provable reputation.
|
||
|
||
---
|
||
|
||
## How is Morphit different from BasicSwap?
|
||
|
||
**FAQ key:** `vs_atomic_swap_dexes`
|
||
|
||
BasicSwap is a kindred project in the no-middleman peer-to-peer space, but it makes different architectural choices than Morphit. It does cross-chain atomic swaps directly between two wallets — no escrow, no arbitrator, no central server. We're aligned on the principle; the tradeoffs differ.
|
||
|
||
• **You have to install it first.** BasicSwap is a desktop app or Docker setup: you install and run it before you can even browse the orderbook. Morphit's orderbook is a public web page on any instance, browsable from any phone without installing anything.
|
||
|
||
• **It runs full nodes.** BasicSwap typically runs a full node for every chain it trades — Bitcoin, Monero, Litecoin. First sync takes hours to days, and storage, CPU and bandwidth costs continue. Morphit is a browser tab.
|
||
|
||
• **Swaps are slow, and both parties must stay online.** A cross-chain atomic swap needs confirmations on both chains; a BTC ↔ XMR swap typically locks coins for 30 minutes to several hours. Both wallets must be live for the whole multi-step exchange — if your counterparty disappears mid-swap, you wait out the refund timelock to get your coins back. Morphit trades need no simultaneous presence: you post an order, the other party acts when they're ready. Coordination finalizes on the next block, about 3 seconds. (Settlement of the underlying asset still takes whatever the chosen chain or payment method takes — Morphit doesn't claim otherwise.)
|
||
|
||
• **Crypto-only, no fiat.** BasicSwap trades crypto for crypto. Morphit also does fiat ↔ crypto in whatever payment method two people agree on — bank transfer, cash, gift card, in-game currency — plus barter (gold bars, banana trees, whatever).
|
||
|
||
• **No reputation, no chat.** BasicSwap has no network-wide feedback system and no messaging layer; negotiation happens somewhere else. Morphit feedback is signed on-chain and follows your public key across every instance, and chat is end-to-end encrypted on your device, stored as ciphertext on the chain.
|
||
|
||
**On the July 2026 exploit.** BasicSwap was exploited on 14 July 2026, with confirmed losses of more than 0.66 BTC (about $42,000 at the time), reported by the project's own developer @ofrnxmr and by Orangefren. We mention it because anyone choosing between two ways to trade should know it happened — not to score a point. Atomic swaps are still a beautiful piece of cryptographic engineering, and the idea is not what broke. Morphit has no room to gloat here either: we are software, we have bugs, and the honest difference is architectural rather than moral. Morphit never takes custody of your coins, so there is no pot for an attacker to drain — but a bug in our code could still cost you a trade, and we would rather say so plainly than pretend otherwise.
|
||
|
||
Both designs are valid. They serve different users.
|
||
|
||
---
|
||
|
||
## How is Morphit different from Bisq or Haveno/Retoswap?
|
||
|
||
**FAQ key:** `vs_bisq_haveno`
|
||
|
||
Bisq and Haveno (and Haveno's fork Retoswap) are the closest projects to Morphit in spirit — non-custodial, peer-to-peer, no KYC. Haveno is itself a fork of Bisq, so the two share the same underlying design; here's how each compares to Morphit.
|
||
|
||
**Bisq** is a long-running peer-to-peer marketplace with the same architectural pattern as Haveno: desktop Java application, 2-of-3 multisig escrow during trades, Tor for transport, arbitrated disputes when something goes wrong. Bisq has been compromised twice with user funds stolen — the kind of risk Morphit avoids by never touching user funds in the first place. Bisq also requires you to lock up BSQ collateral before you can list orders. Morphit locks up nothing from anyone.
|
||
|
||
Haveno (and its fork Retoswap) is much closer in spirit — non-custodial, P2P, no KYC. The big differences: Haveno is a desktop-only Java/JavaFX application tied to the Monero blockchain for its 2-of-3 multisig escrow, and needs you to run (or connect to) a seednode. Morphit runs in any browser, on any phone, with no install; uses Blurt (not Monero) for its on-chain coordination layer, which is faster and far cheaper per action (~free vs. Monero's per-op fees); and ships with built-in Tor, Lokinet, and I2P reachability rather than relying on you to configure it. Haveno trades involve arbitrated escrow, which is strong but requires trusted arbitrators per market. Morphit v1 is pure reputation-based bulletin board — no escrow, no arbitrator, full responsibility on the traders to pick partners with real track records. That's a more conservative safety model, but also fewer centralized choke points and no arbitrator role that a government could pressure.
|
||
|
||
On May 20, 2026 the Haveno trade protocol was exploited for approximately $2.7 million. The attack used a forged out-of-order acknowledgment message from a fake arbitrator to redirect the 2-of-3 multisig wallet address before user funds were deposited; RetoSwap halted trading the same day. Morphit's design has no arbitrator role, no multisig escrow, and no central coordination message Haveno's exploit relied on — so this attack class doesn't apply to our threat model. The tradeoff is real and stated above: Morphit users carry full self-custody and lean on signed on-chain reputation rather than an arbitrator's safety net.
|
||
|
||
Then, on June 16, 2026, the Haveno protocol was exploited a second time in under a month — this time through its dispute-resolution and forced-arbitration path. An attacker posing as a buyer forced a dispute and had the seller's XMR released after the Bitcoin side showed its confirmations, without ever actually sending the BTC; early tracking by orangefren put the loss around 1,500 XMR (roughly $500,000), and RetoSwap again suspended trading and raised the minimum client version. Two protocol-level exploits in under thirty days — both in the arbitration and dispute machinery — are the clearest illustration of the tradeoff above: an arbitrator-and-escrow safety net is also an attack surface. Morphit has no arbitrator, no forced-arbitration step, no dispute payout, and no multisig escrow — so neither the May acknowledgment-spoofing attack nor the June dispute-forgery attack has anything to target in our model.
|
||
|
||
---
|
||
|
||
## How is Morphit different from OpenMonero?
|
||
|
||
**FAQ key:** `vs_openmonero`
|
||
|
||
OpenMonero (a LocalMonero clone) is a custodial platform, and it has lost user funds more than once. On June 6, 2025, a misconfigured firewall and wallet-rpc combination drained roughly 77.85 XMR (about $25,225) from the platform's internal custodial wallet; OpenMonero says it has since refunded affected users out of trading fees, a process that ran for about a year, with vendors prioritized. On May 21, 2026 — one day after the first Haveno exploit — OpenMonero posted a fresh exploit alert and told users to halt all payments while it investigated. Morphit has no custodial wallet at all; your XMR never sits on a Morphit server, so this entire attack class has nothing to steal. The pattern across the sector is consistent: platforms that hold user funds in an internal wallet tend to get drained eventually. Morphit's answer is to not hold them in the first place.
|
||
|
||
OpenMonero went offline briefly in early June 2026 and then returned later that month, saying it is more secure "this time" and pointing to new server-side hardening such as runtime encryption, hardened deployments, and memory encryption. That kind of hardening protects OpenMonero's own custodial wallet and servers — but it doesn't change the fact that there is a custodial wallet there to protect, and to lose. Morphit's difference is structural, not a matter of degree: there is no Morphit wallet, so there is nothing to harden, nothing to drain, and no operator who could quietly go offline holding your coins. The seller sends XMR straight to the buyer once payment is confirmed, and Morphit never touches it. Morphit is also fully open source with zero code obfuscation — every line that runs in your browser is published and auditable — whereas OpenMonero obfuscates parts of its code, so you cannot fully check what it does with your funds.
|
||
|
||
---
|
||
|
||
## Is there a video tutorial?
|
||
|
||
**FAQ key:** `video_tutorial`
|
||
|
||
Yes — we host short video tutorials on Blurt.media, a decentralized PeerTube/Peerhub instance, also syndicated to the Fediverse and multiple networks. Watch at https://blurt.media (search for "Morphit"). We link out rather than embed because video embeds come with trade-offs for privacy: a PeerTube iframe would expose your IP to other viewers in the P2P swarm. Opening Blurt.media in a new tab keeps you in control. If you use a VPN or Tor Browser (recommended), your IP is already protected and the embed trade-off disappears.
|
||
|
||
---
|
||
|
||
## What do I need to sign up?
|
||
|
||
**FAQ key:** `signup_requirements`
|
||
|
||
Nothing. No email, no phone number, no name. Your browser generates a cryptographic keypair on your device — that is your entire account. Write down the 12-word recovery seed and you're done.
|
||
|
||
---
|
||
|
||
## How do I buy crypto?
|
||
|
||
**FAQ key:** `how_to_buy`
|
||
|
||
Open the orderbook and Filter it by the cryptocurrency that you want. Pick a seller with a good reputation, click the Message button to respond to their post and in the chat you two agree on the details. You then pay the seller at least the minimum value amount (cash, crypto, bank transfer, barter, etc) as per your agreement. You provably send the funds (or complete the barter agreement) and then the crypto seller sends the crypto directly to your crypto wallet. Leave each other a Feedback review and you're done!
|
||
|
||
---
|
||
|
||
## How do I sell crypto?
|
||
|
||
**FAQ key:** `how_to_sell`
|
||
|
||
Post an order listing what you're selling — Bitcoin (BTC), Monero (XMR), or BLURT — where you are, and which payment methods you accept. A buyer will open a chat with you to agree on details. When you confirm you received their payment, you send them the crypto (or whatever you guys agreed to exchange). Leave honest feedback when done — it helps everyone.
|
||
|
||
---
|
||
|
||
## What are the fees?
|
||
|
||
**FAQ key:** `fees`
|
||
|
||
Three things to know:
|
||
|
||
1. Morphit never takes a cut of your trade itself. The price you and your counterparty agree on is the price you receive — nothing is skimmed. Morphit isn't an escrow and doesn't touch your funds.
|
||
|
||
2. Posting an order costs a small network fee:
|
||
• **$0.25 USD-equivalent** if you pay in BTC or XMR (full price)
|
||
• **$0.125 USD-equivalent** if you pay in Blurt (a deliberate 50% discount)
|
||
The discount exists because Morphit's coordination layer runs on Blurt's blockchain with 3-second confirmation times. Paying in Blurt is the default option, costs half as much, and counts toward loyalty-milestone Blurt Power (BP) rewards (see "How loyalty rewards work"). The compose screen shows the exact amount in your chosen currency before you sign — no surprises.
|
||
|
||
3. Your very first buy order is free. We waive the network fee on your first-ever buy — a small welcome gift so new traders can try Morphit risk-free. See "Is my first order really free?" for the details.
|
||
|
||
There's also an optional "featured" slot you can bid on if you want your order to stand out — a per-hour cost that you only pay if you actively want the visibility.
|
||
|
||
A note on the spam-deterrent escalation: post a lot of orders quickly (4+ in a 24-hour window) and the per-order fee starts climbing. This is the anti-Sybil tier — it bites spammers far more than real users, who rarely post more than 2-3 listings in a day. The compose screen shows you the current tier multiplier before you sign so there's no surprise. The Sybil escalation only applies to Blurt-paid orders; BTC and XMR fees are flat at the base rate.
|
||
|
||
---
|
||
|
||
## Can I trade goods or services on Morphit, like fruit trees or vintage records?
|
||
|
||
**FAQ key:** `trade_goods_services`
|
||
|
||
**Yes — and for some people, this is the whole point of Morphit.** If you're unbanked, living under capital controls, or watching your national currency lose value by the week, being able to turn your goods and your labor directly into hard money — without asking a bank's permission — isn't a convenience, it's a lifeline. That's counter-economics in practice: ordinary people anonymously trading peer-to-peer in a free market, outside the gatekeepers. Morphit is built for exactly this.
|
||
|
||
How it works: **every Morphit order has a tradable coin on one side (BTC, XMR, Blurt, or any asset Morphit lists), and whatever you agree on for the other side** — a national currency, a different coin, or **goods and services.** To trade goods or services, choose the `Barter (goods/services)` payment method and describe the deal in the `terms` field.
|
||
|
||
*Example 1 — selling orange trees for Monero:* Go to the Post page, then click on `I want to BUY`. Select Monero (XMR). Select which fiat currency you would normally sell those trees for such as Pesos, Euros, Dollars, etc. Select the `Barter (goods/services)` payment method. Set your Terms, for example: `"$20 per orange tree at least 1-2m tall. Pick them up at my farm (or advise me on your location address for shipment ($5 more per tree))."` Anyone holding XMR who wants your trees can accept your offer.
|
||
|
||
*Example 2 — selling your mobile car wash service for Monero:* Same process, but in the Terms field you might say something like this: `"I'll come to your business and wash your car. I charge $30 per car. Dry and wax for an additional $20. See my ad in the local newspaper! Wash Boy, Inc."`
|
||
|
||
**The one rule:** one side must be a coin that Morphit supports. That's what gives every trade a real, on-chain receipt and lets honest traders build a reputation that travels with them — the trust a free market runs on.
|
||
|
||
---
|
||
|
||
## How do I trade cash by mail or ship physical goods through Morphit?
|
||
|
||
**FAQ key:** `cash_by_mail_walkthrough`
|
||
|
||
Cash-by-mail and shipped-goods trades work like any other Morphit trade, with two extra chat tools:
|
||
|
||
**1. Mailing-address share.** In the chat composer, tap **"Share mailing address"**. The form has fields for country, street, city, postal/ZIP code, optional state/province, optional recipient name, optional second line (apt/suite), and an optional note. Your address stays end-to-end encrypted in chat — only you and your trade partner can read it. It is **never** written to the indexer, on-chain, or anywhere federation-readable. The privacy aside in the modal reminds you that sharing is irreversible (once sent, your partner has it even if you clear the message later) and suggests using a P.O. box, mail-drop service, or virtual mailbox if you don't want to share your home address.
|
||
|
||
**2. Shipment record.** After you mail the cash or the goods, tap **"Record shipment"** in the chat composer. Pick a carrier from the dropdown (USPS, UPS, FedEx, DHL Express, Royal Mail, La Poste, Deutsche Post, Poste Italiane, Correos, Poczta Polska, Pochta Rossii, China Post EMS, Hongkong Post, Japan Post, Australia Post, Canada Post, India Post, Iran Post, SF Express, Aramex, or **Other** with a free-text name + tracking URL), enter the tracking number from your receipt, and optionally add a note ("Shipped today, ETA Friday"). Your partner sees a **📦 Shipped via X** pill in chat with a clickable "Track package" link. Tracking number is optional — submit without if you used untracked mail — but recommended as proof of shipment.
|
||
|
||
**Safety tips for any physical shipment** (shown in the modal aside):
|
||
|
||
- Use a tracked, **insured** service. If the package is lost or stolen, insurance is your only recourse.
|
||
- Use a **plain envelope or box** with no markings suggesting valuables inside.
|
||
- **Return address tradeoff**: omitting your return address preserves anonymity but means undeliverable mail gets destroyed. There's no right answer; pick based on your threat model.
|
||
- Tracking number is optional but strongly recommended.
|
||
|
||
**If you're mailing CASH** (collapsible expander in the modal):
|
||
|
||
- **Wrap the cash in aluminum foil inside the envelope.** This defeats people holding envelopes up to bright light to see contents — a well-known soft attack on mailed paper currency.
|
||
- **UPS and FedEx PROHIBIT cash shipments in their terms of service.** If they open the package, they can confiscate it with no recourse. Use a postal service instead (USPS, Royal Mail, Deutsche Post, La Poste, etc.).
|
||
- **International**: don't lie on customs declarations. High-value cash will be seized regardless of how it's declared.
|
||
|
||
**For sellers receiving tracking numbers — sanity-check spoofing.** A scammy buyer could paste any random tracking number. Before you ship crypto, look up the tracking number on the carrier's site (📋 Copy the number from the pill, then paste into the carrier's tracker via your normal browser or Tor) and **verify the destination ZIP code matches your actual ZIP**. If a number resolves to a package being delivered to someone else's city, the buyer is trying to scam you.
|
||
|
||
**ELI5 for grandma:**
|
||
|
||
You want to buy some Monero (a digital currency) from somebody on Morphit. The seller wants U.S. dollars cash, sent through the mail. Here's what happens:
|
||
|
||
1. The seller's order says "Selling 0.05 XMR for $100 USD via Cash by mail."
|
||
2. You take the order. A chat opens.
|
||
3. The seller taps "Share mailing address" and fills in their P.O. box. You see a 📬 pill with the address. You tap "Copy address" to copy it.
|
||
4. You go to the post office. You wrap five $20 bills in tinfoil, put them in a plain envelope addressed to that P.O. box, buy USPS Priority Mail with insurance, and write down the tracking number from your receipt.
|
||
5. Back in Morphit chat, you tap "Record shipment", pick USPS, paste the tracking number, and send.
|
||
6. The seller sees a 📦 pill with your tracking number and clicks "Track package" to verify on the USPS site that the destination ZIP matches their P.O. box's ZIP.
|
||
7. A few days later, the package arrives. The seller picks it up, opens it, counts the cash, and then sends the 0.05 XMR to your Monero wallet (via Morphit's existing "Share address" + "Mark as sent" flow).
|
||
8. You leave each other positive feedback. Done.
|
||
|
||
**Limitations.** Morphit does not arbitrate disputes. If your cash gets lost in the mail and you didn't use insurance, that's between you and the carrier — Morphit cannot recover it. If the seller takes your cash and never sends the crypto, file a feedback report and the community sees their reputation drop, but Morphit cannot reverse the cash transfer. The same is true for any P2P platform that doesn't custody funds. Insurance + verified addresses + good carrier choice + small first trades to build trust are your real protections.
|
||
|
||
---
|
||
|
||
## How long do orders stay open?
|
||
|
||
**FAQ key:** `order_timeouts`
|
||
|
||
Orders stay visible for up to 90 days by default (you can change this 1–90 days). You have 15 minutes after posting to replace an order for typos; after that it's locked. Trades themselves happen off-platform — Morphit coordinates the order match, but you and your counterparty agree on the payment timeline directly via the encrypted chat. Most pairs settle within hours; long-running disputes are rare because feedback discipline incentivizes both sides to close out quickly. If your order expires without a match, you can re-list it from /my/orders with one click.
|
||
|
||
---
|
||
|
||
## Can I fix or cancel an order after posting?
|
||
|
||
**FAQ key:** `order_editing`
|
||
|
||
You have 15 minutes after posting to replace an order (for typos or wrong numbers). After 15 minutes, or as soon as someone expresses interest in trading, the order is locked. You can still cancel it — cancellation is its own on-chain action, always allowed before a trade begins. Technically: Blurt's `custom_json` ops are permanent and not editable at the protocol level, so Morphit handles 'edits' by posting a tiny replacement op that references the original. Both versions live on chain forever — anyone can audit the full history — but indexers only accept replacements posted within the 15-minute window. Why 15 minutes? A longer window is an attack: a seller could post favorable terms, wait for a buyer to start negotiating, then silently worsen them. Fifteen minutes is enough to catch a typo during proofreading, short enough that no real conversation has started.
|
||
|
||
---
|
||
|
||
## Are my chats private?
|
||
|
||
**FAQ key:** `chat_privacy`
|
||
|
||
Your chat content is fully private — encrypted end-to-end between you and your counterparty. Only your two devices hold the keys to decrypt.
|
||
|
||
What's private:
|
||
• Message text
|
||
• Any payment details, addresses, or negotiation you exchange
|
||
|
||
What's not private (metadata, visible on chain):
|
||
• Your counterparty's account handle (@scooby, @dingleberry, etc)
|
||
• Timestamps of when each message was sent
|
||
• Approximate message size
|
||
|
||
Cryptography used:
|
||
• X25519 key agreement (elliptic-curve Diffie-Hellman)
|
||
• ChaCha20-Poly1305 authenticated encryption
|
||
• Fresh ephemeral key per message
|
||
|
||
These are standard, well-audited primitives (from libsodium). The protocol is a simple ECIES design documented in ADR-0015. If your threat model requires different properties like per-message forward secrecy, use a dedicated secure messenger — good options include **Matrix/Element**, **Session**, **Keybase**, and **Signal**. (Morphit complements but doesn't replace a dedicated secure messenger.)
|
||
|
||
---
|
||
|
||
## Why does Morphit randomize my transfer amount?
|
||
|
||
**FAQ key:** `monero_amount_jitter`
|
||
|
||
Identical amounts on a public chain are a fingerprint. If you post an order to sell 0.00513924 BTC and the buyer sends you exactly 0.00513924 BTC, an observer watching the chain — your ISP-attached forensic team, a chain-analysis firm, a curious neighbor running an indexer — can match the chain transfer to your orderbook post with high confidence. Morphit defeats this by adding a tiny random tail to every transfer so the on-chain amount differs from the posted amount by a small unpredictable number. The seller is always paid slightly MORE than asked, never less; verification still passes because the amount-check is 'at-least.'
|
||
|
||
**Why this matters even on 'transparent' chains you chose deliberately.** Choosing Bitcoin (or BCH, LTC, DASH, DOGE, transparent ZEC, SOL, ETH, XRP, etc.) doesn't mean you've consented to having every trade publicly linked to your username. The point of using a transparent chain is auditability of supply and infrastructure trust — not surveillance of your individual trades. Jitter shrinks the linkability without changing anything else about your trade. Think of it like wearing a hat in a parade: you're still in public, you've just removed the bit of identifying detail that wasn't required to be there.
|
||
|
||
**Why this matters even on Monero.** Monero hides amounts on chain — but the amount you SHARE in the chat goes through other surfaces. Centralized exchanges you off-ramp to see the figure. Counterparties you message see the figure. Screenshots leak. Wallet histories on your device record the figure. If chat-shared amounts and on-chain transfers can be linked by an observer who learns just one of them, the privacy advantage of XMR weakens. Jitter restores that gap.
|
||
|
||
**Per-asset jitter range** (all under a cent in most cases):
|
||
- **XMR**: up to 999,999 piconero (~$0.0002)
|
||
- **BTC / BCH / LTC / DASH / DOGE / ZEC / ARRR / DCR / SOL / ETH / XRP**: up to 999 satoshi-equivalents (~$0.001 to $0.50 depending on price)
|
||
- **Blurt**: up to 99 milliblurt (fractions of a cent)
|
||
- **USDT / USDC / DAI**: up to 999 micro-units (under a tenth of a cent)
|
||
|
||
**Default ON.** The toggle sits right under the amount field in the address-share modal. We strongly recommend you leave it on — the cost is a trivial implicit tip, the privacy benefit is meaningful. Turning it off should be a deliberate informed choice (for example, when matching an exact invoice amount that a counterparty's accounting system requires).
|
||
|
||
**What jitter does NOT do.** It addresses amount-correlation linkability, not the separate centralization threat that USDT/USDC/DAI carry (Circle/Tether can freeze addresses regardless of amount). For full per-asset privacy posture see /privacy/{asset}.
|
||
|
||
---
|
||
|
||
## Can feedback be edited or deleted?
|
||
|
||
**FAQ key:** `feedback_immutable`
|
||
|
||
No, once posted it is permanent. This is what makes reputation meaningful — nobody can quietly erase a bad review. If someone leaves feedback you disagree with, you can post a public response; the original stays.
|
||
|
||
**If people are going to trust you, your reputation is everything.**
|
||
|
||
---
|
||
|
||
## What data does Morphit collect about me?
|
||
|
||
**FAQ key:** `data_collection`
|
||
|
||
None. Zero cookies. Zero analytics. Zero tracking scripts. No telemetry. Morphit never sees or logs your IP address, so we keep no record that you were ever here.
|
||
|
||
---
|
||
|
||
## What if I lose my password or recovery seed?
|
||
|
||
**FAQ key:** `lost_keys`
|
||
|
||
Your account is inaccessible, and we cannot get it back for you. This is not a mistake — it's the core design. If there were any recovery mechanism, someone would have access to your keys. We refuse to be that someone. Secure those 12-words like your life depends on it.
|
||
|
||
The same is true if you signed in with an existing Blurt account: your Keyfile and your keys are the account. Lose both and no one — not us, not the operator, not the blockchain — can restore them.
|
||
|
||
---
|
||
|
||
## Why did Morphit choose the Blurt blockchain?
|
||
|
||
**FAQ key:** `what_is_blurt`
|
||
|
||
We needed a public **social** blockchain — and that constraint eliminated almost everything else on the market.
|
||
|
||
Privacy-focused chains like Monero (which we love and trade as a primary asset) are built around hiding amounts, addresses, and metadata. Their users — rightly — refuse to broadcast structured public data because that's antithetical to the whole reason those chains exist. You can't run a public orderbook, immutable reputation system, or auditable trade history on a surveillance-resistant chain; the surveillance resistance is the whole point.
|
||
|
||
But Morphit's coordination layer needs the opposite: orders, prices, feedback, and order announcements that ANYONE can read and verify, without trusting Morphit. So we needed a chain explicitly designed for public structured data — a SOCIAL chain. After auditing the field (Hive, Steem, Blurt, Lens, Farcaster, ATProto), Blurt won on every metric that mattered:
|
||
|
||
**1. Three-second block times.** Real-time orderbook updates. New orders confirm in seconds, not minutes — fast enough that high-frequency traders can place and accept orders without lag, and fast enough to **prevent eBay-style last-second sniping**. There's no time window where someone can rush in and grab an order ahead of a buyer who saw it first.
|
||
|
||
**2. Throughput exceeding Visa + Mastercard combined.** Blurt's witness network can process more transactions per second than every major card network put together. Morphit will never compete with Blurt social-content posts for chain capacity. Listing fees stay tiny because there's no congestion.
|
||
|
||
**3. Transactions are essentially free.** No mining. No gas auctions. No priority-fee arms races. Posting an order, broadcasting feedback, sending an encrypted chat message — these cost effectively zero in chain fees. Morphit's $0.125 listing fee isn't a chain cost; it's a project decision (anti-Sybil + cover account-creation costs). On a chain like Ethereum or Bitcoin, the fees alone would make a $5 trade impossible.
|
||
|
||
**4. Built-in end-to-end encrypted chat.** Buyer–seller conversations live on chain as encrypted ciphertexts. Permanent, verifiable, decentralized — and only the two parties hold the keys to read them. Trade-coordination history is durable for posterity (and for any future dispute, you have a courtroom-grade record).
|
||
|
||
**5. Scammer and spammer prevention.** On-chain identity costs something to create. Posting an order costs something. Sybil tiers escalate fees if you post many orders quickly. Combined with the immutable feedback system, the chain itself is hostile to bad actors. Real traders pay tiny fees; spammers pay rapidly-growing ones.
|
||
|
||
**6. Immutable public feedback proving reputation.** Every star rating, every comment, every response — permanently recorded, impossible to edit, impossible to delete. **If people are going to trust you, your reputation is everything** — and Blurt makes that reputation provably yours and provably unfakeable.
|
||
|
||
**7. Fully distributed federated DEX orderbook.** Because the orders live on chain, any operator running their own Morphit indexer sees the SAME orderbook in real-time. There's no central server to attack, no central database to subpoena, no single point of failure. A buyer on instance A sees orders posted through instance B without any cross-server coordination — the chain is the coordination. Multi-site instance runners give the network resilience that no centralized exchange can match.
|
||
|
||
Blurt is also a social token: holding it gives you posting and voting weight on Blurt content platforms like blurt.blog, blurt.media, and others. So when you pay Morphit listing fees in Blurt, you're not just paying for trade infrastructure — you're directly building stake in a free-speech social network. The loyalty milestones (see the loyalty FAQ) deliberately reward Blurt-paid fees because we want the Blurt economy to thrive alongside Morphit's.
|
||
|
||
**8. Blurt is, by design, an anonymous social reputation chain — and that's the exact thing Morphit needs.** Blurt accounts have no KYC, no email, no real-name requirement. What they have is a stable cryptographic identity that can accumulate posts, votes, and a public on-chain track record over time. Morphit's reputation system needs exactly the same primitive: traders should be pseudonymous (no real-name disclosure) AND have a durable, unforgeable, publicly-auditable track record. We didn't have to graft a reputation system onto a non-reputation chain; we built on a chain that was already designed around the anonymous-but-accountable model that Morphit's feedback layer extends.
|
||
|
||
TL;DR: privacy chains can't host public coordination, transparent chains have congestion problems, slow block times kill order matching, and only Blurt combines social-chain design + 3-second blocks + free transactions + social-token economics in one package.
|
||
|
||
---
|
||
|
||
## What is 'Privacy Mode'?
|
||
|
||
**FAQ key:** `privacy_mode`
|
||
|
||
An optional stricter mode that keeps your encrypted keystore in session memory only — it's gone when you close the tab. Use it on shared or public devices. Normal mode keeps your keystore on your own device until you delete it.
|
||
|
||
---
|
||
|
||
## Can I use a VPN to access Morphit?
|
||
|
||
**FAQ key:** `use_vpn`
|
||
|
||
Yes! In fact, we recommend it. Privacy and security are imperative. Our favorite is Mullvad (mullvad.net) and they accept Monero too!
|
||
|
||
---
|
||
|
||
## How much activity is there on Morphit right now?
|
||
|
||
**FAQ key:** `activity_level`
|
||
|
||
Morphit has a live [stats page](/stats) — it shows the number of active orders, the total number of orders ever placed, completed trades (all-time and in the last 30 days), and how many crypto assets and fiat currencies currently have active orders. Those figures come straight from this instance's indexer reading the underlying blockchain, so they reflect real on-chain activity rather than a number anyone could quietly inflate.
|
||
|
||
And because every Morphit order is a signed `custom_json` operation (id `morphit_order_v1`) on the public chain, anyone can reproduce or double-check these counts by searching the blockchain directly or running their own indexer against the same data — no permission and no reliance on our servers required.
|
||
|
||
---
|
||
|
||
## How does Morphit stop fake reviews?
|
||
|
||
**FAQ key:** `sybil_protection`
|
||
|
||
Each order costs a small fee, and the fee goes up sharply after a few posts in 24 hours to stop spam. The indexer also spots accounts that look like they're trading with themselves and tags any reviews between them as 'unverified self-trade' — weighted to zero so they don't boost reputation.
|
||
|
||
---
|
||
|
||
## Can I use Morphit without JavaScript?
|
||
|
||
**FAQ key:** `no_js`
|
||
|
||
Yes, for browsing. You can read the orderbook, profiles, and feedback with JS off. To trade, JS has to run — because all the cryptography happens inside your browser. If we moved that to a server, we'd have your keys, and that's the one thing we refuse to do.
|
||
|
||
---
|
||
|
||
## Can I follow Morphit with RSS?
|
||
|
||
**FAQ key:** `rss_feeds`
|
||
|
||
Yes — three feeds, and each comes in three formats: RSS 2.0 (`.xml`), Atom (`.atom`), and JSON Feed (`.json`). Click any orange RSS pill on the site to copy a feed's URL in whichever format your reader prefers. Any feed reader can subscribe. No account needed.
|
||
|
||
**Worldwide feed — `/rss/orderbook.xml`**
|
||
The 50 most recent live orders across all assets and traders. Linked from the site footer (the orange RSS pill). Use this when you want to see everything that's posted.
|
||
|
||
**Per-asset feed — `/rss/orderbook/by-asset/<asset>.xml`**
|
||
Filtered to a single asset: `btc.xml`, `xmr.xml`, and likewise for every supported asset. Subscribe to only the trades you care about. To find the link, filter the orderbook to the asset you want and look beside the Clear-filters button.
|
||
|
||
**Per-trader feed — `/rss/orderbook/by-account/@<account>.xml`**
|
||
Filtered to a single trader's orders. Subscribe to a counterparty you trust so you're notified the moment they post a new buy or sell order. Find the subscribe link on any trader's profile page beneath their active orders.
|
||
|
||
**What RSS is good for**: monitoring new orders without keeping a tab open, getting notifications when the main site is slow or blocked in your network, and piping the feed into IFTTT / n8n / a home script for push-notifications the moment something matches.
|
||
|
||
**Privacy tradeoff — worldwide and per-asset**: Blurt is a public chain, so nothing in these feeds is information a determined observer couldn't already get by running their own chain indexer. But RSS makes that effort drop to zero — anyone polling the feed can build a timeline of who posts when, in which region, for what. The set of valid URLs is small and enumerable (one worldwide + one per asset), so a passive observer learns at most "@scooby really likes BTC."
|
||
|
||
**Privacy tradeoff — per-trader (slightly more revealing)**: A per-trader URL maps one-to-one to one identified subject of interest. A network observer who sees you polling `/rss/orderbook/by-account/@alice.xml` learns specifically that you're watching @alice — slightly more revealing than the worldwide or per-asset feeds. If timing correlation matters in your threat model, poll over Tor.
|
||
|
||
We ship all three feeds because orderbook transparency is a core Morphit property — and because following a trusted counterparty is something traders genuinely want — not despite the tradeoffs, but with them documented honestly so you can decide what's right for your situation.
|
||
|
||
---
|
||
|
||
## Why should I use a new receiving address each time?
|
||
|
||
**FAQ key:** `why_fresh_addresses`
|
||
|
||
Both Bitcoin and Monero addresses can be watched on the blockchain. If you reuse the same address for every trade, anyone can see all your trades by looking at that one address — how many you've done, roughly when, and how much.
|
||
|
||
A fresh address each time breaks that link. Your wallet software will happily generate new addresses for free — it's a couple of clicks in any half-decent wallet.
|
||
|
||
For Monero, Morphit requires a subaddress (the kind that starts with 8, not 4). Subaddresses are Monero's modern privacy default: they look completely unrelated on the blockchain even though they all come from the same wallet. Generate one from your wallet for each trade.
|
||
|
||
For Bitcoin, we recommend a new address — but we won't block you if you reuse one, you'll just see a reminder. SegWit (bc1…) and Taproot (bc1p…) addresses also pay lower fees and are better for privacy, so prefer those when your wallet gives you the choice.
|
||
|
||
---
|
||
|
||
## Who runs Morphit?
|
||
|
||
**FAQ key:** `who_runs_it`
|
||
|
||
The project is open-source; the indexer, posting relay, and support bot can all be run by anyone. The morphit.io instance is operated by Agorise (four geeky agorists), but the whole design assumes morphit.io might go offline — your app keeps working from cache, from mirrors, from Tor, from I2P, or from Lokinet.
|
||
|
||
---
|
||
|
||
## Can I run my own Morphit?
|
||
|
||
**FAQ key:** `run_your_own`
|
||
|
||
Yes, and please do — Morphit only stays unstoppable if lots of people run pieces of it. Here's what you can host:
|
||
|
||
• A front-end mirror — clone the repo, run one command, and you have a full Morphit at your own domain (or a .onion, .b32.i2p, or .loki address — or an ENS .eth name). Same code, same orders, your rules about who can reach it. Great for communities that want a curated presence.
|
||
|
||
• An indexer — watches the chain, serves the orderbook as REST + RSS, gossips with other indexers. Your indexer's RSS feeds become another path for everyone; your REST API becomes a fallback when others are slow.
|
||
|
||
• A posting relay — pays the small chain network fees so your users don't have to think about them. Run one for your community and make onboarding frictionless.
|
||
|
||
• A payment watcher, a support bot, or an avatar server — smaller pieces, all useful.
|
||
|
||
Why it matters: every mirror, every indexer, every relay is an extra path that a censor, a bankrupt host, or a bad court order cannot shut down at once. One instance is a target. Fifty is a movement. Morphit's core promise — non-custodial, no-KYC, uncensorable — only holds as long as enough people are willing to run a copy. If you have a VPS, a Raspberry Pi, a spare laptop, or even a mid-range phone, you can contribute. All the services are lightweight Node.js (TypeScript) programs with plain config files; the README walks you through it in minutes, not hours.
|
||
|
||
The more people who run Morphit, the harder it is for anyone to take it away from the rest of us. Running a Morphit node also earns you 90% of the Blurt-paid listing fees there.
|
||
|
||
---
|
||
|
||
## Is Morphit vulnerable to hacking, data theft, or takedowns?
|
||
|
||
**FAQ key:** `security_attack_vectors`
|
||
|
||
The best defense is the design itself. Morphit is non-custodial — your private keys never leave your device and are never transmitted to our servers, so there is no key database for anyone to steal. There are no accounts, no passwords, no sessions, and no login state, which means no credential phishing, no session hijacking, and no account-takeover class of attack. We do not collect KYC and we do not log IPs, so there is no personal-information database that could be breached or subpoenaed. The orderbook lives on the blockchain itself — any user can run their own indexer and their own frontend — so censorship and takedowns cannot delete orders, only hide them from one particular mirror. Standard web attack surfaces (XSS, CSRF, SSRF, RCE, SQL injection, parameter pollution) are addressed through a combination of strict Content Security Policy headers, exact-origin CORS allowlists, schema-validated request bodies with bounded field lengths, no eval / no dynamic code paths, no server-side database queries on user input, and a relay service that only speaks to pre-configured blockchain endpoints. We also have no PHP, no WordPress, no xmlrpc.php, and no OAuth layer, so entire vulnerability classes that plague other platforms simply do not apply here. Volumetric (network-level) DDoS is beyond the reach of any application to solve alone — that belongs to the VPS provider or an upstream scrubbing service — but application-layer abuse is mitigated by per-IP rate limits, 64 KiB request body caps, and tight resource ceilings. The full threat model is documented in SECURITY.md and ADR-0006 in the project repository.
|
||
|
||
---
|
||
|
||
## How rigorous is Morphit's security review process?
|
||
|
||
**FAQ key:** `security_engineering_rigor`
|
||
|
||
Very. Security on Morphit isn't a marketing claim — it's a sustained engineering practice with a documented audit trail anyone can read.
|
||
|
||
**The audit lives in the repository.** `docs/AUDIT-2026-05.md` in the public source tree is a running document of every security review pass we've done on the codebase, organized by date and subsystem. It's not a one-time pre-launch certificate; it's a working log that gets a new entry every time we audit a meaningful change. Every finding is given a severity rating, a description, and an outcome — fixed inline, deferred to a tracked follow-up, or accepted with rationale. Items we choose not to fix immediately go into `docs/REVISIT-LIST.md` (also public) with full context so nothing falls through the cracks.
|
||
|
||
**We use formal threat-modeling methodology.** Each audit pass runs a STRIDE matrix (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) over every changed subsystem, then builds attack trees from the most attractive entry points, then writes adversarial red-team narratives walking through what a determined attacker — we name them and give them goals — would actually do. This is the same methodology used in commercial security reviews; the difference is we publish the result.
|
||
|
||
**Open source means open audit.** Morphit is AGPL-3.0. The full source code is at git.agorise.net/agorise/morphit. Anyone can clone the repo, read the code, run the test suite (over 1,000 self-checks ship with the source), submit issues, and propose patches. We treat external review as an asset, not a threat. The threat model assumes a sophisticated attacker has already read every line of code — because that's the realistic worst case, and designing for it is what makes the system actually safe.
|
||
|
||
**Privacy-first defaults.** The architecture is built so that even a complete server compromise doesn't leak much, because we deliberately don't have much to leak. No KYC. No email. No phone number. No IP retention. No central key store. No session cookies. Chat is end-to-end encrypted; the indexer stores only ciphertext and could not decrypt your conversations even under legal compulsion. Trade verification for cryptocurrencies happens on the user's own device against the user's own node — Morphit never sees your view keys, your wallet, or your funds. The threat model treats every operator as untrusted by default; the federation lets users choose whose mirror to use, and switch at any time.
|
||
|
||
**Monero users in particular**: we know your community is the most rigorous in crypto about privacy. Every Monero-related change goes through extra scrutiny because the cost of a privacy mistake on XMR is permanent. The marketplace never holds your XMR, never asks for view keys, never proxies your transactions, never logs your IP, and never sees your wallet. Where a naive marketplace would expose linkable amounts on chain, Morphit's order math includes amount-randomization features specifically designed to defeat the obvious correlation attack. We've shipped multiple rounds of work specifically to harden Monero flows; the testing suite covers the cases we expect adversaries to try.
|
||
|
||
**Discipline beats heroics.** The single most important security property of any system is whether the team treats issues as systemic engineering work or as embarrassments to be downplayed. Morphit is run as the former. When we ship a feature, we audit it; when we audit it, we publish what we found; when we find something, we fix it or document why we didn't. The audit document and the revisit list together total many thousands of lines and grow steadily. Some of what's in there is unflattering — that's the point. A security review that finds nothing isn't a thorough review; it's a shallow one.
|
||
|
||
**What we deliberately don't publish.** We do publish our defensive-economics math (the cost to attempt various Sybil attacks is openly documented, because deterrence works best when attackers can see the math is against them). We don't publish exact internal heuristics, rate-limit thresholds, or detection signal weights, because those would give an evasion roadmap to an attacker without correspondingly helping defenders. The ratio of public to private information is calibrated to maximize attacker friction while letting honest users verify our work.
|
||
|
||
**Bug bounty program.** We run a discretionary security recognition program. Every actionable finding gets reviewed by a real engineer, gets an answer, and — if it materially improves Morphit's security posture — gets rewarded in Blurt (paid from @morphit-fees) or BTC, scaled to severity and the report's quality. No fixed tier table; case-by-case adjudication. Hall of fame credit available even when payment isn't. Send a Matrix DM to **@agorise:matrix.org** for confidential disclosure (end-to-end encrypted by default), or open a confidential issue on git.agorise.net. Full scope, severity guidance, and payment workflow at /security#bounty and in `docs/SECURITY.md`.
|
||
|
||
If you're evaluating Morphit and you want to verify any of the above for yourself: clone the repo and read `docs/AUDIT-2026-05.md`, `docs/REVISIT-LIST.md`, `SECURITY.md`, and the ADR series. Everything is there.
|
||
|
||
---
|
||
|
||
## How can I help make Morphit unstoppable?
|
||
|
||
**FAQ key:** `help_make_unstoppable`
|
||
|
||
Morphit's resilience grows with every independent operator. You can help in any of these ways:
|
||
|
||
• Run your own node. Spin up an indexer + relay + frontend on your own server (or VPS, or home box), and serve Morphit from your own URL. Every independent mirror multiplies our surface area: blocking one does nothing when ten more exist. See the 'Can I run my own Morphit?' entry for the technical steps.
|
||
|
||
• Host on Tor, Lokinet, or I2P. A .onion, .loki, or .b32.i2p mirror lets users reach Morphit from jurisdictions where clearnet access is blocked. These are cheap to run — they don't need TLS certificates or DNS — and the impact is enormous for users in censored networks.
|
||
|
||
• Point an ENS .eth name at it. Register a `.eth` name with ENS (Ethereum Name Service) and aim it at your instance — usually via an ENS contenthash to an IPFS copy of your site — so people can reach you at a human-readable, decentralized name like `morphit.eth` (through an ENS-aware browser or gateway). It appears as an extra footer pill alongside Tor/Lokinet/I2P.
|
||
|
||
• Host Morphit's dependencies. The frontend pulls a handful of JavaScript libraries at build time. Self-hosting mirrors of those packages (or proxying their CDNs) lets communities bootstrap without relying on third parties. We document the exact list in the operator runbook.
|
||
|
||
• Fund a community node. If you don't want to run servers yourself, contributing Blurt to an active operator's @morphit-relay account keeps it funded to create accounts. One operator covering 500 weekly signups needs ~$1 of Blurt per week; small contributions add up.
|
||
|
||
• Spread the word. Morphit depends on network effect — every user who posts a trade is a signal to the next person that the marketplace is alive. Tell your crypto communities, link us from your blog, post tutorials on blurt.media.
|
||
|
||
• Write tutorials and translations. The project is AGPL-3.0; clone the repo, improve documentation, translate the UI into more languages, and open a merge request. Non-code contributions count.
|
||
|
||
Morphit is designed to be impossible to kill because there is no central actor to pressure. You running ANY part of the stack makes that guarantee stronger.
|
||
|
||
---
|
||
|
||
## Why doesn't trading with myself work to boost my reputation?
|
||
|
||
**FAQ key:** `why_self_trading_fails`
|
||
|
||
Self-trading is economically unprofitable on Morphit by design.
|
||
|
||
Here's the math: each listing costs about $0.25 to post (the fee goes to @morphit-fees, not to your counterparty). If you post a buy order and a sell order with two accounts you control, you pay $0.50 for the round trip. Each 'successful trade' produces one feedback entry you can sign to yourself. Cost per fake feedback: $0.50.
|
||
|
||
Now consider detection. Morphit's indexer runs signal analysis that flags suspicious reciprocity — accounts that trade exclusively with each other, accounts created within minutes of each other, and accounts sharing an account-creator relationship. Those signals are PUBLIC on every order row. A reputation built entirely from self-trades shows the signal badge; real traders avoid you; you've spent your fake-reputation money for nothing.
|
||
|
||
Even the Sybil fee tier is stacked against this abuse. Your 4th order in 24 hours pays 1.25× the base fee; your 5th pays 1.56×; your 10th pays 4.77×. Running a fake-reputation factory at any useful speed gets expensive fast.
|
||
|
||
The honest path is cheaper, faster, and actually works: post good orders, communicate clearly with counterparties, show up with payment promptly. Feedback from real traders looks different from self-trading feedback — timing distribution, counterparty variety, geographic spread. The people checking your reputation can tell.
|
||
|
||
---
|
||
|
||
## Can I register many accounts through Morphit to spam the orderbook?
|
||
|
||
**FAQ key:** `why_multi_accounts_fail`
|
||
|
||
You can — but the economics make it unprofitable, and the system is designed to stay that way.
|
||
|
||
Each Morphit relay creates accounts on Blurt with a direct account_create operation that pays the ~100 account-creation fee inline. So every account a Morphit relay creates costs the operator ~$0.20 of Blurt. To recover this, Morphit requires a listing fee on every order you post after your first. An attacker registering bulk accounts and never posting wastes ~$0.20 per account of Morphit's Blurt — so we rate-limit signups to 2 per IP per day at the network layer, and a per-relay daily signup ceiling caps the total damage (operators set this ceiling to bound how much Blurt they'll spend on signups per day). An attacker who wants to exceed our rate limits has to rotate IPs (which is non-trivial and expensive at scale); the rate limit is an annoyance for abusers and invisible to normal users.
|
||
|
||
If you register accounts AND post orders to spam the orderbook, each order pays its $0.25 listing fee. 100 spam orders = $25 of your real money. Meanwhile Morphit's indexer flags related-account patterns automatically and shows that signal publicly on the orderbook, so your spam is conspicuous.
|
||
|
||
The welcome bonus (10 Blurt + 10 Blurt Power) is delayed until AFTER your first successful trade is confirmed by counterparty feedback — so you cannot collect welcome bonuses at scale without also completing real trades with real counterparties. A farmer who fakes trades between their own accounts pays the listing fees and gets flagged by signal analysis; they never net a profit.
|
||
|
||
We publish these mechanics openly because deterrence works best when attackers can see the math. It's always cheaper to be a real trader than a fake one on Morphit.
|
||
|
||
---
|
||
|
||
## What is Blurt and why does Morphit sometimes mention it?
|
||
|
||
**FAQ key:** `blurt_benefits`
|
||
|
||
Morphit settles its on-chain coordination on a public ledger called Blurt. The ledger's native unit is also called Blurt — every block, every signature, every fee transfer flows through it. You can think of Blurt as the gas token for the coordination layer, the same way ETH is gas for Ethereum, but smaller and quieter.
|
||
|
||
You don't have to interact with Blurt to trade BTC, XMR, USDT, USDC, DAI, BCH, LTC, DASH, DOGE, ZEC, ARRR, DCR, SOL, ETH, or XRP on Morphit. If your operator accepts BTC or XMR for the network fee (most do), you can list orders, message counterparties, and complete trades without ever touching Blurt.
|
||
|
||
Why does it come up at all? Three reasons:
|
||
|
||
1. **Network fees can be paid in Blurt** as an alternative to BTC/XMR. Some users prefer this because Blurt confirmations are instant — no waiting for external block explorers. If your operator has only Blurt configured for fees, this is the path you'll use.
|
||
|
||
2. **The welcome bonus is denominated in Blurt** (a small one-time gift after your first successful trade). It's harmless to ignore, or you can spend it on future network fees.
|
||
|
||
3. **Your Blurt balance gives you voting weight** on Blurt-social frontends like blurt.blog. That's outside Morphit's scope but if you find yourself with Blurt and curious, those are your options.
|
||
|
||
Morphit is built on Blurt because the ledger's design (low transaction overhead, free posts, public-by-default state) fits a peer-to-peer trade venue better than the alternatives we evaluated. We treat the ledger as plumbing — necessary, deliberately chosen, but not something you should have to think about while trading.
|
||
|
||
---
|
||
|
||
## How do I stake my Blurt (power up to BP) to earn interest?
|
||
|
||
**FAQ key:** `how_to_stake_blurt`
|
||
|
||
Staking Blurt means converting your liquid Blurt into **Blurt Power (BP)** — a process Blurt calls "powering up." Staked Blurt earns roughly **2% interest a year (APR)** (the live rate is computed from the chain's inflation and shown in-app), strengthens your upvotes, and earns curation rewards. It's your own coin the whole time — not a deposit, not a loan, not held by anyone else.
|
||
|
||
**The easiest way is right here in Morphit.** Open your [wallet](/my/wallet), find your liquid Blurt, and choose **Power Up**. Enter the amount and confirm. That's it — your Blurt is now BP and starts earning.
|
||
|
||
Morphit never holds or moves your Blurt for you — powering up happens directly on the blockchain, signed by your own keys. If you ever want liquid Blurt back, you **power down**, which releases it gradually over 4 weeks (this gradual unstake is a Blurt protocol rule, not a Morphit one).
|
||
|
||
---
|
||
|
||
## Where does the Blurt price displayed on Morphit come from?
|
||
|
||
**FAQ key:** `where_does_blurt_price_come_from`
|
||
|
||
The Blurt/USD price you see next to listing fees on Morphit (the "~$0.125" subtext beside the Blurt amount) comes from a layered price-source chain designed to reduce reliance on any single external service.
|
||
|
||
**The chain, in priority order:**
|
||
|
||
1. **External market median** — Blurt/USD is read from several independent public price sources at once — Coingecko, CoinPaprika, CryptoCompare, and (for assets they list) major exchanges like Kraken/Binance/Coinbase/OKX/Bybit — and combined with an outlier-rejected median. Any source that's down, rate-limiting us, or returning a bad number is simply dropped, so no single service can block or skew the price.
|
||
|
||
2. **morphit_native** — A SELF-SOVEREIGN price derived from on-platform trade data (opt-in per operator; off by default until your instance has enough volume to support it). When enabled, this fetcher looks at recent verified-fee orders that traded Blurt against USD-fiat or stablecoins, applies several layers of manipulation defense, and computes a median across distinct traders. Slotted between the external market median and the static floor — external sources remain primary until an operator explicitly opts in to preferring the native value during disagreement.
|
||
|
||
3. **Static fallback** — An operator-set floor value (default $0.002) used when all upstreams have failed. Editable in the setup wizard.
|
||
|
||
**Why a chain instead of one source?** No single price feed can be trusted unconditionally — any one service can go down, rate-limit us, or be wrong. That's why the first tier is itself a median of many independent feeds, and a static fallback sits behind it for the worst case. The chain means Blurt pricing keeps working in every scenario short of the entire internet going down.
|
||
|
||
**How morphit_native works** (when enabled — see ADR-0039 for full design):
|
||
|
||
- **Tiered anchors**: Tier 1 (highest priority) uses Blurt-vs-USD direct orders (bank transfer, cash, etc.); Tier 2 supplements with Blurt-vs-stablecoin orders (USDT/USDC/DAI); Tier 3 combines both pools when each alone is too thin.
|
||
- **Cross-stablecoin depeg detection**: independent ratios between USDT/USDC/DAI on Morphit identify when any one of them is off-peg. Depegged stablecoins are excluded from Tier 2; Tier 1 (which doesn't depend on stablecoin peg assumptions) continues working.
|
||
- **Sybil resistance**: each contributing trader must have at least one prior verified-fee completed trade AND must NOT appear in any of the cp123-cp125 reputation signal tables (suspicious_reciprocity, related_accounts, one_way_pile_on, review_concentration). Price manipulation requires the same level of effort as reputation manipulation.
|
||
- **Per-trader contribution cap**: each distinct account contributes ONE vote (their own median price) regardless of how many orders they posted. A whale with 50 orders is still 1 vote of N.
|
||
- **Order-age grace period**: orders must have existed for at least 10 minutes before they qualify, defeating "post-and-cancel" manipulation races.
|
||
- **Smoothing cap**: large per-cycle price moves are dampened to prevent flash manipulation.
|
||
- **Long-term drift monitor**: a 7-day exponential baseline catches slow-drift attacks where each individual move is small but the cumulative drift is large.
|
||
- **Cross-source disagreement detector**: when morphit_native and external sources disagree by more than 25% for 4+ hours, an alert fires in the indexer logs and `/v1/health`.
|
||
- **Hardcoded outer plausibility envelope**: operator config can tighten the price-range filter but cannot widen it past the hardcoded bounds, preventing a captured operator from displaying wildly wrong prices.
|
||
|
||
**The "verify yourself" endpoint**: `GET /v1/price/morphit-native/receipt` returns the full set of inputs that produced the current native price — which tier was used, which traders contributed (just account names; their orders are already publicly visible in the orderbook), the cross-stablecoin depeg report, plausibility envelope settings, and a NOT-AN-ORACLE warning. Anyone can audit; no opaque "trust the indexer" required.
|
||
|
||
**IMPORTANT: morphit_native is NOT designed to be an oracle for other systems.** It's for Morphit's internal USD display courtesy only. Don't use it as a price input to lending protocols, DEXes, or any value-bearing system. The price is manipulation-resistant for DISPLAY purposes (where small inaccuracies are tolerable) but not bulletproof against the kind of attack a determined adversary mounts when real money depends on the value being correct. See ADR-0039 for the threat model.
|
||
|
||
**Why this matters for your trades**: Blurt-paid listing fees are USD-targeted, not a fixed Blurt amount — Morphit quotes the Blurt worth about $0.125 at the current price, so the fee's dollar value stays steady as Blurt moves up or down. The exact Blurt amount is shown before you sign and settles at chain time. Behind the scenes the indexer accepts that amount against a chain-pinned floor with a small tolerance band, so every instance agrees on what's owed and the amount can't be gamed by feeding in a bad price. The price source's only job is to make that conversion accurate for Morphit's display — never a source of truth for any downstream financial system.
|
||
|
||
**Pre-launch note**: Until enough on-platform trade volume exists for morphit_native to qualify (requires ≥3 distinct verified-fee traders posting Blurt-vs-USD or Blurt-vs-stablecoin orders in the last 8 hours), every instance falls back to the external market median (and the static floor behind it). Operators turn on morphit_native via `MORPHIT_INDEXER_PRICE_FEED_NATIVE_ENABLED=true` when their data is mature.
|
||
|
||
**cp128 update — denomination is operator-configurable.** Although the discussion above uses USD as the example, the indexer's displayed unit isn't hardcoded to USD. Operators set `MORPHIT_INDEXER_PRICE_FEED_DENOMINATION_FIAT` (default `USD`) to any 3-8 character uppercase ticker — `EUR` (Euro), `GBP` (British Pound), `JPY` (Japanese Yen), `BRL` (Brazilian Real), `CNY` (Chinese Yuan), `INR` (Indian Rupee), `RUB` (Russian Ruble), `AED` (UAE Dirham), `XDR` (IMF Special Drawing Rights basket), `XAU` (gold ounces, a hard-currency hedge), or any other ticker their market uses. The listing-fee response carries a `denomination_fiat` field telling the frontend which unit the `blurt_price_fiat` + `base_fee_fiat` numbers are in, so the UI renders the appropriate symbol and formatting ("$0.125" for USD, "€0.11" for EUR, "XAU 0.0000023" for gold, etc.). This isn't just for the hypothetical USD-collapse scenario — operators serving non-USD-native markets benefit today.
|
||
|
||
---
|
||
|
||
## Where do I buy Blurt to use as a network fee?
|
||
|
||
**FAQ key:** `where_to_buy_blurt`
|
||
|
||
**Buy it on Morphit itself — that's the whole point.** Morphit is a peer-to-peer marketplace; Blurt is one of the sixteen assets traded here, alongside BTC, XMR, USDT, USDC, DAI, BCH, LTC, DASH, DOGE, ZEC, ARRR, DCR, SOL, ETH, and XRP. Visit /orderbook, filter for Blurt sell orders, and message a counterparty. You pay them in whatever fiat or method they accept; they send Blurt to your account. Done.
|
||
|
||
**Your first order is free.** New users get a one-time waiver that covers the listing fee on their first Blurt buy — see "Is my first order really free?" for details. So your first Blurt acquisition can also be your first trade on Morphit, with no exchange account, no card, and no KYC required. The waiver is offered automatically when you compose your first order.
|
||
|
||
**Once you have Blurt in your wallet**, paying a Morphit listing fee is automatic — choose "Pay in Blurt" on the post-order screen and Morphit deducts the configured fee directly from your Blurt balance with no extra steps.
|
||
|
||
---
|
||
|
||
## Is my first order really free?
|
||
|
||
**FAQ key:** `first_order_free`
|
||
|
||
Yes — and it's a really generous one. Your first order on Morphit is a free buy worth at least $1 USD of Blurt. You enter the order in your own local currency and Morphit checks it against $1 USD-equivalent — you never have to think in Blurt. We cover the listing fee. One free order per account, for life.
|
||
|
||
**Why Blurt specifically, and not BTC or XMR?** Because the Blurt in your wallet is what makes you an active participant in everything else on Morphit. With about $1 of Blurt, you can:
|
||
|
||
- Pay listing fees on ~8 future orders at the discounted Blurt rate (about 12.5¢ each — 50% off the BTC/XMR rate)
|
||
- Vote on Blurt social content at blurt.blog, blurt.media, etc. and earn curation rewards. You also earn Blurt coins when people click "Like" on your posts.
|
||
- Receive a 1 BP delegation as your welcome stake (fires automatically on your first Blurt-paid listing fee)
|
||
- After your first completed trade, receive 10 Blurt liquid + 10 Blurt Power as the welcome bonus
|
||
|
||
Without the Blurt in your wallet, you'd start with no way to pay future listing fees at the discount, no Blurt voting weight, and no path into the loyalty-milestone reward tiers. We thought a long time about this — handing new users a dollar's worth of Blurt instead of "any first crypto" sets you up to be active rather than stranded.
|
||
|
||
**Why a $1 minimum?** That's the threshold that makes the rest of the math work: a dollar of Blurt covers ~8 future listings at the discounted rate. If we let the waiver apply to a tiny few-cent buy, you'd leave the flow with effectively no starter balance and the bonus wouldn't help you. A dollar's worth is the minimum that turns the waiver into a meaningful starter pack. Because you enter the order in your own currency, $1 stays $1 whether Blurt's price is up or down that day.
|
||
|
||
**The waiver is offered automatically** when you visit /post and start composing your first order. The Review step shows a green "🌱 First order is free" panel with the waiver pre-selected. You can decline if you'd rather save the waiver for a future trade — it never expires.
|
||
|
||
**What "free" means here:** Morphit covers the listing fee for this one order. You don't pay any network fee. The trade itself happens off-platform between you and your counterparty (they send you Blurt, you pay them whatever fiat or other thing you agreed on); Morphit doesn't touch your funds at any point.
|
||
|
||
**After your first trade:** the waiver is consumed and the normal fee structure applies — about 25¢ in BTC/XMR or about 12.5¢ in Blurt (the 50% Blurt discount is permanent). See "What are the fees?" for the full pricing.
|
||
|
||
---
|
||
|
||
## What is the welcome bonus and how do I earn it?
|
||
|
||
**FAQ key:** `welcome_bonus`
|
||
|
||
There are actually three welcome rewards on Morphit, and they fire at different moments:
|
||
|
||
**1. First listing-fee payment in Blurt → 1 BP delegated.** The moment you pay your first Blurt listing fee — even before any trade matches or completes — Morphit delegates 1 BP (Blurt Power) to your account. This is a tiny, one-time "welcome to the network" stake that starts earning APR/curation rewards immediately. It fires regardless of whether your order eventually finds a counterparty. Once-per-account.
|
||
|
||
**2. First completed trade → 10 Blurt liquid + 10 Blurt Power.** When you complete your first actual trade (counterparty signs feedback citing the order), Morphit sends you 10 Blurt liquid plus 10 Blurt Power (≈13 BP of voting weight). "Completed" means: you posted an order, a counterparty responded, the trade settled off-platform, and the counterparty signed positive feedback about you that cites your order. That feedback is what triggers this bonus — it's proof of a real trade with another human, not just a posted-and-abandoned order.
|
||
|
||
**3. Loyalty milestones → up to 1,260 BP.** As you pay more Blurt fees over time, you cross 100/500/2,000/10,000 Blurt thresholds and receive delegation increases (10/50/200/1,000 BP at each tier). See the loyalty FAQ for details.
|
||
|
||
Why the staggered design: handing out the full bonus at signup would be farmed by Sybil accounts in minutes. The 1 BP welcome on first paid fee is a small enough amount that Sybil farming is unprofitable ($0.125 cost per attacker per 1 BP), and the larger 10 Blurt liquid + 10 Blurt Power requires real trade evidence (counterparty feedback). Both add up to meaningful staking weight for honest users.
|
||
|
||
If you trade exclusively in non-Blurt assets (BTC, XMR, USDT, USDC, DAI, BCH, LTC, DASH, DOGE, ZEC, ARRR, DCR, SOL, ETH, or XRP) and never pay a Blurt listing fee, you'll receive the 10 Blurt liquid + 10 Blurt Power from your first completed trade but not the 1 BP first-fee welcome (which is Blurt-fee-gated). The Blurt bonus is harmless to receive and ignore — it can sit in your account indefinitely or cover future network fees.
|
||
|
||
The rewards arrive as `delegate_vesting_shares` and `transfer` ops from @morphit-relay in your account history.
|
||
|
||
---
|
||
|
||
## How do loyalty rewards work? (The BP milestones I saw mentioned)
|
||
|
||
**FAQ key:** `loyalty_milestones`
|
||
|
||
Every time you pay a listing fee in Blurt, your cumulative lifetime spending with Morphit is tracked. When you cross certain thresholds, Morphit sends you a Blurt Power (BP) delegation as a thank-you. Four tiers:
|
||
|
||
• 100 Blurt paid cumulatively → 10 BP delegated
|
||
• 500 Blurt paid cumulatively → 50 BP delegated
|
||
• 2,000 Blurt paid cumulatively → 200 BP delegated
|
||
• 10,000 Blurt paid cumulatively → 1,000 BP delegated
|
||
|
||
The thresholds measure cumulative lifetime Blurt fees paid — they don't reset, and they don't require the fees to be recent. If you pay 100 Blurt of fees over two years of trading, you still get the 10 BP reward the moment you cross the threshold.
|
||
|
||
BP (Blurt Power) gives you voting weight on Blurt content across blurt.blog, blurt.media, and any other Blurt frontend. It's a "you matter more in this network" stake. You don't spend it by voting; your voting weight refills over time. And votes you cast can earn you curation rewards when you vote early on content that later becomes popular.
|
||
|
||
Important mechanics to know:
|
||
• The milestones only count fees paid in Blurt. BTC/XMR fees and waived-first-buy orders don't count toward the thresholds. This is deliberate — the loyalty program exists to reward users who support the Blurt economy.
|
||
• The reward is a DELEGATION, not a transfer. Morphit delegates BP to your account, and retains the ability to undelegate if the account is later found to be engaged in abuse (fake trades, sybil attacks). For honest users this never matters.
|
||
• Each tier fires once per account. If you cross 100 Blurt, then later 500, you get 10 BP + 50 BP = 60 BP total delegated. Not "the bigger tier replaces the smaller" — they add up.
|
||
• You see the milestone arrive as a delegate_vesting_shares op from @morphit-relay in your account history. It shows up in Blurt wallet UIs as incoming BP.
|
||
|
||
These four loyalty tiers stack on top of two earlier welcome rewards: the **1 BP delegation** you receive on your first Blurt-paid listing fee, and the **10 Blurt liquid + 10 Blurt Power** you receive after your first completed trade. Together, an active trader can accumulate up to 1,261 BP in total delegations over their Morphit lifetime, all of which translates directly into voting weight in the wider Blurt social network. See the welcome-bonus FAQ for the full three-tier reward system.
|
||
|
||
---
|
||
|
||
## Why no Escrow or Arbitration service?
|
||
|
||
**FAQ key:** `no_escrow_arbitration`
|
||
|
||
Escrow is a babysitter who holds your money until the trade finishes. If you and the other kid argue, the arbitrator is the referee who decides who gets the toys.
|
||
|
||
The risk:
|
||
You stopped trusting the other person… and now you have to trust the babysitter AND the referee instead. Both are centralizing — they become the new middleman with power over your money. If they're dishonest, slow, biased, or get hacked, your money can still disappear.
|
||
|
||
Bottom line:
|
||
Escrow + arbitration just moves the trust problem to a different person/group.
|
||
|
||
Don't trust. Verify.
|
||
#reputation
|
||
|
||
---
|
||
|
||
## What does the 'No JS' link in the footer do?
|
||
|
||
**FAQ key:** `no_js_limits`
|
||
|
||
It links here, to explain how Morphit behaves without JavaScript — it isn't a switch that turns JS off (a link can't; your browser controls JavaScript).
|
||
|
||
You don't need a special mode: browsing already works with JavaScript disabled. Every page — orderbook, FAQ, profiles, feedback — is statically rendered, so turn JS off in your browser and reload and the pages still render. JavaScript only powers the interactive layer (placing orders, decrypting chat, signing feedback, switching language without a reload), because that cryptography runs in your browser, never on a server.
|
||
|
||
Morphit is a static, prerendered site with no per-request server, so there's no one-click "no-JS" URL — but disabling JavaScript in your browser gives you that result today.
|
||
|
||
---
|
||
|
||
## How do I run a Morphit node?
|
||
|
||
**FAQ key:** `how_to_run_node`
|
||
|
||
A Morphit node is two services running on a server you control: the indexer (reads the blockchain, stores what it finds) and the relay (signs the occasional auxiliary op on Morphit's behalf, like delegating BP to new traders). The web app you see at morphit.io is a third piece, and you can host your own copy of that too if you want to brand the interface for your community.
|
||
|
||
Hardware requirements are modest — a Raspberry Pi 4, an old laptop, or a $5/month VPS all work. See "What are the minimum hardware requirements to run a Morphit node?" for the full breakdown across hobbyist, serious, and spare-laptop tiers. You don't need to run a Blurt witness or full chain node — the indexer reads from public RPC endpoints over HTTPS.
|
||
|
||
The setup walkthrough is at /run-a-node. The complete runbook, including systemd units, reverse-proxy config, TLS, and the monthly maintenance checklist, lives in docs/OPERATIONS.md in the Morphit repo.
|
||
|
||
Running a node lets you register as an operator and earn a generous share of the listing fees your instance attracts — 90% of every Blurt-paid fee, automatically delivered on-chain. See "How do operators earn?" for the full economics. You can also run a node purely for uncensorability — if morphit.io is blocked in your region, your instance isn't, and your community has somewhere to trade.
|
||
|
||
---
|
||
|
||
## How do operators earn?
|
||
|
||
**FAQ key:** `how_operators_earn`
|
||
|
||
Every Morphit order costs a small listing fee — $0.25 base if paid in BTC or XMR, or $0.125 if paid in Blurt (a deliberate 50% discount for Blurt-paid fees, because we want freemarket economies to thrive). #agorism When a user posts an order through your operator-branded frontend, your operator tag is included in the order op, and you instantly earn a 90% share of the Blurt listing fees paid by your users.
|
||
|
||
**The split is asymmetric — and it's asymmetric on purpose, in your favor.**
|
||
|
||
**For Blurt-paid listing fees: 90% goes to you, 10% goes to the Morphit treasury.**
|
||
|
||
Yes, you read that right. Ninety percent. The operator who attracted the order keeps the lion's share. The 10% the project keeps covers the welcome bonus (10 Blurt + 10 BP granted to every new trader after their first trade), the loyalty milestone delegations (up to 1,000 BP for active traders), and the relay's account-creation costs (~100 Blurt per new signup, on Morphit's tab). Without a small slice flowing back to the project, that whole onboarding economy can't sustain itself — and your instance benefits from a larger network of trained, account-funded users.
|
||
|
||
**For BTC-paid and XMR-paid listing fees: 100% flows to the Morphit treasury, 0% to operators.**
|
||
|
||
We want to be transparent about this because we know it sounds unfair at first glance. Here's why it works this way, and why we still think you come out ahead:
|
||
|
||
**The honest mechanics.** The on-chain payout system operates in Blurt. When a user pays a listing fee in Blurt, the chain itself can split it — that's how the operator share is delivered automatically. When a user pays in BTC or XMR, those funds land in cold-stored Morphit-controlled wallets, off the blockchain entirely. There's no clean automated way to split BTC or XMR back to operator accounts on every fee receipt; it would require either a custodial off-chain bookkeeping system (defeating the non-custodial design) or batching and converting (introducing exchange-rate risk and operational complexity). So we made a deliberate trade-off: keep BTC/XMR fees centralized to fund the project's Blurt-denominated obligations (welcome bonuses, loyalty milestones, account-creation funding, audits, infrastructure), and **make the Blurt split aggressively generous to make up for it.**
|
||
|
||
**Why 90% on Blurt specifically.** A 50/50 split would be fair if the BTC/XMR side were also 50/50. Since the BTC/XMR side is 100/0 (in the project's favor by mechanic, not by greed), we lean the Blurt side hard the other way. 90/10 means an operator running a busy instance whose users mostly pay in Blurt earns close to the full fee value — meaningfully more, in expectation, than the original 50/50-on-everything model would have produced for most usage patterns.
|
||
|
||
**What this means in practice.** If your users tend to pay in Blurt (which is rewarded by loyalty milestones), you keep 90% of the listing-fee value. If they tend to pay in BTC or XMR, you don't earn from those fees directly — but the funds Morphit collects there pay for the BP welcome stake every new user on your instance receives, which is real value flowing into your trader base. Your users' wallets get topped up with BP they can use to vote on Blurt social content, building stake that keeps them engaged with the broader ecosystem your instance serves.
|
||
|
||
**Payouts are denominated in Blurt.** If the Blurt price rises, your earnings rise with it, with zero additional work.
|
||
|
||
**Open source so you can verify.** The fee model lives in the indexer source code (AGPL-3.0). Anyone can read the payout logic and prove the split percentages match what's described here — no trust required.
|
||
|
||
**No employment relationship.** There's no contract, no service agreement, no human counterparty. The Morphit project cannot fail to pay you because the chain pays you, deterministically, from funds that were never touched by a human hand.
|
||
|
||
---
|
||
|
||
## How do I find a good operator to use?
|
||
|
||
**FAQ key:** `how_to_find_good_operator`
|
||
|
||
Every Morphit instance you can reach is on the /operators directory, with each operator's account name, display name, operator tag, contact URL, orders-attributed count, and cumulative earnings.
|
||
|
||
Signals that an operator is worth trusting:
|
||
|
||
• Long registration history without a gap. An operator whose first-registered date is over a year old and who's still active is making a long-term commitment, not running an exit-scam test.
|
||
|
||
• Orders attributed. A high total tells you their instance actually gets used — real traders trust it, which is harder to fake than a polished-looking frontend.
|
||
|
||
• Verifiable contact channel. Does their contact URL lead to a real person/team with a reputation outside Morphit? A PGP-signed introduction post on their community forum is worth more than a generic @handle.
|
||
|
||
• They publish their own node health. The indexer has a /v1/health endpoint exposing indexed-block lag; operators who proxy this publicly demonstrate they care about uptime.
|
||
|
||
What doesn't matter much:
|
||
|
||
• Which language the interface is in. The chain data is the same for all operators — every Morphit instance sees the same orderbook. An operator serving your region in your language is convenience, not trust.
|
||
|
||
• Fancy visuals. An operator can run off-the-shelf Morphit with no theming changes and still be 100% reliable. Judge on uptime + attribution history, not polish.
|
||
|
||
Importantly: no operator can see or move your funds. Your keys stay in your browser; your fees go to the Morphit fee recipient account, not to any operator directly. Even a malicious operator can only harm you by showing you stale data or by refusing to serve you — in either case, switch to another operator and carry on.
|
||
|
||
A bad operator is an inconvenience, never a loss.
|
||
|
||
---
|
||
|
||
## How does Morphit chat work?
|
||
|
||
**FAQ key:** `what_is_morphit_chat`
|
||
|
||
Morphit chat is end-to-end encrypted messaging between two traders. Messages are encrypted on your device, stored as ciphertext on the blockchain, and decrypted only by the recipient's device. No Morphit server, operator, or chain observer ever sees plaintext.
|
||
|
||
What you get:
|
||
|
||
• **Durable.** Close the tab, come back tomorrow, the conversation is still there. Messages live on the blockchain; they persist without Morphit running any server.
|
||
|
||
• **Private.** Only you and your counterparty can read the message content. Ciphertexts on chain are opaque blobs to everyone else.
|
||
|
||
• **No setup.** You don't manage a chat key. Your chat identity is derived automatically from your posting key when you open chat for the first time.
|
||
|
||
• **Operator-resistant.** Morphit's operators route broadcasts but can't decrypt them. Even if one operator were compromised, your chat content stays private.
|
||
|
||
What's visible on chain (not private):
|
||
|
||
• Who you chatted with, and when. Sender, recipient, and timestamp are on-chain metadata, not encrypted. (ie: @scooby chatted (something illegible) with @dingleberry)
|
||
|
||
• Rough message size — an attacker can see roughly the size of the message that they sent.
|
||
|
||
If you need fully metadata-private messaging, use something like Session (getsession.org) or Signal out-of-band alongside Morphit for sensitive details.
|
||
|
||
---
|
||
|
||
## What happens if I lose my chat key?
|
||
|
||
**FAQ key:** `chat_key_loss`
|
||
|
||
You can't "lose" your chat key separately — it's derived from your posting key (see 'Do I need to set up a separate key to use chat?'). Losing your chat key happens only if you lose your seed phrase / posting key, which is the same scenario as losing access to your entire account.
|
||
|
||
If you lose access to your posting key:
|
||
• You can't sign any Morphit op (post orders, leave feedback, send chat).
|
||
• You can't decrypt past chat messages sent to you.
|
||
• Morphit cannot help recover — we don't custody keys.
|
||
|
||
The only safety net is your 12-word seed phrase, written down at onboarding. If you have it, sign back in with it and everything (including past chat) is recoverable. If you don't, the account is inaccessible to you.
|
||
|
||
See 'What if I lose my password or recovery seed?' and 'How do I back up my Morphit account?' for the canonical instructions.
|
||
|
||
---
|
||
|
||
## Why is chat on the blockchain instead of a regular server?
|
||
|
||
**FAQ key:** `why_chat_on_chain`
|
||
|
||
Two reasons: no dependence on Morphit's infrastructure, and chain-level durability.
|
||
|
||
If chat ran on a Morphit server:
|
||
|
||
• Morphit could be coerced into handing over ciphertexts by any authority with jurisdiction. That's still end-to-end encrypted so the content is safe, but the metadata — who chatted with whom, when — is not.
|
||
|
||
• Morphit going offline (DDoS, legal action, bankruptcy) means chat goes offline. For a two-day trade where buyer and seller need to communicate, that's a real risk.
|
||
|
||
• Operators would have to rely on a centralized service to get chat functionality, undermining the whole point of Morphit being operator-pluggable.
|
||
|
||
On-chain chat instead means:
|
||
|
||
• Any indexer can serve the messages. If Morphit's default indexer is unreachable, a user can point their client at a different one.
|
||
|
||
• Ciphertexts are immutable once confirmed. Nobody can edit or retroactively censor them.
|
||
|
||
• There's exactly one source of truth. No sync headaches between Morphit's copy and yours.
|
||
|
||
The tradeoff is block latency: messages confirm in ~3 seconds (the chain's block time) rather than instantly. For trade coordination — the main use case — this is fine. For casual real-time chat, it's a semi-noticeable delay.
|
||
|
||
---
|
||
|
||
## Does Morphit require KYC, identity verification, or government ID?
|
||
|
||
**FAQ key:** `kyc_requirement`
|
||
|
||
No. Morphit never asks for your identity, your name, your phone number, your government ID, a selfie, or proof of address. You don't upload a passport, you don't verify anything. Morphit is KYC-free (Know-Your-Customer-free) because it never holds your money — so there's no regulator forcing it to identify you. The only thing Morphit ever sees is an account name that you chose yourself. You don't even need an email address. If a site calling itself Morphit asks you for ID, that's not Morphit — that's a phishing scam. Close the tab.
|
||
|
||
---
|
||
|
||
## How do I trade on Morphit — a step-by-step walkthrough?
|
||
|
||
**FAQ key:** `how_to_trade_walkthrough`
|
||
|
||
New to Morphit? Here's the full first-time user walkthrough, from start to finish. **Step 1:** Create a free account (one click, no email, no ID). **Step 2:** Write down your 12-word recovery phrase on paper (and/or encrypted in an offline password manager like KeePass) and store it somewhere safe. **Step 3:** Browse the orderbook and find a counterparty whose offer matches what you want — the right asset, the right price, a payment method you can use, good feedback history. **Step 4:** Open a chat with them using the encrypted chat button on their order. **Step 5:** Agree on specifics (exact amount, meetup if cash-in-person, which bank account for transfer, etc). **Step 6:** One of you sends the fiat/crypto first depending on your agreement; the other sees it arrive and sends the other side. **Step 7:** Leave each other feedback so future traders can see you're trustworthy. That's it. Morphit is just the bulletin board that connects you; the actual trade happens between the two of you directly.
|
||
|
||
---
|
||
|
||
## Does Morphit work in my country?
|
||
|
||
**FAQ key:** `supported_countries`
|
||
|
||
Yes. Morphit works in every country because Morphit doesn't operate from any specific country — it's a decentralized bulletin board published to a public blockchain. You can browse, post, and trade from anywhere with an internet connection. There are no IP blocks, no country-of-residence checks, no geographic restrictions built into the software. If your country blocks access to crypto services, the Tor / Lokinet / I2P / `.eth` mirrors let you reach Morphit anyway (see the footer icons). That said: please understand your own country's laws about crypto trading. Morphit doesn't enforce any country/corporation's rules — that's between you and the government that you consent to (govern = control, ment = mind. Mind Control). Their flag is their corporate logo. You are a living male or female, not a corpse (hence the term corporation). Starve the beast. #agorism #freemarkets #countereconomics
|
||
|
||
---
|
||
|
||
## Which fiat currencies (USD, EUR, local money) does Morphit support?
|
||
|
||
**FAQ key:** `supported_fiat_currencies`
|
||
|
||
All of them. Morphit doesn't restrict fiat currencies; when you post an order you type whichever currency code you want — USD, EUR, GBP, JPY, BRL, INR, NGN, ARS, PHP, anything. The orderbook filter lets other users find your currency. There are no 'unsupported' currencies — if two people want to trade crypto for that currency, they can post about it.
|
||
|
||
---
|
||
|
||
## What happens if my trading partner disappears or stops responding mid-trade?
|
||
|
||
**FAQ key:** `counterparty_disappears`
|
||
|
||
This is why reputation matters. Morphit has no escrow, no arbitration, no customer service that can reverse a trade — so if someone sends crypto first and then the counterparty vanishes without paying, the crypto is gone. Protect yourself: (1) only trade with accounts that have strong feedback history and visible trade volume, (2) for larger amounts, split the trade into smaller pieces and check feedback between each, (3) use the immutable, encrypted chat to confirm every step so there's a trail if things go wrong, (4) if you're the seller, wait for the fiat to fully clear before releasing crypto (bank transfers can be reversed for days). If someone scams you, leave provable, sourced, detailed, honest feedback so the next person sees the warning. You only get one feedback field per trade, so make it count. Feedback is on-chain and permanent.
|
||
|
||
**If people are going to trust you, your reputation is everything.**
|
||
|
||
---
|
||
|
||
## Do I owe taxes on trades I make through Morphit?
|
||
|
||
**FAQ key:** `taxes`
|
||
|
||
Depending on your stance regarding income taxes (we consider it theft), most people would answer yes to that question.
|
||
|
||
Morphit doesn't report anything to any tax collector — we have no idea who you are anyway. (@scoobydoo did 27 trades last year. So what?!)
|
||
|
||
Most countries/corporations scare people into reporting their gains (sometimes as capital gains, sometimes as income, their rules vary widely).
|
||
|
||
Knowledge is power. Obey authorities (so-called) at your own expense.
|
||
|
||
Morphit gives you an immutable, on-chain trail you can reference any time from anywhere, but your consent to reporting your gains is all on you.
|
||
|
||
The beast needs your consent and participation, or else it dies.
|
||
#donoharm #agorism
|
||
|
||
---
|
||
|
||
## Does Morphit work on mobile phones, iPad, or only desktop?
|
||
|
||
**FAQ key:** `mobile_desktop`
|
||
|
||
Morphit runs in any modern browser — desktop, laptop, tablet, phone. There's no app to install, no permissions to grant. The site is responsive and usable at phone screen sizes. On iOS use Safari or Brave; on Android use Brave, Firefox, or Chrome. **Also fully supported: Google Pixel phones and GrapheneOS** — GrapheneOS is the privacy-first Android we actually recommend for Morphit users, since it doesn't have Google's sideload restrictions. The Tor Browser and Mullvad Browser both work on desktop; Onion Browser works on iOS; Orbot + Chrome works on Android. No 'native app' is planned — a browser is enough, and building apps would require app-store gatekeepers who could remove us at their discretion.
|
||
|
||
---
|
||
|
||
## How do I trade anonymously or privately on Morphit?
|
||
|
||
**FAQ key:** `privacy_practices`
|
||
|
||
Morphit is privacy-protective by default: no KYC, no account linking, no tracking. To go further: (1) use a VPN or Tor to hide your IP from everything, (2) create a fresh account for Morphit, separate from any you use for blogging, (3) never type your legal name or phone number in chat or order notes, (4) always use new Bitcoin/Monero receiving addresses for each trade (Monero does this automatically — that's one reason we love XMR), (5) trade Monero when possible; its on-chain privacy is vastly stronger than Bitcoin's, (6) for cash-in-person, meet in neutral public places and don't share personal info beyond what's needed for the meet. Privacy is a practice, not a setting — but Morphit's architecture lets you practice it. For asset-specific privacy guidance, see the per-asset guides at /privacy/{asset} (e.g. /privacy/btc, /privacy/ltc).
|
||
|
||
---
|
||
|
||
## Should I trade in person (cash meetup) or online (bank transfer)?
|
||
|
||
**FAQ key:** `in_person_vs_online`
|
||
|
||
Both work. Cash in person is the most private — no paper trail, no bank involvement — but requires physical trust (meet in public, ideally in daytime, maybe bring a friend for larger amounts). Online via bank transfer or payment app is more convenient but creates records your bank can see and potentially reverse (wire reversals, chargebacks). For sellers accepting online fiat: wait for the money to fully clear, not just 'appear pending.' For cash meets: both parties should confirm the on-chain send before parting. Morphit doesn't enforce either style; use whatever matches the trust level of your counterparty and the trade size.
|
||
|
||
---
|
||
|
||
## What scams should I watch out for on Morphit?
|
||
|
||
**FAQ key:** `scam_patterns`
|
||
|
||
The classics: (1) **Reversible payment bait** — someone pays you with a method that can be reversed after you send crypto (chargebacks on credit cards, wire reversals within hours, PayPal 'family and friends' that isn't). Only accept payment methods that truly clear before you release crypto. (2) **Fake chat impersonation** — a scammer pretends to be your counterparty on a different app (WhatsApp, Telegram). Stay in the encrypted on-chain chat; that's the only channel tied to the Morphit account. (3) **Phishing sites that look like morphit.io** — always check the URL, and bookmark the real one. (4) **New accounts offering too-good prices** — if someone with zero feedback offers 10% above market, that's bait. (5) **'Test trade' escalation** — small successful trade to build trust, then a large one that scams. Feedback is your defense; use it.
|
||
|
||
---
|
||
|
||
## Do I need technical skills to run a Morphit node? How hard is it?
|
||
|
||
**FAQ key:** `node_technical_skills`
|
||
|
||
You need basic Linux comfort: SSH into a server, run a shell command, edit a config file. If you've set up a home NAS, a personal VPN, or a self-hosted app before, you have enough. If you've never done any of those things, our `/run-a-node` guide walks through each step, and the Agorise Matrix channel (`#agorise:matrix.org`) has operators happy to help newcomers. The software itself is Docker-friendly and the setup is one command. No blockchain-node experience needed — Morphit reads from public blockchain nodes, not its own chain node. Hosting a Morphit instance is much closer to 'run a web app' than 'run a blockchain validator.'
|
||
|
||
---
|
||
|
||
## How much does it cost to host a Morphit node?
|
||
|
||
**FAQ key:** `node_hosting_costs`
|
||
|
||
Very little. A small VPS (4GB RAM, 20GB disk) runs Morphit comfortably and costs about $5-8/month from providers like Hetzner, OVH, Vultr, or DigitalOcean. Disk storage grows slowly — the indexer stores on-chain events and the cache doesn't balloon. Bandwidth is minimal for a small instance (a few GB per month per hundred active users). If you already run a personal server or homelab, Morphit adds negligible load. Operator fees collected from orders are specifically sized to cover this and leave margin for your time (see the operator-earnings FAQ for the split math).
|
||
|
||
---
|
||
|
||
## If one Morphit instance goes down, do I lose my orders and reputation?
|
||
|
||
**FAQ key:** `switching_instances`
|
||
|
||
No — that's the whole point of the federated design. Your orders, profile, feedback, and chat history live on the underlying blockchain, not on any single Morphit instance. If morphit.io goes down, any other operator's instance shows you the same data, from the same chain, with zero migration step. You don't even need to sign in again — your keys decrypt the same content everywhere. The instance is a view into the chain; the chain is the source of truth. Operators come and go; your reputation is yours forever.
|
||
|
||
---
|
||
|
||
## How do I back up my Morphit account? What should I write down?
|
||
|
||
**FAQ key:** `backup_practices`
|
||
|
||
Write down your 12-word recovery phrase on paper, in order, exactly as shown. That phrase is everything — it regenerates every key Morphit uses. Store the paper somewhere safe and not networked: a fireproof box, a bank safety deposit box, somewhere a fire or theft can't hit the same place as your computer. Never photograph it, never email it to yourself, never paste it into a password manager that syncs to the cloud. Besides paper, we personally like to use the encrypted password manager called KeePass. Never type it into any site that isn't Morphit. For extra durability: write two copies, store them in separate locations. For very high value: engrave it on a steel plate — paper burns and water destroys it, metal survives both. Your 12 words are your account; protect them like cash.
|
||
|
||
If you signed in with an existing Blurt account, you have no 12-word phrase and there can't be one — a phrase *derives* keys, and it cannot be built backwards from keys you already had. Your backup is your Keyfile, downloaded from the Back up my keys page. If you chose to keep your Active key on this device, that Keyfile holds both your Posting and Active keys, encrypted with your Morphit password. Treat it exactly like the paper above.
|
||
|
||
---
|
||
|
||
## Is there a minimum or maximum trade size on Morphit?
|
||
|
||
**FAQ key:** `trade_size_limits`
|
||
|
||
No hard limits — the software doesn't enforce any. You can post an order for 5 USD worth of BTC, or 50,000 USD worth. What matters is finding a counterparty willing to match your size, which is easier in the middle (50-500 USD range) and harder at the extremes. For very small trades, fees and payment-method minimums may make it impractical; for very large trades, split across several smaller ones with feedback between each to reduce counterparty risk. Some payment methods have their own limits (bank wire minimums, daily transfer caps) — check before agreeing.
|
||
|
||
---
|
||
|
||
## If a bad operator starts lying to users, can you shut them down?
|
||
|
||
**FAQ key:** `rogue_operator`
|
||
|
||
Short answer: **no**, and that's a feature, not a bug.
|
||
|
||
Anyone can set up a Morphit instance. They pay for their own server, they run the open-source code, they read the public blockchain. There is no central authority that approves operators or can take them offline. Nobody issued them a license we can revoke.
|
||
|
||
Specifically, we cannot: (1) make their server stop — we have no access to it, (2) block users from reaching them — there's no central gateway, (3) stop them from reading the blockchain — it's public, (4) stop them from collecting operator fees if users post through their frontend — the protocol treats all operators the same, (5) sue them — they're anonymous, no KYC, no jurisdiction, no company.
|
||
|
||
What we **can** do is **warn** users. If an operator serves fabricated data, runs a phishing clone, or lies about on-chain state, we tell people via channels we control: our homepage, Matrix (`#agorise:matrix.org`), the `@morphit` account, the signed release-op on the chain. Users read those sources and decide for themselves which instance to trust.
|
||
|
||
We also publish tools so users can verify an instance themselves: the site's bundle hash is signed on-chain; any instance serving a tampered bundle will visibly mismatch.
|
||
|
||
The honest framing: "stopping" is not the goal, because if we could stop a rogue operator, a government could pressure us to stop a good one. The moment central shutdown exists, censorship-resistance dies. The goal is **truth** — giving users the information to choose well.
|
||
|
||
The practical consequence: **a better-looking operator with better uptime should get more users and earn more than morphit.io**. That's correct. That's the market working. We keep morphit.io worth using by making it actually better, not by blocking competitors.
|
||
|
||
---
|
||
|
||
## What is a Monero TxID and where do I find it?
|
||
|
||
**FAQ key:** `xmr_txid`
|
||
|
||
A Monero TxID (transaction ID) is a 64-character hexadecimal string that uniquely identifies a single Monero transaction on the XMR blockchain. It looks like this: `c1a2b3…deadbeef`. Morphit asks for a TxID when you need to provide proof that you sent or received a Monero payment — e.g. attesting that a counterparty's claimed XMR transfer actually landed.
|
||
|
||
Where to find it:
|
||
• In **Monero GUI wallet**: open Transactions, click the transaction you want, the TxID is the long hex string at the top of the detail panel. Copy button is right there.
|
||
• In **Cake Wallet / Monero.com mobile**: tap the transaction in your history; the TxID appears at the top and has a copy icon.
|
||
• In **Feather Wallet**: Transactions tab → right-click or tap a row → Copy → Transaction ID.
|
||
• In **command-line monero-wallet-cli**: the TxID is printed when you run `show_transfers out` — it's the long hex after the date.
|
||
|
||
The TxID is public information (it's visible to anyone with a blockchain explorer). Posting it to Morphit to attest a trade does NOT reveal who you are, your view key, or your balance — just that a specific transaction happened.
|
||
|
||
**One honest note for privacy maximalists.** If you choose to pay your *listing fee* in Monero, the fee transaction's TxID is recorded in your order op on the public blockchain (so any indexer can verify the fee without the treasury view key). That is the only place a Monero TxID ever touches the Blurt chain — and it's a ~$0.25 fee to the public treasury address, never your actual trade settlement (the XMR you sell to a counterparty moves peer-to-peer and never touches the Blurt chain). If you want *zero* linkage between Monero and the blockchain, simply pay your listing fee in BLURT — it's the default, it's half the price, and no XMR TxID is broadcast at all.
|
||
|
||
---
|
||
|
||
## What is a Monero tx_proof and why does Morphit ask for one?
|
||
|
||
**FAQ key:** `xmr_tx_proof`
|
||
|
||
A Monero tx_proof (transaction proof) is a short string from your own wallet that proves you paid a specific transaction to a specific address — without revealing anything else about your wallet. It looks like `OutProofV2…` followed by a long base58 string.
|
||
|
||
**Why Morphit asks for one.** Morphit verifies your XMR fee by checking on the blockchain that your payment landed at the treasury address with the right amount. To do that without holding the treasury wallet's view key (publishing a view key would deanonymize every fee payment forever — see the privacy invariant in OPERATIONS.md §40.2), every Morphit instance asks YOU to generate a per-payment proof from your own wallet. Any indexer can verify your proof using public data; no privileged party is needed.
|
||
|
||
**What it reveals.** The proof reveals only:
|
||
• That this specific transaction (the txid you supplied) paid this specific address (Morphit's treasury), and
|
||
• The amount that was paid.
|
||
|
||
**What it does NOT reveal.** It does NOT reveal:
|
||
• Your other transactions
|
||
• Your wallet balance
|
||
• Your other addresses
|
||
• Any wallet metadata
|
||
• Anything about future payments
|
||
|
||
The proof is one-time and per-payment. Possessing one proof tells an outsider nothing about other payments to the address (yours or anyone else's) or any other wallet activity.
|
||
|
||
**How to generate one.**
|
||
• **Monero CLI**: `get_tx_proof <txid> <treasury-address>`
|
||
• **Monero GUI**: Advanced → Prove transaction → fill in txid + address → Generate
|
||
• **Cake Wallet**: Settings → Privacy → Verify a transaction → Generate proof
|
||
• **Feather Wallet**: Tools → Prove/check transaction → Generate
|
||
|
||
You'll get a string starting with `OutProofV1` or `OutProofV2`. Paste that into the Payment proof field.
|
||
|
||
**Why this is better than a view key.** A view key would let any holder see every payment to the address forever. A tx_proof reveals one payment, period. This means every Morphit instance — yours, the canonical one, a community operator's — can verify XMR fees independently without needing a shared secret. That's the federation working as intended.
|
||
|
||
---
|
||
|
||
## Why is Morphit's source mirrored to so many code hosts?
|
||
|
||
**FAQ key:** `morphit_mirrors`
|
||
|
||
Decentralization — it's priority #2 in Morphit's design, right behind privacy. A project that lives in one place can be killed in one place: a platform can suspend the account, a government can order a takedown, a host can simply disappear. So Morphit's source code (AGPL-3.0) is mirrored across many independent code hosts — our own Forgejo server at git.agorise.net is the canonical copy, GitHub, Codeberg, SourceForge, SourceHut, GitLab, Bitbucket, and Launchpad are live, plus a content-addressed copy on IPFS that no single host controls. If any one of them blocks or drops Morphit, every other copy is still there — and because it's AGPL, anyone can re-host, audit, or fork it. The full, current list is on the Download page.
|
||
|
||
(There's nothing to install from an app store — Morphit runs as a Progressive Web App (PWA) you add straight from your browser. The mirrors are for the source code, so the project can't be silenced by taking down a single repository.)
|
||
|
||
You can confirm any running instance serves untampered code: each release's SHA-256 hashes are published on the blockchain — see /about-this-instance.
|
||
|
||
---
|
||
|
||
## How do I install Morphit on Android?
|
||
|
||
**FAQ key:** `android_sideload`
|
||
|
||
Open Morphit in Chrome, Brave, or any browser, open the menu (⋮), and tap "Install app" (or "Add to Home screen"). The icon lands on your home screen, runs fullscreen, works offline, and updates itself.
|
||
|
||
There's no APK, so Google's sideloading hurdles don't apply — and that sidesteps the Android install lockdown Google began rolling out in 2026 (developers must register with Google, accept its terms, pay a fee, and hand over government ID before their apps can install). A PWA installs straight from the web, with no developer registration and no gatekeeper who can pull it.
|
||
|
||
---
|
||
|
||
## How does someone become a Morphit operator?
|
||
|
||
**FAQ key:** `operator_registration`
|
||
|
||
Anyone can run a Morphit operator node. The technical setup is documented at /run-a-node.
|
||
|
||
To claim an operator tag (the identifier that appears in orders placed through your instance), you broadcast a one-time `morphit_operator_register_v1` op on-chain containing your chosen tag (1-64 chars, lowercase letters/digits + dashes/underscores/dots only). Tags are first-come-first-served: if @alice registers "alice-exchange" at block 1000, nobody else can use that tag.
|
||
|
||
The registration op is signed by your posting key, so only you control your tag. Morphit the project does not approve or deny operators — any account can register, and every order placed through your frontend immediately counts toward your fee earnings (see "How do operators earn?"). The tag is also how users identify which operator onboarded them — it appears on /operators and in the order metadata.
|
||
|
||
---
|
||
|
||
## When do operators get paid their fee share?
|
||
|
||
**FAQ key:** `operator_payouts_timing`
|
||
|
||
Immediately — in the very transaction the user pays. Each Blurt listing fee is split at payment time: the user's fee transaction sends 90% straight to your fees account and 10% to the Morphit treasury, in the same transaction. Your share lands in one Blurt block (~3 seconds), with no forwarding step and nobody who has to pass it along to you.
|
||
|
||
There is no batching, no weekly payout cycle, no "minimum threshold to withdraw," and no relay in the middle. Each Blurt-paid order pays your share directly, on chain.
|
||
|
||
**Important: operators earn from Blurt-paid fees only.** BTC- and XMR-paid listing fees go 100% to the Morphit treasury (`@morphit-fees`) — see the "How do operators earn?" entry for the full rationale of why the Blurt split is 90/10 (heavily operator-favored) while the BTC/XMR path is 100/0 (treasury-only). In short: a Blurt payment can carry the split on-chain in a single transaction, while BTC/XMR would require off-chain custodial bookkeeping that breaks Morphit's non-custodial design.
|
||
|
||
This is one of the clearest non-custodial advantages over traditional exchange partnerships. You never wait for a "payout schedule," and Morphit the project never holds your earnings at any point — the user pays you directly on chain, deterministically, with no human involvement, fully auditable from chain history.
|
||
|
||
---
|
||
|
||
## Can operators block or ban specific users from their instance?
|
||
|
||
**FAQ key:** `operator_moderation`
|
||
|
||
Yes — an operator can review abuse signals and block an account on their own instance using the `morphit-ops` moderation tools. The block is enforced server-side: the indexer stops serving that account's listings anywhere this instance shows them — the orderbook, the per-account view, featured slots, the RSS feeds, and the live stream. When the blocked person is signed in here, they see a clear banner explaining their posts are hidden on this instance only.
|
||
|
||
What this does NOT do:
|
||
- Affect the chain. The blocked account's orders still exist on-chain and stay visible via every other operator instance or a direct chain query.
|
||
- Touch the account's funds, keys, or identity — and it has no effect on any other Morphit instance. It is fully reversible.
|
||
- Prevent the blocked person from trading. They can use a different instance, their own self-hosted instance, or raw chain tools — there is no restriction at the protocol level.
|
||
|
||
Operators can moderate spam and abuse on their own instance only, transparently (no operator can censor silently). Selling goods or services that would initiate harm for example. #donoharm #agorism Operators can't erase anyone from the federation either — users posts are still visible through any of the other instances listed at /instances.
|
||
|
||
---
|
||
|
||
## Do I need to set up a separate key to use chat?
|
||
|
||
**FAQ key:** `chat_identity_key`
|
||
|
||
No. Your chat identity is derived automatically from your Blurt posting key the first time you open chat — no separate key to generate, back up, or lose.
|
||
|
||
How it works:
|
||
|
||
1. When you open a conversation for the first time, your client derives a dedicated X25519 keypair from your posting private key.
|
||
|
||
2. The public half is published on-chain via a one-time `morphit_chat_identity_v1` op. This takes ~3 seconds and happens in the background — you don't see it.
|
||
|
||
3. Anyone who wants to message you fetches your chat public key from the indexer and uses it to encrypt.
|
||
|
||
4. Your chat private key never leaves your browser. It's re-derived deterministically each time you open chat (so refreshing the page, or unlocking on a new device, gives you the same key back).
|
||
|
||
The tradeoff: because your chat key is derived from your posting key, someone who gets your posting key (e.g. through seed phrase theft) can also decrypt your past chats. This is acceptable because posting-key compromise already means the attacker can impersonate you on Morphit anyway. Back up and secure your 12-word seed phrase, don't leak your password either, and you're fine.
|
||
|
||
---
|
||
|
||
## What is the "Syndicate my order" checkbox?
|
||
|
||
**FAQ key:** `syndicate_trade_announcement`
|
||
|
||
On the order-posting form, you can tick "Syndicate my order to the Blurt blog". If checked, Morphit publishes a short announcement of your order to your own Blurt blog (blurt.blog, beblurt.com, etc) the moment your order is successfully broadcast. The post includes a link back to your order's page on Morphit and uses the #morphit tag so it shows up in the Morphit community feed.
|
||
|
||
The post is signed with YOUR posting key — not Morphit's, not the operator's, yours. This means:
|
||
- The post is authentically from you, not marketing spam.
|
||
- Morphit the project holds no keys that can sign social content on your behalf.
|
||
- You can edit or delete the post later just like any other post on your account.
|
||
- "Likes" that you receive on blog posts earn you more Blurt for trading and staking.
|
||
|
||
There's also a one-time announcement you can opt into: a short "I joined Morphit" post to the @morphit community (not your blog) on your FIRST trade. It's off by default — arm it with a checkbox on the order form, in Settings, or on the feedback form, and it fires once, when you leave feedback for that first trade. Afterwards the Settings card instead lets you pre-tick the per-order blog post.
|
||
|
||
---
|
||
|
||
## Does Morphit work offline?
|
||
|
||
**FAQ key:** `offline_caching`
|
||
|
||
Partially — enough that slow connections and brief offline moments don't break your browsing.
|
||
|
||
Morphit ships a service worker that caches static assets (fonts, icons, small images) locally on first visit. On repeat visits, these load instantly from your device without hitting the network. If you're briefly offline (tunnel, elevator, flaky wifi), you can still view pages you've previously loaded, and the UI will catch up when connectivity returns.
|
||
|
||
What requires a live connection:
|
||
- Fetching the current orderbook (depends on the indexer).
|
||
- Broadcasting new orders, messages, feedback (writes to the chain via the relay).
|
||
- Price feeds for USD-denominated displays.
|
||
|
||
What works offline once cached:
|
||
- Page layouts, icons, fonts, design.
|
||
- Static educational content (FAQ, /security, /plan, /backup-keys).
|
||
- Your session's identity (if you've unlocked earlier in this session).
|
||
|
||
The service worker respects Tor Browser at its highest security level (service workers disabled there) and gracefully falls back to normal browser caching — everything still works, just without the offline boost.
|
||
|
||
---
|
||
|
||
## What's the difference between Lock Session and Sign Out?
|
||
|
||
**FAQ key:** `lock_vs_signout`
|
||
|
||
**Lock Session** clears your keys from memory but keeps the encrypted keystore on this device. Next time you open Morphit on this device, you can unlock with just your password — no seed phrase needed. Think of it as "put away" — the keys are stored, you just can't use them right now.
|
||
|
||
**Sign Out** wipes the encrypted keystore from this device entirely. You'll need your 12-word seed phrase or keyfile to log back in. Think of it as "leaving this device" — no trace of your keys remains locally.
|
||
|
||
When to use which:
|
||
- **Lock Session**: your own device, walking away briefly, shared office but you trust your screen-locker.
|
||
- **Sign Out**: public computer, someone else's device, giving this laptop to a friend, any situation where you don't want keys persisting locally.
|
||
|
||
Both happen instantly — your in-memory keys are wiped in the same moment in both cases. The only difference is whether the encrypted backup stays on disk.
|
||
|
||
Note: Lock Session is only meaningful if you chose "Password (fast)" during onboarding. If you chose "Seed every time (most private)," Lock Session and Sign Out produce the same result because no keystore was ever persisted.
|
||
|
||
---
|
||
|
||
## When does my session auto-lock if I walk away?
|
||
|
||
**FAQ key:** `auto_lock_timeout`
|
||
|
||
By default, Morphit auto-locks your session after 9 hours of inactivity. This is deliberately long — shorter defaults (like the 15-30 minutes banks use) would be annoying for a trading app where you might walk away to cook dinner and come back to an offer on your order.
|
||
|
||
You can change the timeout in Settings → Session:
|
||
- As short as 15 minutes (high-security)
|
||
- Up to "never auto-lock" (you lock manually)
|
||
- Or disable the timer entirely
|
||
|
||
The 9-hour default assumes "I left my screen for the workday" rather than "I stepped away for a coffee." If you want shorter, set it shorter.
|
||
|
||
**What counts as activity:** keyboard, mouse, or touch input anywhere on the Morphit tab. The timer resets on each interaction. When the timeout fires, your session locks (same effect as clicking Lock Session from the avatar menu) — your keys are wiped from memory, but the encrypted keystore stays on the device so you can unlock with your password when you return.
|
||
|
||
---
|
||
|
||
## How do push notifications work with my privacy?
|
||
|
||
**FAQ key:** `push_notifications_privacy`
|
||
|
||
Push notifications let Morphit alert you when your order fills, a chat message arrives, or feedback lands — even when the Morphit tab is closed or your phone is locked. They require a "push service" running somewhere that holds a queue of pending notifications for you.
|
||
|
||
**The honest version:** your browser picks that push service, not us. Chrome uses Google FCM, Firefox uses Mozilla, Safari uses Apple. There is no setting anywhere — in Morphit or in your browser — that points it at a different server.
|
||
|
||
What that service sees is metadata: that this browser received a push from morphit.io at this timestamp. What it never sees is the content. Every push is end-to-end encrypted per the Web Push specification, so the push service only ever handles ciphertext. It cannot read your messages, your orders, or your balances.
|
||
|
||
If that metadata bothers you, turn push off. You still get badges on the avatar, favicon and title bar whenever the Morphit tab is open — those never leave your browser. That is the only honest way to keep Google out of it today.
|
||
|
||
**What we removed, and why.** Older builds offered a "Self-hosted only" option. It did nothing. Your choice was recorded and then ignored — Chrome still delivered through Google exactly as before — while this article told you no third party could see your pings. That was wrong, and a privacy switch that does nothing is worse than no switch, because it turns your caution into false confidence. It is gone.
|
||
|
||
We would like to do this properly with UnifiedPush, which is the one design where you really do choose your own push server. Until that exists, this page tells you what actually happens.
|
||
|
||
---
|
||
|
||
## Can I hide orders from specific users?
|
||
|
||
**FAQ key:** `user_hide_accounts`
|
||
|
||
Yes. Every order row on the orderbook has a small hide button that makes orders from that account invisible to you. This is personal to your browser — nobody else on any other Morphit instance sees your hide list, and the hidden user is never notified.
|
||
|
||
Hiding is fully reversible. Manage your hidden list from Settings → Hidden accounts. You can unhide anyone individually, or unhide everyone at once.
|
||
|
||
Transparency: when the orderbook has hidden orders on the current page, a line at the top tells you the count and offers a "Show anyway" toggle so you can peek at hidden orders without unhiding them.
|
||
|
||
What hiding does NOT do:
|
||
- Affect the chain in any way. Hidden users' orders still exist on-chain, visible via any other Morphit instance or direct chain query.
|
||
- Ban anyone from the protocol. They can still trade — your hide just removes them from your view.
|
||
- Sync across devices. This is per-browser storage. If you sign in from another device, your hide list doesn't follow.
|
||
|
||
---
|
||
|
||
## How does Morphit's reputation system work?
|
||
|
||
**FAQ key:** `what_is_reputation`
|
||
|
||
Every completed trade lets both sides leave one feedback: a 1-5 star rating and an optional comment. The feedback is posted on-chain, so it's permanent and public — anyone can read it on a trader's profile page. The profile shows a weighted average rating, a count of reviews, and a breakdown by star rating so you can see at a glance whether a trader has a consistent track record or a few outliers. There's no central arbiter; the community's own reviews are the reputation signal.
|
||
|
||
**If people are going to trust you, your reputation is everything.**
|
||
|
||
Morphit doesn't have arbitrators, escrow agents, or chargebacks. The only thing that lets a stranger trust you with their money is the visible track record you've built. Treat every trade like it matters — because every trade is a public, permanent entry on the only reputation that counts: yours.
|
||
|
||
**Your reputation score.** On order cards, Morphit distils all of this into a single reputation score from 0 to 5 (for example, 4.06), shown next to — but separate from — your trade count. The score blends your time-decayed average rating with how many trades you've completed and how recently you've been active, shrinking a thin track record toward a neutral 3.0 so a single review can't spike it. Good behaviour compounds over time; a poor rating can't be bought back with sheer volume.
|
||
|
||
|
||
---
|
||
|
||
## How do I build a high reputation score on Morphit?
|
||
|
||
**FAQ key:** `how_to_build_high_reputation`
|
||
|
||
Reputation on Morphit is built **organically** — by trading consistently, getting real feedback from real counterparties, and avoiding patterns that the code flags as suspicious. There is no shortcut. Here's exactly what factors into your score and what you should do.
|
||
|
||
**What counts toward your score** (in order of impact):
|
||
|
||
1. **Verified, completed trades.** Every order you post that pays the listing fee (`fee_status = 'verified'`) and gets a feedback row from a counterparty contributes to your weighted rating. **Unverified-fee orders cannot be cited as feedback targets** — so a counterparty can only leave you reputation-bearing feedback after you've put real economic skin in the game (the listing fee, ~$0.25 in Blurt/BTC/XMR equivalent).
|
||
|
||
2. **Recent activity counts more than ancient activity.** Morphit uses a **365-day half-life** exponential decay: a review posted today carries full weight (1.0×), a review one year old counts half (0.5×), two years old counts a quarter (0.25×), and so on. A trader with 10 fresh 5-star reviews can rank higher than a trader with 100 ancient 5-star reviews. **Trade regularly to keep your score current.**
|
||
|
||
3. **Both buy AND sell sides.** Your profile shows separate weighted ratings for buyer-side trades and seller-side trades. A trader great as a buyer but careless as a seller (or vice versa) is visible to readers. **Build reputation on both sides** by being trustworthy whether you're the one sending crypto or the one receiving it.
|
||
|
||
4. **Verified-chat badges on individual reviews.** A review carries a verified-chat badge (a small ✓ icon next to the rating) when you and your counterparty exchanged at least 2 messages each direction over a span of at least 15 minutes before either party left feedback. Real trades involve real conversation; this badge is a quality signal that distinguishes a real-trade review from a drive-by one. **Have real conversations with your counterparties.**
|
||
|
||
5. **Recency of last activity (dormancy signal).** Your profile shows "Last traded: N ago." A trader with great old reviews who hasn't traded in 18 months is visibly dormant. **Trade at least every few months** to keep that timestamp fresh — both for the recency-decay benefit AND for the dormancy display.
|
||
|
||
**What does NOT inflate your score** (the system actively filters these out):
|
||
|
||
- **Self-reviews.** Trying to leave feedback for yourself (subject = reviewer) is rejected at the protocol level.
|
||
- **Sock-puppet accounts created by the same person you control.** Signal A flags accounts created by the same creator with first-Morphit-activity within 5 minutes of each other. Their mutual feedback is excluded from both sides' aggregates.
|
||
- **Mutual high-star reciprocity rings.** Signal B flags pairs exchanging ≥3 high-star reviews in 7 days with no third-party reviews. Their feedback to each other is excluded from both aggregates.
|
||
- **Concentration attacks.** Signal D (added cp123) flags reviewers who concentrate ≥80% of their reviews on a single high-star target across a 30-day window. An attacker who reviews 2-3 throwaway third parties to evade Signal B still gets caught if the concentration ratio is high.
|
||
- **Untethered feedback.** Feedback without an `order_permlink` (no cited trade) does NOT count toward the aggregate weighted rating. The feedback row still exists in your profile's per-row list, but it doesn't move the headline number.
|
||
- **Coordinated 1-star pile-ons.** Signal C catches the deflation case: ≥3 reviewers leaving 1-star with clustered account creation and narrow review diversity → flagged.
|
||
|
||
**What you should DO** (concrete checklist):
|
||
|
||
1. **Complete real trades, all the way through.** Post orders, pay the listing fee, settle off-platform with your counterparty, leave honest feedback.
|
||
2. **Pay the listing fee** (Blurt is cheapest at 50% discount; BTC or XMR work too). Without a verified fee, your counterparty can't cite your order in their feedback.
|
||
3. **Reciprocate feedback.** When your counterparty leaves you a review, leave them one back. Mutual feedback is the strongest reputation signal both ways.
|
||
4. **Have real chat conversations** with your counterparties before settlement. Aim for 2+ messages each direction, over at least 15 minutes. That earns the verified-chat badge on the resulting feedback.
|
||
5. **Write detailed comments** in your feedback. "Smooth trade, fast settlement, would trade again" is more credible to readers than empty 5-star reviews.
|
||
6. **Trade on both sides.** Don't only buy or only sell — alternate to build a balanced reputation.
|
||
7. **Trade with diverse counterparties.** Reviewers who concentrate on one subject get filtered (Signal D). The same applies in reverse: build relationships with many traders.
|
||
8. **Stay active.** A trader who posts orders monthly preserves their decay-weighted score and dormancy signal far better than one who disappears for 2 years.
|
||
|
||
**What you should AVOID:**
|
||
|
||
1. **Don't create alt accounts to review yourself.** Signal A + Signal B + Signal D will catch this. Your fake reviews will be filtered out of your aggregate and your real reputation will look worse for the attempt.
|
||
2. **Don't pile-on a counterparty you had a bad trade with.** One honest 1-star is fine. Three sock-puppet 1-stars triggers Signal C and gets all of them filtered.
|
||
3. **Don't pay for fake reviews.** Reviewers who concentrate ≥80% of their activity on one subject get flagged by Signal D regardless of how the relationship started.
|
||
4. **Don't leave drive-by feedback.** A review without an `order_permlink` won't move your aggregate, and even if you cite an order, a review with no chat history won't earn the verified-chat badge.
|
||
|
||
**Verification — anyone can audit your score.** Morphit ships a **public reputation receipt** endpoint: `GET /v1/accounts/<your-account>/reputation-receipt`. Any reader can fetch the full set of feedback rows about you (included AND excluded, with the reason for each exclusion), the decay-weight at the moment of computation, and the formula used. They can independently re-derive your weighted rating from chain data. Your reputation is not "trust the indexer" — it's "verify against the chain."
|
||
|
||
**Honest caveats:**
|
||
|
||
- **First few trades are the hardest.** A brand-new account is shown with a `is_new_trader` badge in the orderbook until they have 4+ verified-fee trades. This is intentional cold-start protection for everyone trading with newcomers; it's not a permanent penalty.
|
||
- **Bad reviews recover over time but are not erased.** A 1-star from 2 years ago counts roughly 1/4 of a fresh 5-star, so honest mistakes from your past don't anchor your score forever — but they don't disappear either.
|
||
- **The system does NOT detect "trade actually happened."** Settlement is off-chain, so neither Morphit nor anyone else can verify that you and your counterparty actually exchanged value. Reputation is built on the **pattern** of consistent verified-fee orders + mutual feedback over time, not on any individual claim. This is documented honestly and is fundamental to all peer-to-peer reputation systems.
|
||
|
||
**How the 0–5 score itself is built.** The reputation score on your order cards is a composite. It starts from your time-decayed average rating, shrinks a thin history toward a neutral 3.0 (so newcomers earn trust rather than inheriting it), then adds a small bonus for a long, recent, above-average track record. Experience and recency can lift a good trader toward a full 5.0 but can never rescue a poor rating — it's good behaviour that's rewarded, not sheer activity. The trade count shown beside it (e.g. 852) is a separate number: how MUCH you've traded, not how well. The public reputation receipt returns this score and its factor breakdown too, so the 0–5 figure is as auditable against the chain as the raw rating.
|
||
|
||
**The shortest path to a high reputation: trade consistently, settle reliably, chat with your counterparties, leave honest feedback both ways, and let time + signal-table filtering do the rest.**
|
||
|
||
---
|
||
|
||
## How do I leave feedback after a trade?
|
||
|
||
**FAQ key:** `how_to_leave_feedback`
|
||
|
||
Go to 'My Orders' (/my/orders) and find the live order you just completed off-platform. Click 'Leave feedback' on it — there's no separate 'mark completed' step. Submitting the feedback is what closes out the trade: rate 1-5 stars, optionally add a short comment (up to 256 characters), and hit submit. Your feedback is broadcast on-chain using your posting key — no fee, no password prompt — and shows up on your counterparty's profile within a few seconds.
|
||
|
||
---
|
||
|
||
## Can I respond to a review someone left about me?
|
||
|
||
**FAQ key:** `feedback_reply`
|
||
|
||
Yes. If you're the subject of a review, you can post one public reply to it from your own profile page. The reply shows beneath the original review so anyone reading your profile sees both sides. Replies are also on-chain and permanent, so use them to add context — not to escalate. You cannot edit or delete the original review; nobody can.
|
||
|
||
---
|
||
|
||
## Who can see the reviews I've left for other traders?
|
||
|
||
**FAQ key:** `reviews_given_visibility`
|
||
|
||
Everyone. Your profile page has a 'Reviews given' section that lists every rating you've posted about other people, linking to each one. This is deliberate: if you give wildly different ratings to different counterparties, or leave a 1-star review that no one else agrees with, readers should be able to see that context. Think of it the same way as the reviews you receive — they're public reputation signals, and your review history is part of your reputation too.
|
||
|
||
---
|
||
|
||
## Why did Morphit warn me about a private key in my message?
|
||
|
||
**FAQ key:** `private_key_warning`
|
||
|
||
Morphit scans every free-text field that goes on-chain — order terms, feedback comments, replies to reviews, profile fields — for things that look like private keys. That includes WIF-format keys (like your posting or active key), 64-character hex strings (Monero private keys), and 12-24 word BIP-39 seed phrases. Anything matching those patterns triggers a bright red warning. Private keys are the password to your wallet; sending one to anyone — support, 'an admin', a trade partner — gives them full access to your funds forever. If you ignore the warning and send anyway, Morphit will truncate the key (keeping only the first 6 and last 4 characters) before it leaves your device, so the full secret never reaches anyone else.
|
||
|
||
---
|
||
|
||
## What does the 'New trader' label mean?
|
||
|
||
**FAQ key:** `new_trader_badge`
|
||
|
||
It means this account hasn't received any feedback yet. They might be a brand-new user, or someone who's been around but hasn't completed a trade on Morphit. It's not a red flag by itself — everyone starts here. If you want to trade with a new trader, a reasonable first step is a small trade to test the waters. After you complete it, leaving honest feedback helps the next person decide.
|
||
|
||
---
|
||
|
||
## What's on a user's profile page?
|
||
|
||
**FAQ key:** `profile_pages`
|
||
|
||
A Morphit profile lives at /@username. At the top you'll see an avatar (a deterministic identicon derived from the account name — no photo upload), their display name, and shortcut links to any Nostr or Blurt.media presence they've declared. Below that: a reputation summary with weighted rating and a 1-5 star histogram so you can see how reviews are distributed. Then a list of their live orders, sorted with the ones closest to expiring first. Then the reviews they've received (with any replies the subject has posted), followed by the reviews they've left for other traders. Everything is public — anyone can read any profile without signing in.
|
||
|
||
---
|
||
|
||
## What changes when I'm viewing my own profile vs someone else's?
|
||
|
||
**FAQ key:** `profile_own_vs_others`
|
||
|
||
When you're viewing your own profile, you'll see a 'Reply' button under each review you've received that doesn't have a response yet — that's how you post your one public reply per review. When you're viewing someone else's profile, the reply button doesn't appear. Similarly, on an individual order detail page (/@username/order-permlink), if it's your own order you'll see Edit and Cancel buttons; if it's someone else's order, you see a 'Chat with the poster' hint instead. The logic is consistent: actions are only surfaced where they make sense for the viewer.
|
||
|
||
---
|
||
|
||
## Can I share a link to my order?
|
||
|
||
**FAQ key:** `share_order_link`
|
||
|
||
Yes. Every order has a shareable URL in the form /@username/order-permlink. This is the same page anyone visiting Morphit can use to read your full offer — terms, payment methods, location, your reputation — and it works without signing in. You can post the link on Nostr, paste it into a chat, share it in a forum. The page is public by design; ordering decisions benefit from being link-shareable the same way any marketplace listing is. The permlink itself is stable for the life of the order, so the link keeps working until the order is canceled, filled, or expires.
|
||
|
||
---
|
||
|
||
## Does Morphit chat have forward secrecy?
|
||
|
||
**FAQ key:** `forward_secrecy`
|
||
|
||
Short answer: partial — and we made that tradeoff deliberately, for reasons we think are good ones for this use case. Here's the honest version.
|
||
|
||
**What we have.** Every outgoing message generates a fresh sender-side ephemeral keypair for the ECDH key agreement. The ephemeral private key is used once, then wiped from memory. So if your *posting* key is later compromised, the attacker still can't go back and read messages YOU SENT in the past — those ephemerals are gone.
|
||
|
||
**What we don't have.** Per-message rotation of the receiver's long-term key. Your long-term chat identity key (deterministically derived from your Blurt posting key) is the same forever, until you change your posting key for some reason. So if your chat-priv ever leaks (ie: gets stolen), the attacker CAN decrypt every past message they have a ciphertext for. Protocols that rotate per message protect against this; we don't.
|
||
|
||
**Why we chose this design.** Five reasons we're proud of:
|
||
|
||
1. **Stateless decryption.** A Morphit recipient can decrypt any individual message without prior state from earlier ones. This is essential for chain-anchored chat: messages may arrive out of order, after long gaps, on a brand-new device, or for a conversation you haven't touched in a year. A per-message-rotation protocol would need synchronized per-conversation state that Blurt simply doesn't provide. We took the property the use case actually needs.
|
||
|
||
2. **No "first message" bootstrap.** Sender can encrypt to anyone whose chat identity is on chain — instantly. No prekey-bundle dance, no out-of-band exchange, no "X is using Signal" detection step. You see a trader's account, you can DM them.
|
||
|
||
3. **Multi-device by default.** Your phone and your laptop, both unlocked from the same 12-word seed, are the same chat identity. There is no device-pairing UI to fail and no "this device is missing recent messages" trap to fall into.
|
||
|
||
4. **Auditable simplicity.** The entire crypto module is roughly 200 lines of libsodium calls. A more complex protocol would be closer to 1500 lines and notoriously easy to get wrong (the Matrix folks have written about how many subtle bugs they hit shipping forward-secrecy protocols). Less code, fewer places to hide a bug, easier for any third-party security researcher to read end-to-end.
|
||
|
||
5. **The threat model where per-message rotation helps doesn't really apply here.** Per-message rotation protects against "silent compromise" — an attacker who steals your key without you noticing and uses it to decrypt your archive while you keep using the app. On Morphit, your chat identity comes from your Blurt posting key. If someone has that key, they can already broadcast as you, edit your identity record on chain, leave fake feedback in your name, and impersonate you to your existing contacts going forward. Adding per-message rotation would protect a small slice of past messages while leaving the rest of your account fully exploitable. We'd rather you rotate keys promptly when something is wrong than build a fortress around one window of one room.
|
||
|
||
**The PFS we DO have is one-sided** — sender's outbound messages stay safe even if their posting key leaks later (because the ephemerals are wiped). For two-sided PFS, both parties would need to rotate posting keys after each conversation. Blurt allows that, but we don't expect normal users to do it.
|
||
|
||
**When this tradeoff is wrong for you.** If you're coordinating activism that may be investigated years from now, or corresponding with someone under active state-level surveillance, or exchanging information that stays sensitive long-term, please use a dedicated secure messenger. Some good options: **Matrix/Element**, **Session**, **Signal**. Morphit chat is usually just for coordinating a trade — conversations about payment details and getting to know your trading buddy a little bit.
|
||
|
||
---
|
||
|
||
## If I disagree with my counterparty later, can I prove what we agreed to in chat?
|
||
|
||
**FAQ key:** `chat_dispute_recourse`
|
||
|
||
Yes — because Morphit chat lives on the blockchain, both of you hold a permanent cryptographic record of every message sent. The ciphertext is immutable once confirmed; nobody can edit or quietly delete what was said.
|
||
|
||
**What this gives you:**
|
||
|
||
• **A verifiable trail.** Every message has a block number, a timestamp, and a signature from the sender's posting key. There's no "he said / she said" about whether a specific message was sent at a specific time.
|
||
|
||
• **Decryption on demand.** Both you and your counterparty can decrypt the full conversation at any time — the keys don't expire. If you later need to show a mediator, trusted friend, accountant, or even a small-claims court what was agreed, you can export plaintext from your side.
|
||
|
||
• **No operator gatekeeping.** Because the chat is on-chain rather than on a Morphit server, no operator or admin can selectively reveal or hide parts of the record. What's there is there for everyone with a decryption key.
|
||
|
||
**What this does NOT give you:**
|
||
|
||
• **No automatic arbitration.** Morphit has no customer service, no dispute-resolution team, and no escrow. Having the evidence doesn't force the other side to honor it. See 'Why no Escrow or Arbitration service?' for why that's deliberate.
|
||
|
||
• **No forced disclosure.** Your counterparty cannot be compelled to decrypt their side of the conversation. The record is symmetric — if they refuse to cooperate, you still have your copy, but you can't unlock theirs.
|
||
|
||
• **No binding precedent.** A chat log is evidence, not a contract. Whether a court or mediator weighs it depends on their jurisdiction and the nature of the dispute.
|
||
|
||
**Practical advice.** For any trade large enough that a dispute would matter, use chat for the whole negotiation: confirm the asset, amount, payment method, and any special terms in writing before anyone transfers anything. Short messages that pin down the exact terms are more useful later than long casual back-and-forth.
|
||
|
||
If you want your record to be legible to people outside Morphit, you can paste decrypted message excerpts (with timestamps and block numbers) into an email or document — the block number is the anchor anyone else can independently verify against the blockchain.
|
||
|
||
**One-tap court-ready export.** You don't have to copy-paste any of this by hand. Open the conversation's ⋯ menu and choose "Export chat": Morphit builds a locked PDF (view / print / copy only, no editing) with every message, its UTC timestamp, and its on-chain transaction ID as a re-verifiable "Blockchain proof" — plus a plain-language page that walks a mediator or a small-claims court through checking each line against the public chain. It can't force a dishonest counterparty to do the right thing, but it replaces "he said / she said" with a record built to hold up outside Morphit.
|
||
|
||
---
|
||
|
||
## What's public and what's private about my trades on Morphit?
|
||
|
||
**FAQ key:** `chat_vs_feedback_visibility`
|
||
|
||
Morphit splits your trading footprint into two very different layers, on purpose.
|
||
|
||
**Private (encrypted, only you two can read):**
|
||
|
||
• **Chat messages.** The actual content of what you discuss — prices, payment details, negotiation, personal context — is end-to-end encrypted between your device and your counterparty's. Morphit operators, indexers, and chain observers see only opaque ciphertext. See 'Are my chats private?' for the crypto details.
|
||
|
||
• **Payment details you exchange.** Bank account numbers, crypto addresses, meetup locations, phone numbers — anything you type into chat inherits chat's E2EE protection.
|
||
|
||
**Public (plaintext, anyone can read):**
|
||
|
||
• **Your orders and their prices.** Your live orderbook entries are posts on the blockchain anyone can read without even running Morphit. That's how the worldwide-accessible orderbook works.
|
||
|
||
• **Feedback and reputation.** Star ratings, review comments, and replies to reviews are **plaintext on chain** and visible to everyone. This is deliberate — reputation only works as a public signal. See 'Can feedback be edited or deleted?' and 'Who can see the reviews I've left for other traders?'.
|
||
|
||
• **Chat metadata.** Who (@scooby) chatted with whom (@dingleberry), when, and roughly how big the messages were. The content of the messages though is totally encrypted; the fact of communication isn't.
|
||
|
||
Everything above — private chat ciphertext, public feedback, public orders — lives on the blockchain and cannot be edited, deleted, or retroactively censored. The difference is who can read the plaintext, not whether it exists.
|
||
|
||
**Why the asymmetry makes sense.**
|
||
|
||
Chat needs privacy so that discussing a specific trade doesn't leak payment details to the world. Feedback needs publicity so that reputation is auditable — a review nobody could read would be worthless as a trust signal. Permanence serves both: permanent chat gives you dispute recourse (see 'If I disagree with my counterparty later, can I prove what we agreed to in chat?'); permanent feedback means bad actors can't quietly erase a history of complaints.
|
||
|
||
If you want even the metadata of your communication hidden, use a dedicated secure messenger out-of-band for anything sensitive beyond the trade itself.
|
||
|
||
---
|
||
|
||
## How does Morphit protect me from scammers and stop them from getting my private keys or personal info?
|
||
|
||
**FAQ key:** `how_morphit_protects_me`
|
||
|
||
Morphit's defense is layered, and most of it is structural rather than reactive. Here's the stack:
|
||
|
||
**Architecture that has nothing to steal.** Morphit is non-custodial and KYC-free. Your private keys never leave your device — there's no key database for an attacker to crack. There's no email, no phone number, no government ID, no IP log — there's no personal-info database to leak. Even if every Morphit server were compromised tomorrow, the attacker would walk away with nothing about you.
|
||
|
||
**Outgoing-message private-key scanner.** When you type into any free-text field that touches the chain — order terms, feedback comments, profile bio, chat messages — Morphit watches for patterns that look like private keys: WIF-format Blurt keys, 64-character hex Monero keys, 12-24 word BIP-39 seed phrases. If you accidentally paste one (or a scammer convinces you to), a bright red warning fires before send. If you press send anyway, Morphit truncates the key on your device (keeps only the first 6 and last 4 characters) so the full secret never leaves the browser. See 'Why did Morphit warn me about a private key in my message?' below for details.
|
||
|
||
**Stranger-message gates.** Anyone who tries to message you for the first time has to either pay a small Blurt fee per recipient, or wait for you to message them first. That kills cold-DM phishing as a viable tactic — see 'How does Morphit stop spam and unsolicited messages from strangers?' below.
|
||
|
||
**Block + hide.** Any user who's harassing you can be blocked (an on-chain action that the indexer enforces — they can't reach you again from any account they control without paying the gate fee), or hidden locally if you don't want to make a public block. See 'How does the chat inbox work? Can I mute or unmute someone?' for the full UX.
|
||
|
||
**Reputation that scams can't fake cheaply.** Every review costs the reviewer a small fee, and the fee escalates if they post a flurry. The indexer flags self-trade patterns and zeros out the reviews. New accounts offering suspicious deals are flagged with a 'new trader' badge until they have real history. See 'How does Morphit stop fake reviews?'.
|
||
|
||
**Standard-web-attack hardening.** No PHP, no WordPress, no OAuth, no eval, schema-validated request bodies, exact-origin CORS, strict CSP. Entire vulnerability classes that plague typical platforms simply don't apply. See 'Is Morphit vulnerable to hacking, data theft, or takedowns?' below for the full inventory.
|
||
|
||
The only attack class Morphit can't fix for you is **social engineering you, the trader** — a scammer convincing you to pay for a service that doesn't exist, send to the wrong address, or accept a reversible payment. For those, see 'What scams should I watch out for on Morphit?' below.
|
||
|
||
---
|
||
|
||
## How does Morphit stop spam and unsolicited messages from strangers?
|
||
|
||
**FAQ key:** `chat_anti_spam`
|
||
|
||
Three layers, designed so that small-scale legitimate first contact stays cheap while mass spam becomes expensive fast.
|
||
|
||
**Layer 1 — Block list.** You can block any account on-chain. The indexer enforces it: blocked sender's messages to you simply don't land, no notification, no UI surface. They can't bypass by switching accounts unless they're willing to pay the layer-2 stranger fee from each new account, and even then you'll see the new account in your Inbox and can block it too.
|
||
|
||
**Layer 2 — Stranger fee per recipient (with rapid-send escalation).** A first message from someone you've never exchanged with requires either a paid stranger-fee transaction (about $0.01 in Blurt, equivalent at the time of payment) sent to the operator's fees account, OR a prior message from you to them. Once any message has flowed in either direction between the two of you, the pair is unrestricted forever — replies don't cost anything.
|
||
|
||
**The fee doubles for every additional first-contact message a sender makes within a 5-minute window.** First message: $0.01. Second within 5 min: $0.02. Third: $0.04. Then $0.08, $0.16, $0.32, $0.64, $1.28 — and the price caps at $1.28 (128× the base) for every additional send while they keep going fast. Pause for 5 quiet minutes and the price resets to $0.01. The cap exists to protect legitimate large-volume traders (and to prevent a malicious user from triggering a multi-thousand-dollar charge against themselves to embarrass Morphit).
|
||
|
||
Here's the cost-multiplication this produces. Spam-economics depend on volume being free; both the per-recipient fee AND the per-window doubling tax volume.
|
||
|
||
- Pacing one message every 6 minutes: $0.01 per recipient, forever. The escalation never engages.
|
||
- Sending 8 messages in a 5-minute burst: $0.01 + $0.02 + $0.04 + $0.08 + $0.16 + $0.32 + $0.64 + $1.28 = $2.55. ~255× the per-recipient base.
|
||
- Sending 100 messages in a 5-minute burst: $2.55 for the first 8, then $1.28 each for messages 9-100 = $120.31.
|
||
- Sending 1,000 messages in a fast continuous burst: ~$1,272.55. Paid in advance.
|
||
|
||
Spammers also get an in-app warning the moment the multiplier exceeds 1×, telling them to slow down because recipients dislike unsolicited contact and may block them — and blocks are visible on-chain, so multiple blocks against an account hurt that account's reputation as a counterparty.
|
||
|
||
Why $0.01 base specifically: it's small enough that legitimate first contact (a serious buyer reaching a seller they've found in the orderbook) shrugs it off, but large enough that broadcasting to a list isn't free. The base fee, the doubling rule, the 5-minute window, and the 128× cap are all hardcoded in the indexer — operators can't tune them to undercut the spam economics across the ecosystem.
|
||
|
||
**Layer 3 — Rate limits on never-replied conversations.** Even if a sender pays the (escalating) stranger fee, they're capped at 20 unique never-replied recipients per rolling 24 hours and 50 messages per recipient pair before you reply. The moment you reply to them, both caps lift forever for that pair. So a serious counterparty stays unrestricted as soon as you engage; a flooder gets cut off after their first burst, and has to wait or pay again from a fresh account.
|
||
|
||
The combined effect: legitimate trade chat is essentially free and unrestricted; broadcast spam is priced into oblivion; harassment is one click away from being shut down via Layer 1. See 'How does the chat inbox work? Can I mute or unmute someone?' below for what the inbox and block button actually look like.
|
||
|
||
---
|
||
|
||
## How does the chat inbox work? Can I mute or unmute someone?
|
||
|
||
**FAQ key:** `chat_inbox_features`
|
||
|
||
The chat inbox lives at the chat icon in the header and works like an email inbox: **one card per discussion**, not one per person.
|
||
|
||
If you and the same trader have talked about three different orders, that is three cards, each with a "RE:" line naming the order and its current state — **(Live)**, **(Canceled)**, **(Expired)** or **(Paid)** — so a thread about a dead order says so before you open it. A discussion that isn't about an order still gets its own card; its second line simply reads "RE: -". Open a card and you see only that discussion. Newest activity is always on top.
|
||
|
||
Reading one card marks **only that one** read — three unread conversations with the same person stay three unread conversations, on this device and every other one you sign in from. Unread cards keep an emerald border, and the chat icon (plus the browser tab and favicon) carries the unread count. Reading a card, or clicking **Mark all as read**, clears it.
|
||
|
||
The inbox has three tabs, exactly like an email client:
|
||
|
||
**Inbox** — where everything lands by default and stays until you move it. New conversations, replies, and first contact from someone you've never met all show up here.
|
||
|
||
**★ Starred** — tap the empty star to the right of a card's time and the discussion moves here; tap the gold star to send it back to the Inbox. The same star sits in the conversation's ⋮ menu, so you can flag a thread from inside the chatroom too.
|
||
|
||
**Archived** — done with a discussion but don't want to block anyone? Tap **Archive** on the right of the card. It moves to Archived, stops counting toward your unread badge, and its button becomes **Restore** to bring it back to the Inbox. Archiving is per-discussion, local to your browser, never on-chain, and never visible to the other party.
|
||
|
||
**Mute / unmute (block + unblock).** Inside any conversation, the header's ⋮ menu has a Block button. It asks for confirmation, then broadcasts an on-chain block op — that account can no longer reach you from any handle, enforced server-side by the indexer no matter which Morphit instance they use. To unmute, go to **Settings → Blocked accounts** and click Unblock; that's an on-chain op too, effective immediately.
|
||
|
||
**Block vs Archive vs Hide:** Block is on-chain and protocol-level (cross-instance, cross-account-history). Archive is your own inbox curation — local-only and per-discussion. Hide (the orderbook button — see 'Can I hide orders from specific users?' below) is the same local-hide idea extended to orderbook rows.
|
||
|
||
Desktop and mobile both get optional push notifications for new messages — see 'How do push notifications work with my privacy?' for the privacy footprint. Turn them off any time from Settings.
|
||
|
||
---
|
||
|
||
## How does Morphit let me know when something happens — a new message, an order filling, feedback arriving?
|
||
|
||
**FAQ key:** `notifications_overview`
|
||
|
||
Morphit has a built-in notifications system designed to keep you informed without being annoying. It works in layers — quiet ambient signals first, with louder OS-level pings as opt-ins on top — and ties to a chat inbox where conversations live.
|
||
|
||
**The inbox.** Click the chat icon in the header. It works like email, with three tabs:
|
||
• **Inbox** — every discussion by default, newest first. New conversations and first contact from strangers who paid the anti-spam fee all land here.
|
||
• **★ Starred** — the discussions you've flagged with the gold star, one tap away.
|
||
• **Archived** — discussions you've filed away; they stop counting toward your unread badge until you restore them.
|
||
|
||
The unread count surfaces on the Inbox tab and on the chat icon. See "How does the chat inbox work? Can I mute or unmute someone?" for starring, archiving, muting, and blocking.
|
||
|
||
**Ambient channels (always on, no permission needed).** Three quiet signals update in your peripheral vision whenever something happens:
|
||
• The browser tab title is prefixed with the unread count — for example, "(3) Morphit — Orderbook".
|
||
• The favicon gets a small colored dot with a count painted over it.
|
||
• If you've installed Morphit as a PWA, the operating system badges the app icon (works on desktops and supported mobile OSes).
|
||
|
||
These never interrupt you; they're just there if you glance over.
|
||
|
||
**Interactive channels (you opt in at Settings → Notifications).**
|
||
• **OS notifications** — browser-level pings via the Notification API. Morphit asks for permission the first time it would actually fire one, not on page-load (this has roughly 3× the grant rate vs. nagging up-front).
|
||
• **Audio cue** — a short two-tone chime synthesized in the browser. No audio file ships. Default off.
|
||
• **Vibration cue** — a short two-buzz pattern on mobile devices that support `navigator.vibrate`. Default off.
|
||
|
||
**Categories.** Each channel can be enabled per event type, so you can be loud about orders but silent about chat noise:
|
||
• **Order events** (your offer filled, payment marked, funds confirmed) — default on. Highest signal.
|
||
• **Feedback events** (someone left you a rating) — default on.
|
||
• **Chat events** (new chat message) — default off. Chat is high-volume; turn it on per-channel if you want every message to ping.
|
||
|
||
**Tab-closed delivery (Web Push) — available now.** The channels above work while the Morphit tab is open. To be notified when the tab is closed or your phone is locked, turn on Web Push. You can choose between your operator's self-hosted push server (most private), a standard browser push provider (broadest reach), or off.
|
||
|
||
The principle behind all of this: **use every reasonable channel — visual, audible, native OS — without being annoying.** Defaults are quiet; you opt in to anything louder.
|
||
|
||
---
|
||
|
||
## What does "We couldn't safely send" mean?
|
||
|
||
**FAQ key:** `chat_key_changed`
|
||
|
||
When you message someone for the first time, Morphit fetches their chat key from your indexer and remembers it locally. On every later message to that person, Morphit checks the indexer's answer against what it remembered. If something looks off, the message is held back and you see "We couldn't safely send."
|
||
|
||
This is a safeguard against a compromised indexer trying to feed you the wrong chat key — which would let an attacker read your outgoing messages.
|
||
|
||
**Four cases trigger the safeguard:**
|
||
|
||
• **Tampered record.** The indexer points at the same on-chain transaction it pointed at before, but the chat key inside is different. The indexer changed stored data behind the scenes — only an indexer with bad intent or a database problem produces this state. Try a different Morphit instance.
|
||
|
||
• **Older record than expected.** The indexer is reporting a chat-key publication older than one you've already seen. The blockchain only moves forward, so this shouldn't happen on a healthy indexer. Refresh, or try a different Morphit instance.
|
||
|
||
• **Indexer claims a chat key, the chain doesn't.** The indexer says your peer has published a chat identity, but Blurt itself reports nothing. The indexer is either out of sync or fabricating. Wait a moment and retry, or switch instance.
|
||
|
||
• **Chain reports something older than what you've seen.** The blockchain says the latest chat-identity for this person is older than what you previously saw. That's internally inconsistent. Try another Morphit instance, or another blockchain endpoint.
|
||
|
||
**What to do:**
|
||
|
||
1. **Try retrying once.** Transient indexer hiccups can produce a false alarm.
|
||
|
||
2. **Switch Morphit instance.** Just pick a different one from the instances link at the bottom of this page. Different instances run different indexers; if yours is misbehaving, another is fine.
|
||
|
||
3. **Confirm with the recipient out-of-band.** If they recently rotated their Blurt posting key (rare — that's an Owner-key operation), the legitimate new chat key will eventually settle. Asking them directly is the safest way to know.
|
||
|
||
**What this DOESN'T mean:**
|
||
|
||
• Your messages are not at risk in the past. Messages already sent stay encrypted with the keys that were in use at the time.
|
||
• Your peer is not necessarily compromised. The most common cause is a misbehaving indexer, not your peer.
|
||
• Your account is fine. None of these errors involve your own keys.
|
||
|
||
The whole point of the check is to refuse to encrypt to the wrong key. Better a held-back message than a leaked one.
|
||
|
||
See also 'How does Morphit chat work?' and 'Are my chats private?' for the encryption design this safeguard sits on top of.
|
||
|
||
---
|
||
|
||
## My order isn't showing up. What does the fee status mean?
|
||
|
||
**FAQ key:** `order_fee_rejected`
|
||
|
||
When you post an order, Morphit needs to confirm your network fee was paid before showing it on the public orderbook. Your "My orders" page shows the fee status next to each order. Five things you might see:
|
||
|
||
**Verified.** Your fee landed and matched what was expected. The order is on the orderbook. Nothing else to do.
|
||
|
||
**Verified (attested).** You paid in BTC or XMR, and at least two community members vouched for the payment after the indexer couldn't reach a block explorer in time. Same outcome — your order is live.
|
||
|
||
**Awaiting attestation.** You paid in BTC or XMR, but the block explorers were unreachable when the indexer first looked. The order is on hold until two attestors confirm the payment, or until the order expires. This usually resolves itself within minutes; if it lingers, your transaction may not have confirmed on the BTC/XMR chain yet.
|
||
|
||
**Fee didn't arrive / fee too low.** The indexer didn't see a fee transfer at all (didn't arrive), or the transfer was below the expected amount (too low). Possible reasons:
|
||
- The fee transfer didn't broadcast successfully (network glitch, wrong recipient).
|
||
- For Blurt fees: the amount sent was below the expected baseline, or below the current Sybil-tier amount if you've been posting a lot recently.
|
||
- For BTC/XMR fees: the amount in satoshis or piconero was below what the operator currently configures.
|
||
- The transaction memo didn't bind the fee to this specific order — every fee includes a memo like `morphit-fee:<order-permlink>` that ties it to one listing.
|
||
|
||
**Reused.** The transaction ID you submitted was already used to verify a different order. Each external (BTC/XMR) payment can only fund one listing — submitting the same txid twice rejects the second attempt.
|
||
|
||
If you see a non-verified status that doesn't resolve itself, the simplest fix is usually to cancel the order and post a fresh one. Network fees are small enough that the cost of retrying isn't significant.
|
||
|
||
---
|
||
|
||
## Signup isn't working. What do these errors mean?
|
||
|
||
**FAQ key:** `signup_stuck`
|
||
|
||
Signup goes through a relay that creates your account on Blurt (paying the account-creation fee), so it has to push back on abuse. Most errors you might see are temporary and resolve on their own; a few need you to wait or pick a different relay. The most common cases:
|
||
|
||
**"Verifying you're not a name-squatting bot" stuck.** The relay is asking your browser to solve a small proof-of-work puzzle (Altcha). It usually takes 1-2 seconds. If it hangs much longer, your browser may have throttled the background work — try closing other tabs or switching to a different browser. Refreshing the page restarts the puzzle with a fresh challenge.
|
||
|
||
**"Too many requests from this client" / "rate-limited."** This relay caps signups per IP address per hour. If you're sharing a network (school, office, public WiFi) with others who recently signed up, you'll hit the cap even though you personally haven't signed up. Wait an hour, or try from a different network.
|
||
|
||
**"Daily signup limit reached on this relay."** Each relay sets a daily signup ceiling to bound how many accounts it will fund per day. The cap resets at UTC midnight. You can wait it out, or — if you're impatient — try a different Morphit instance (linked at the bottom of this page).
|
||
|
||
**"You recently created an account. Wait N minutes."** A spacing rule: even within the daily cap, the relay enforces a minimum gap between signups from the same IP address. This catches scripted attempts. If you're a real human signing up your second device, just wait.
|
||
|
||
**"Signup token was issued to a different connection" (invite_ip_mismatch).** Your network address changed between when the relay issued you a signup token and when you submitted the signup. Common on mobile when you switch between WiFi and cellular, or when your home connection's address rotates. Refresh and try again from a stable connection.
|
||
|
||
**"Signup is currently unavailable on this relay."** The operator has paused signups, usually because they're investigating a potential abuse spike or topping up the relay's Blurt balance. You can wait, or just switch to a different instance (linked at the bottom of this page).
|
||
|
||
**"The relay is temporarily unable to fund new accounts."** The relay's Blurt balance is too low to pay the account-creation fee. The operator tops it up; the operator gets an alert when the balance runs low, so usually it's resolved within hours. Switching instances also works.
|
||
|
||
**"The chain rejected the transaction" / "broadcast_failed."** Generic fallback for chain errors that don't fit the patterns above. Usually transient — try again. If it persists, your chosen account name may have been claimed by someone else in the moment between the relay checking availability and broadcasting; pick a different name.
|
||
|
||
**"Account already taken in the last moment."** Two people happened to ask for the same name at the same time and the chain accepted the other one. Pick a slightly different name.
|
||
|
||
**Account name validation errors.** The relay enforces Blurt's account-name rules: 3-16 characters, lowercase ASCII letters / digits / dashes only, must start with a letter, no consecutive dashes, no dots, no leading or trailing dash. The reason code (e.g. "must_start_with_letter") tells you which rule fired.
|
||
|
||
**"This name is reserved."** The relay refuses to register names that impersonate the project (morphit, morphit-bot, etc.) or close-typo variants of those names. Pick something distinctive.
|
||
|
||
**What to do if you're truly stuck:**
|
||
|
||
1. Wait an hour and try again — most rate-limits are short-lived.
|
||
2. Try a different network if the issue is IP-based (rate_limited, invite_ip_mismatch).
|
||
3. Try a different Morphit instance — operators run their own relays and might not share rate-limit state.
|
||
4. If you're seeing repeated chain errors with no obvious cause, the Blurt network itself may be having a moment. Check the block explorer or wait it out.
|
||
|
||
See also 'What do I need to sign up?' for the requirements check, and 'What is the welcome bonus?' for the next step after registering.
|
||
|
||
---
|
||
|
||
## What is the "Verified chat" badge on a review?
|
||
|
||
**FAQ key:** `verified_chat_badge`
|
||
|
||
A small green checkmark badge that appears on a feedback row when the reviewer and the trader had a real-looking on-chain conversation BEFORE the review was signed.
|
||
|
||
**What "real-looking" means:**
|
||
- At least 2 chat messages from each side (so the conversation was bidirectional, not one-sided flooding).
|
||
- At least 15 minutes elapsed between the first and last message (so it wasn't a 30-second sock-puppet exchange).
|
||
- The (reviewer, trader) pair isn't flagged in our suspicious-reciprocity detector.
|
||
|
||
**What the badge claims:** these accounts had a conversation that looks like real trade coordination.
|
||
|
||
**What the badge does NOT claim:** that these are two distinct people. A patient attacker with two coordinated accounts can satisfy the criteria by scheduling messages over time. The badge is a correlation signal — it's strictly more useful than nothing, but it doesn't prove distinct identity.
|
||
|
||
**Why we don't IP-check the conversation:** Morphit's privacy commitment forbids IP collection. Even if we did collect IPs, sophisticated attackers route through Tor/VPN and would defeat it; honest users on shared wifi or VPN would trip false positives. We pay the privacy cost without catching real adversaries — not a good trade.
|
||
|
||
**How to use the signal:** treat verified-chat as one input among several. A reviewer with verified-chat + an account 6+ months old + a history of feedback to many distinct counterparties is a much stronger signal than verified-chat alone.
|
||
|
||
---
|
||
|
||
## Why are some reviews greyed out as 'not counted toward rating'?
|
||
|
||
**FAQ key:** `feedback_suppressed`
|
||
|
||
Morphit runs four pattern detectors on the public feedback table to spot reviews that look like sock-puppet manipulation rather than genuine trading. When a (reviewer, subject) pair triggers any of them, those reviews are excluded from the headline rating + review count. They still appear in the reviews list — transparency matters — but marked "Not counted toward the rating" and at reduced opacity.
|
||
|
||
**The four patterns we flag:**
|
||
|
||
1. **Same-creator close-timing (Signal A).** Two accounts created by the same Blurt creator (other than @morphit-relay, which onboards most legitimate users) whose first Morphit activities are within 5 minutes of each other — the typical sock-puppet farm setup.
|
||
|
||
2. **Mutual high-star with no third party (Signal B).** Two accounts exchanging 3+ five-star reviews of each other in 7 days with no third-party reviews in that window — a wash-trading pattern. Real heavy traders almost always have third-party reviews mixed in.
|
||
|
||
3. **One-way pile-on (Signal C).** A cluster of reviewers concentrating on a single subject.
|
||
|
||
4. **Review concentration (Signal D).** A reviewer whose reviews overwhelmingly target one counterparty rather than being spread across their trading.
|
||
|
||
**Also excluded:** a review not linked to a specific order. It cannot be checked against a real trade, so counting it would let anyone inflate a reputation with reviews tied to nothing.
|
||
|
||
**Why we flag rather than hide:** the reviews stay visible because the chain itself is public — anyone running their own indexer can see them. Hiding them here would be cosmetic only, and dishonest about what the reputation system is doing. The chip plus reduced opacity convey "this exists but does not count" while preserving transparency.
|
||
|
||
**Why the headline excludes them:** the rating + count at the top of a profile is the at-a-glance trust signal traders use to decide whether to engage. Including suppressed reviews there would defeat the point of detecting them. The list is for due diligence; the headline is for snap judgments.
|
||
|
||
**False positives:** the detectors are not perfect. If you believe you have been wrongly flagged, the operator of the instance you are looking at can clear any of the four signals for a pair — contact them, or open a thread on the project discussion forum.
|
||
|
||
See also "How does Morphit reputation system work?" for the bigger picture.
|
||
|
||
---
|
||
|
||
## If I block someone, will they know?
|
||
|
||
**FAQ key:** `block_privacy`
|
||
|
||
**Morphit does not show blocked users that they have been blocked.** This is a deliberate anti-harassment design choice, not a privacy guarantee.
|
||
|
||
When you block someone, what happens:
|
||
|
||
- The block decision is broadcast on the blockchain as a `morphit_block_v1` op. This is technically public — anyone scraping the chain can see "@you blocked @them on date X."
|
||
- Morphit's interface deliberately does not surface "you have been blocked by @x" anywhere. The blocked user can still try to send messages to you, but those messages do not land on your end and they get no error indication telling them they have been blocked specifically. From their side, it just looks like delivery failed.
|
||
- This is the standard anti-harassment posture used by most social platforms. Telling a stalker exactly which account is blocking them helps them figure out how to evade the block. Telling nobody preserves the victim's safety.
|
||
|
||
What this means in practice:
|
||
|
||
- If you block someone and they retry sending, their message is silently rejected. They do not get a popup saying "you are blocked." They might assume the indexer is having trouble or they typed the wrong account.
|
||
- If they try to message you from a different account, that new account hits the layer-2 stranger-fee gate ($0.01 minimum, escalating if they keep trying fast) AND the layer-3 fan-in cap (maximum 20 new strangers per 24h on your inbox). So even creating new accounts to evade your block costs them real money and is bounded.
|
||
- A determined stalker who scrapes the blockchain directly can find your block decision. There is no realistic way to hide this — the chain is public. But Morphit's UI does not make it convenient for them.
|
||
|
||
If you change your mind, you can unblock someone via Settings → Blocked Accounts. Unblocking is also broadcast on-chain (so other Morphit instances see the change), but it does not retroactively deliver messages they tried to send while blocked.
|
||
|
||
See also "How does Morphit stop spam and unsolicited messages from strangers?" for the broader anti-spam design.
|
||
|
||
---
|
||
|
||
## What is Mana on Blurt?
|
||
|
||
**FAQ key:** `what_is_mana`
|
||
|
||
On Blurt, Mana is your voting power — it sets how much weight your upvotes carry, and that is the only thing it affects. Picture a stamina bar that starts at 100%, drops a little each time you vote, and refills by roughly 20% a day. The more Blurt Power (staked Blurt) you hold, the bigger the bar.
|
||
|
||
What Mana does NOT do is pay for your actions. This is the key difference from Steem and Hive, which meter posting and transacting with "Resource Credits (RC)". Blurt dropped that model. On Blurt, on-chain actions — posting, commenting, transferring, and on Morphit submitting orders, leaving feedback, and sending chat messages — cost a small fee paid from your liquid BLURT (an operation flat fee plus a size-based bandwidth fee, set by the witnesses; you see the exact amount just before you sign). Voting is the one exception: it spends Mana, not BLURT.
|
||
|
||
So the practical rule is simple: keep a little liquid BLURT on hand — even about 10 is plenty for everyday use — and your actions go through. Incoming transfers are free, so topping up is easy. You never have to wait for Mana to recharge before you can post or trade; that is a Steem/Hive habit that does not apply on Blurt.
|
||
|
||
---
|
||
|
||
## What are the minimum hardware requirements to run a Morphit node?
|
||
|
||
**FAQ key:** `node_minimum_requirements`
|
||
|
||
Surprisingly modest. Morphit is built to run on hardware most people already own. Three categories of setups people are using:
|
||
|
||
**Hobbyist tier — Raspberry Pi 4 / 5 (4 GB).** Runs the indexer, relay, and frontend together comfortably. Use a USB-3 SSD instead of an SD card; SD cards die under database write load. Power draw is around 5–7 W, so a small UPS or solar setup handles it for hours. Suitable for serving a personal community of a few dozen active users.
|
||
|
||
**Serious tier — small mini-PC (Beelink, Intel NUC, generic 2nd-hand).** An Intel N100 / Ryzen 3xxx with 8 GB RAM and any modern SSD is overkill for the indexer and runs every Morphit service at the same time without thinking about it. Power draw 6–10 W idle, 15–20 W under load. $150–250 used. Comfortable for an instance serving hundreds of active users.
|
||
|
||
**Spare-laptop tier — anything that still boots Linux.** An old ThinkPad or any laptop from the last decade with at least 4 GB RAM and a working SSD is plenty. Bonus: built-in UPS (the laptop battery). Some operators leave a closed laptop on a shelf running Morphit on a wired Ethernet connection — works great.
|
||
|
||
**Concrete minimums (any architecture: x86-64, ARM64, or Apple silicon under Asahi):**
|
||
|
||
• **CPU:** 2 cores at 1 GHz or faster. Indexer is mostly I/O-bound; relay is mostly idle. No GPU needed, ever.
|
||
|
||
• **RAM:** 2 GB minimum, 4 GB comfortable. Postgres fits inside that with the default config; tuning Postgres `shared_buffers` to 256 MB on a 2 GB system avoids paging.
|
||
|
||
• **Disk:** 20 GB free, on an SSD. HDDs technically work but Postgres will be slow and SD cards will die from write amplification. The indexer's database grows slowly — measured in low-MB per month for typical activity — so 20 GB lasts years. Plan for backups, though.
|
||
|
||
• **Network:** 1 Mbit/s up and down is enough. An average page load is around 100 KB. A small instance serving a few users uses a few GB of bandwidth a month, well within any home internet cap. Static IP is nice but not required — dynamic-DNS works fine.
|
||
|
||
• **Operating system:** Any modern Linux (Debian 12, Ubuntu 24.04 LTS, Arch, Alpine, NixOS — we test on Debian). FreeBSD works with minor adjustments. macOS works for development but isn't recommended for a public instance.
|
||
|
||
• **Uptime expectation:** 95% is a reasonable target. Morphit is federated by design — when your instance is down, users fall back to other operators' instances and back to you when you return. The chain holds the data; your instance is just one of many windows into it.
|
||
|
||
**What you do NOT need:**
|
||
|
||
• A blockchain node. Morphit talks to public blockchain endpoints over HTTPS.
|
||
|
||
• A static IP. The one-command setup wizard configures dynamic-DNS for you, so a home connection with a changing IP just works — no static IP, and no third-party tunnel, required. See the operator handbook for the details.
|
||
|
||
• A domain name. You can run a private instance on `https://morphit.local` for your friends, or expose a `.onion` / `.loki` / `.b32.i2p` address (or an ENS `.eth` name) only.
|
||
|
||
• A datacenter VPS. Operators running on residential connections work fine, especially with alt-network reachability so users don't need your home IP.
|
||
|
||
The operator-earnings split is sized so that even a Pi-tier instance covers its hosting cost and your time at modest activity levels. Run one because you want a Morphit that exists in your community, not because it pays well — but the math doesn't lose money.
|
||
|
||
---
|
||
|
||
## Can I use Morphit on my iPhone or iPad?
|
||
|
||
**FAQ key:** `iphone_install`
|
||
|
||
Yes — fully, no jailbreak and no App Store needed. Apple rejects apps that facilitate non-KYC peer-to-peer crypto (exactly what Morphit is), so instead of a native app we ship a Progressive Web App (PWA).
|
||
|
||
Install it in ~15 seconds:
|
||
1. Open this site in **Safari** (Chrome/Firefox on iOS don't show the install option).
|
||
2. Tap **Share** (the square with an up-arrow).
|
||
3. Tap **"Add to Home Screen."**
|
||
4. Confirm the name and tap **Add**.
|
||
|
||
The icon launches fullscreen like any app. On iOS 16.4+ it caches for offline use and supports notifications; older versions still install without those extras. No APK, IPA, TestFlight, or sideloading on any platform.
|
||
|
||
---
|
||
|
||
## Is there a block explorer for Morphit?
|
||
|
||
**FAQ key:** `block_explorer`
|
||
|
||
Yes — visit /explorer to look up any account, transaction, or block. The explorer is public and works without an account. Completed trades on Morphit are visible there with rich Morphit-aware decoration on each operation. For BTC and XMR transactions, Morphit links out to the appropriate external explorer (mempool.space for Bitcoin, xmrchain.net for Monero).
|
||
|
||
---
|
||
|
||
## Can I build a block explorer or aggregator on top of Morphit's data?
|
||
|
||
**FAQ key:** `public_api`
|
||
|
||
**Yes — this is supported, encouraged, and free.**
|
||
|
||
Every Morphit instance exposes a documented public HTTP API at `/v1/*`. Same contract on every operator's box — different hostname, identical shape. The endpoints are read-only, no authentication required, no API key, no signup. Just hit the URL.
|
||
|
||
**Documented contract.** The full reference is at `docs/API.md` in the source repo. Endpoints we promise stable shape for: `/v1/orderbook`, `/v1/orderbook/stream` (SSE), `/v1/orderbook/featured`, `/v1/orders/:account`, `/v1/accounts/:account`, `/v1/accounts/:account/feedback`, `/v1/accounts/:account/feedback-given`, `/v1/instances`, `/v1/instances/stream`, `/v1/operators`, `/v1/health`, `/v1/instance`, `/v1/listing-fee`, `/v1/chain-fee`, `/v1/release`, plus three RSS endpoints (`/rss/orderbook.xml`, `/rss/orderbook/by-asset/*`, `/rss/orderbook/by-account/*`).
|
||
|
||
**Response shapes are versioned.** Anything documented under `/v1/*` won't have fields renamed or removed without a `/v2/*` version bump. Adding new fields is non-breaking and you should ignore unknown fields. Versioning policy in detail at `docs/API.md`.
|
||
|
||
**Rate limits.** 120 req/min for list endpoints, 600 req/min for single-record lookups, per-IP per-minute, operator-tunable. If you need higher throughput, run your own indexer — see `RUN-A-MORPHIT-NODE.md`. Self-hosting gives you no rate limits and faster response times for your application.
|
||
|
||
**Why this design makes sense.** Morphit's whole architecture is built on the idea that data lives on the public blockchain and any indexer can recompute it. A locked-down API would be security theater because the underlying chain ops are already public — anyone scraping Blurt directly can build their own Morphit indexer in a weekend. Documenting the existing endpoints just makes the same data accessible to people who don't want to build their own chain indexer first.
|
||
|
||
**What CAN'T you do via this API:**
|
||
|
||
- Write data. Writes happen via signed `custom_json` ops broadcast to a blockchain node. See `apps/web/src/lib/blurt/sign.ts` for the pattern.
|
||
- Read encrypted chat content. Chat ciphertext is on-chain (visible to anyone) but only the two participants have the keys.
|
||
- Read private order metrics (e.g. per-order viewcount is gated to the order owner).
|
||
- Bypass the operator's rate limits. Run your own instance instead.
|
||
|
||
**Examples of what people build with this:**
|
||
|
||
- **Block explorers** that decorate Morphit ops on top of generic Blurt explorers
|
||
- **Federation health monitors** scraping `/v1/instances` for instance status
|
||
- **Trading-bot price feeds** combining `/v1/orderbook` data with external Blurt/USD prices
|
||
- **CLI clients** for sysadmins who want a terminal interface to Morphit
|
||
- **Academic research** on P2P market dynamics, Sybil-resistance economics, and federated reputation systems
|
||
- **Mobile apps** by operators or third parties who want a native experience while respecting Morphit's federation
|
||
- **RSS-driven dashboards** for traders who want order-feed alerts in their existing news reader
|
||
|
||
If you're building something interesting on the API, drop a note on the operators' Matrix channel — we'll add your project to a curated list of API consumers and link it from the operator handbook.
|
||
|
||
**Self-hosting as a first-class path.** If your aggregator is going to be high-volume, the right answer is run your own indexer. ~$5/month VPS, 30-minute setup (see `RUN-A-MORPHIT-NODE.md`), full speed-of-light access to the data. No rate limits, no operator-availability dependency, no aggregator-vs-instance fragility. This is the path serious projects should take.
|
||
|
||
---
|
||
|
||
## What is the featured slot and how does the auction work?
|
||
|
||
**FAQ key:** `what_is_featured_slot`
|
||
|
||
Featured slots are the top **3 highest-paying** orders that appear at the top of the orderbook page in a special highlighted section. They get more visibility than the regular orderbook list — useful when you want a fast trade and are willing to pay a small fee to be seen first.
|
||
|
||
**How bidding works.** You bid by paying Blurt into the Morphit fee account along with a `morphit_feature_bid_v1` op naming your order and the number of hours you want featured time. The rate you pay (Blurt per hour) determines your rank: the 3 highest-rate active bids are visible at any moment.
|
||
|
||
**Bid rules:**
|
||
• **Minimum bid duration:** 6 hours. Prevents one-hour cheap-shots from displacing serious multi-day bidders.
|
||
• **Maximum bid duration:** 1 week (168 hours) per bid.
|
||
• **Min-bid increment:** if your bid would displace someone currently visible, you must beat them by at least `max(1 Blurt/hour, 5%)`. Prevents penny-war bidding spam.
|
||
|
||
**What you pay:** rate × hours, in Blurt, transferred to the Morphit fee account when you submit the bid. The fee is non-refundable — see the **What happens if I get outbid?** entry for what "non-refundable" means in practice.
|
||
|
||
**Who sees featured slots:** every visitor to the orderbook page on every Morphit instance. Featured-slot rendering is part of the standard orderbook view, not opt-in.
|
||
|
||
---
|
||
|
||
## What happens to my featured slot if someone outbids me?
|
||
|
||
**FAQ key:** `featured_slot_displaced`
|
||
|
||
Your bid stays alive — you don't lose your money — but you lose visibility until the higher bidder's slot ends or you're un-displaced.
|
||
|
||
**Concretely:** Morphit shows the top 3 highest-paying active bids. If a 4th bidder posts a meaningfully higher rate (max of 1 Blurt/hour or 5% above the current 3rd-place bid — small increments are rejected to prevent grief-displacement), you drop to position 4 and become invisible in the featured section. Your bid record stays in the indexer. When any of the bids above you expires (their hours run out), you bubble up. If you eventually rise back into the top 3 before your own hours expire, you become visible again.
|
||
|
||
**No refund for displaced minutes.** This is deliberate. Refunds would require re-broadcasting transfer ops on every displacement — operationally messy and would create a perverse incentive (bid high, get displaced, get refunded, repeat). The simple rule is: you paid for N hours of *eligibility for the featured slot*, not N hours of *guaranteed visibility*.
|
||
|
||
**How to avoid being displaced:**
|
||
• Watch the current top-3 rates before bidding. If the lowest visible rate is 10 Blurt/hour, bidding 8 Blurt/hour means you're queued, not visible.
|
||
• Bid for shorter durations. 6 hours of guaranteed-visible time is often more useful than 24 hours of "might get displaced midway."
|
||
• Bid during low-traffic times. Featured-slot competition is higher when more traders are posting.
|
||
|
||
**Two protections built into the platform:**
|
||
|
||
• **Outbid push notifications.** If you've subscribed to Web Push (Settings → Notifications), Morphit sends a notification the moment you drop out of the top 3, with a deep-link to the affected order in `/my/orders`. You'll know within seconds — you don't have to refresh the orderbook manually.
|
||
|
||
• **Anti-snipe soft-close.** A late bidder can't insta-displace you at T-2 seconds: when a new bid arrives within 5 minutes of an expiring top-3 bid's deadline, that deadline auto-extends by 5 minutes. The extension can fire up to 6 times per bid (30 minutes total drag), giving you real time to counter. Your bid history shows an "Extended ×N" chip when anti-snipe has fired on one of your bids.
|
||
|
||
**Recap:** outbid = you stay queued, no refund, you get a push notification if subscribed, anti-snipe gives you time to counter, and you reappear when slots above you expire.
|
||
|
||
---
|
||
|
||
## How can I be sure no one is reading my chats? (Verify peer fingerprint)
|
||
|
||
**FAQ key:** `verify_peer_fingerprint`
|
||
|
||
Morphit chat is end-to-end encrypted by default — your messages are encrypted on your device with your counterparty's chat public key, and only their device can decrypt them.
|
||
|
||
The default trust model is "trust on first use" (TOFU): the first time you chat with someone, your client takes whatever chat key the indexer says is theirs. After that the chain-anchored pin (see "What if my chat key changed?") detects any future swap.
|
||
|
||
There's still one window where TOFU is theoretically vulnerable: the very first key exchange. A hostile indexer could, in principle, hand each side a different attacker-controlled key, so each side encrypts to the wrong person and the indexer reads everything in between. **The fingerprint feature gives you a way to detect this if you want to.**
|
||
|
||
**How to use it:**
|
||
|
||
1. Open the conversation with your counterparty.
|
||
2. Tap the ⋮ menu next to the Block button → **Verify peer**.
|
||
3. You'll see 8 words. Your counterparty does the same on their device.
|
||
4. Compare the words **out of band** — voice call, in person, or another platform you both already trust. **Do NOT compare them in this chat.**
|
||
5. If both sides see the **exact same 8 words**, you've got your proof that no MITM occurred. You're good to go.
|
||
6. If even one word differs, treat the conversation as compromised. Don't continue.
|
||
|
||
**What the fingerprint protects against:**
|
||
|
||
A malicious indexer relaying fake keys to both sides simultaneously. The fingerprint is computed locally on your device from the keys actually being used to encrypt — if the indexer lied, your fingerprint and your counterparty's fingerprint won't match.
|
||
|
||
**What the fingerprint does NOT protect against:**
|
||
|
||
- **Impersonation on the OOB channel.** If you call "Bob" but the person who answers is actually Mallory, comparing fingerprints with Mallory will succeed because she controls the conversation. You have to recognize Bob's actual voice / face / handle.
|
||
- **Their device being compromised.** If Bob's phone is owned by an attacker, the attacker reads everything no matter what. Fingerprint verification can't help with that.
|
||
- **Future key changes.** Each conversation has its own fingerprint based on both sides' current keys. If your counterparty rotates their posting key (e.g. after a security incident), they get a new chat key, and the old fingerprint becomes invalid. You'd verify again with the new one.
|
||
|
||
**Privacy note:**
|
||
|
||
The fingerprint feature is opt-in. There's no badge, no banner, no nag — most users will never see this. We don't track who taps "Verify peer". The 8-word fingerprint reveals nothing about you that wasn't already public (it's derived from public keys both sides already share).
|
||
|
||
**About the OOB channel:**
|
||
|
||
Choose a channel you both already trust. Voice call works (you recognize their voice). In-person works (you can see them). Another encrypted messenger you've already verified works. SMS to a number you don't already know does NOT work — you'd be establishing trust on an unverified channel, which defeats the purpose.
|
||
|
||
If your counterparty is a stranger you've never spoken to (a new orderbook contact), fingerprint verification gives you less than it gives a contact you already know — but it still protects against indexer-side MITM, which is its job.
|
||
|
||
---
|
||
|
||
## What is QR login and is it safe?
|
||
|
||
**FAQ key:** `qr_login`
|
||
|
||
QR login lets you sign in to Morphit on a computer by scanning a code with the Morphit app on your phone — no typing your seed phrase. When you tap "Sign in with QR" on the computer, Morphit creates a one-time code that's valid for 5 minutes. You scan it with your phone, your phone shows you the website name and asks if you really did just open it on your computer, and only after you tap "Yes, that was me" does the phone send a signed permission slip back to the computer. What's safe: your private key NEVER leaves your phone. The code on the screen is a request, not a key. Even if someone screenshots the code, they can't use it without YOUR phone tapping yes. What to watch out for: when your phone asks "Sign in to morphit.io?", read the website name carefully. A scammer could send you to a fake page like "morph1t.io" (with a 1 instead of an i). Only tap Yes if YOU just opened the real Morphit on your computer. If you didn't, tap No. What this isn't: it's not a way to use Morphit without your phone. If you lose your phone you fall back to your written seed phrase. What we don't store: the operator running the website only sees an encrypted permission slip pass through. They can't read it; they can't pretend to be you.
|
||
|
||
---
|
||
|
||
## What is USDT (Tether)?
|
||
|
||
**FAQ key:** `what_is_usdt`
|
||
|
||
USDT is a stablecoin issued by Tether Inc., designed to maintain a 1:1 peg with the US dollar. Active traders use it to park value temporarily without converting to fiat — for example, between trades, or to avoid volatility in BTC/XMR while waiting for a better entry. On Morphit you can buy and sell USDT peer-to-peer across four networks: Ethereum (ERC-20), Tron (TRC-20), Solana (SPL), and BNB Smart Chain (BEP-20). USDT is **trade-only** on Morphit — you can never pay listing fees, cold-message fees, or featured-slot bids with it. Those always cost Blurt, BTC, or XMR. The fee invariant is wire-format-frozen and enforced by sentinel smokes in CI.
|
||
|
||
---
|
||
|
||
## What is USDC?
|
||
|
||
**FAQ key:** `what_is_usdc`
|
||
|
||
USDC (USD Coin) is a stablecoin issued by Circle, a US-based financial-services company, designed to maintain a 1:1 peg with the US dollar. It's the second-most-traded stablecoin in the world after USDT, and many active traders prefer it because Circle publishes monthly attestation reports on the reserves backing each token and is regulated under New York DFS oversight. On Morphit you can buy and sell USDC peer-to-peer across four networks: Ethereum (ERC-20), Solana (SPL), Base, and Polygon. Pick whichever network you and your counterparty both support; the picker on the order form makes you commit to a specific network up front so a cross-network send can't accidentally lose your funds. USDC is a tradable asset only — listing fees on Morphit stay in Blurt, BTC, or XMR. See also the per-asset privacy guide at `/privacy/usdc` for the honest trade-offs.
|
||
|
||
---
|
||
|
||
## Why does Morphit show a chip about how USDT is issued and transmitted?
|
||
|
||
**FAQ key:** `why_usdt_warning`
|
||
|
||
USDT is the most-traded stablecoin in the world, and millions of traders rely on its dollar-stability and broad acceptance every day. When Morphit lists an asset, we tell our users about the technical properties of that asset honestly, so they can make an informed choice for each trade. For USDT, two facts worth knowing: (1) USDT is issued and administered by Tether Inc., and Tether has the technical ability to freeze addresses on the host chain — they have used this ability in the past, mostly in response to law-enforcement requests. (2) USDT transactions on every supported host chain (Ethereum, Tron, Solana, BNB Smart Chain) are publicly visible on those chains; this is a property of the chain, not unique to USDT. Different traders weigh these differently. If you want maximum on-chain privacy, XMR is the right tool. If you want maximum decentralization-from-any-single-issuer with transparent chains, BTC, Blurt, BCH, LTC, DASH, DOGE, DCR, SOL, ETH, or XRP are the right tools. If you want dollar-denominated stability and a market that's liquid almost anywhere, USDT is the right tool. The Morphit chip is information, not a verdict — pick the asset that fits the trade you're making.
|
||
|
||
---
|
||
|
||
## Why does Morphit show a privacy warning when I trade USDC?
|
||
|
||
**FAQ key:** `why_usdc_warning`
|
||
|
||
USDC carries the same class of warning as USDT: it's a centralized stablecoin. Circle (USDC's issuer) has the technical ability to freeze any individual USDC address on any of the supported networks via a contract-level admin function. They have used it in the past in response to court orders, OFAC sanctions, and reported fraud. None of the other assets on Morphit (BTC, XMR, Blurt, BCH, LTC, DASH, DOGE, ZEC, ARRR, DCR, SOL, ETH, XRP) have any issuer; nobody can freeze any address. We don't think this makes USDC bad — many traders consciously accept this trade-off for the dollar stability that comes with it — but we think you should know about it before every USDC trade, the same way we want you to know that XMR trades have stronger privacy than BTC trades. The warning chip on the order form is informational, not blocking; it's there so the choice is yours and informed. Operators can disable USDC instance-wide if they prefer to keep their instance free of centralized stablecoins; users can simply choose a different asset on this instance, or pick a different operator's instance, if they prefer.
|
||
|
||
---
|
||
|
||
## Which USDT network should I pick — ERC-20, TRC-20, SPL, or BEP-20?
|
||
|
||
**FAQ key:** `which_usdt_network`
|
||
|
||
It depends on what you and your counterparty already hold and what fees you can stomach. **TRC-20 (Tron)** is the most common for P2P trades because the network fees are around $1 — predictable and cheap. **ERC-20 (Ethereum)** is the most universally accepted: every exchange, every wallet, every smart-contract platform supports it; fees are $5-20 and slower, but if your trade settles on an Ethereum-side application, this is the network to use. **SPL (Solana)** has the lowest fees (under $0.01) and is fast, but less universally accepted; pick this if you and your counterparty both use Solana wallets. **BEP-20 (BNB Smart Chain)** has fees around $0.30, fast, but less common — useful if you're moving USDT between Binance and another BSC-using counterparty. There is **no default** on Morphit — every USDT trade requires explicit network choice because cross-network sends are unrecoverable. If you send USDT-ERC20 to a TRC-20 address (or vice versa), the funds are gone forever. The network picker on the post-order form refuses to let you submit until you choose.
|
||
|
||
---
|
||
|
||
## Which USDC network should I use?
|
||
|
||
**FAQ key:** `which_usdc_network`
|
||
|
||
It depends on what you and your counterparty already hold and what fees you can stomach. **Solana (SPL)** is the cheapest of the four — fees are usually a fraction of a cent — but requires both parties to have a Solana wallet (Phantom, Solflare, etc.). **Base** is a layer-2 on Ethereum and offers fees around $0.01-0.10; if you both have an EVM wallet (MetaMask, Rabby, etc.) Base is often the right pick. **Polygon (PoS)** is similar territory to Base with slightly different wallet support; many exchanges withdraw USDC on Polygon natively. **Ethereum (ERC-20)** is the most universally accepted: every exchange, every wallet, every smart-contract platform supports it; but mainnet fees can be $5-20 a transaction, so it's rarely the right pick for a P2P trade unless one of you is sending FROM or TO a service that only supports ERC-20. Critical foot-gun: three of the four (ERC-20, Base, Polygon) all use the same `0x[40 hex]` Ethereum-format address. An address that's valid on Polygon is also a valid address on Ethereum and Base — but each chain holds its own separate USDC balance for that address. If you send USDC on Polygon to an address your counterparty gave you for Base, the funds will arrive on Polygon, not Base, and the counterparty's Base wallet won't show them. Both parties should explicitly confirm which network before sending; the order form's network picker locks this in at post-time so the chat message header tells the receiver which chain to expect.
|
||
|
||
---
|
||
|
||
## What is DAI?
|
||
|
||
**FAQ key:** `what_is_dai`
|
||
|
||
DAI is a USD-pegged stablecoin issued by the MakerDAO protocol on Ethereum. Unlike USDT (Tether Inc.) and USDC (Circle), DAI is not issued by a single corporate entity — it's governed by holders of the MKR token through on-chain votes, and the DAI token contract itself has no admin-controlled freeze function. Many traders prefer DAI for that reason. Honest nuance: since 2020, MakerDAO's Peg Stability Module (PSM) holds USDC as collateral to dampen peg deviations, so when DAI's peg is supported by USDC, Circle's freeze power over USDC indirectly affects DAI's redeemability. DAI is also upgradeable in principle through MKR governance, though no freeze mechanism has been deployed in practice. On Morphit you can buy and sell DAI peer-to-peer across four networks: Ethereum (ERC-20, native), Polygon, Base, and Arbitrum One. Pick whichever network you and your counterparty both support; the network picker locks this in at post-time so a cross-network send can't accidentally lose your funds. DAI is a tradable asset only — listing fees on Morphit stay in Blurt, BTC, or XMR. See also the per-asset privacy guide at `/privacy/dai`.
|
||
|
||
---
|
||
|
||
## Why does Morphit show a privacy warning when I trade DAI?
|
||
|
||
**FAQ key:** `why_dai_warning`
|
||
|
||
DAI's warning is more nuanced than USDT's or USDC's because DAI is genuinely more decentralized — but not freeze-immune. Three things to know: (1) The Dai token contract has NO admin-controlled freeze function. MakerDAO can't blacklist your address and stop transfers, the way Tether or Circle can on their stablecoins. This is a real advantage that DAI supporters rightly point to. (2) The Peg Stability Module (PSM) holds significant USDC reserves as collateral to dampen peg deviation. When DAI's peg is partly supported by USDC, Circle's freeze power over USDC transitively affects DAI's redemption mechanics — if Circle were to freeze the PSM's USDC, the peg-arbitrage path closes for that portion of the supply. (3) MakerDAO governance (MKR token holders) could theoretically deploy a contract upgrade that adds freeze or pause mechanisms. This hasn't happened in practice, but it's possible. Bottom line: DAI's decentralization story is real but partial — better than fully centralized stablecoins on the freeze-immunity axis, less so than truly decentralized assets like BTC/XMR. Like all stablecoins on Morphit, DAI transactions are publicly visible on each supported network — there is no on-chain privacy. The warning chip on the order form is informational, not blocking; it's there so the choice is yours and informed. Operators can disable DAI instance-wide if they prefer to keep their instance free of stablecoins entirely.
|
||
|
||
---
|
||
|
||
## Which DAI network should I use?
|
||
|
||
**FAQ key:** `which_dai_network`
|
||
|
||
DAI runs on four networks Morphit supports: Ethereum (ERC-20, native), Polygon (PoS), Base, and Arbitrum One. All four are EVM-family with `0x[40 hex]` addresses — they look IDENTICAL. An address that's valid on Polygon is also a valid-format address on Ethereum, Base, AND Arbitrum, but each chain holds its own separate DAI balance for that address. The network picker on the order form locks the network in at post-time so the chat message header tells the receiver which chain to expect. This is the highest cross-network address-confusion surface on Morphit — be especially careful. **Ethereum (ERC-20)** is the most universal — every exchange, wallet, and smart-contract platform supports it — but mainnet fees can be $5-20 per transaction, so it's rarely the right pick for a P2P trade unless one of you is sending FROM or TO a service that only supports ERC-20. **Polygon (PoS)** is much cheaper (cents per transaction); many exchanges withdraw DAI on Polygon natively. **Base** is Coinbase's layer-2 on Ethereum and offers fees around $0.01-0.10; if you both have an EVM wallet (MetaMask, Rabby, etc.), Base is often the right pick. **Arbitrum One** is similar territory to Base — another major Ethereum layer-2 with very low fees. Both parties should explicitly confirm which network before sending; the order form's network picker locks this in at post-time.
|
||
|
||
---
|
||
|
||
## How does arbitrage between Morphit and centralized/decentralized exchanges work?
|
||
|
||
**FAQ key:** `arbitrage_morphit_vs_exchanges`
|
||
|
||
Morphit is built so arbitrage is easy. Listing fees are a fraction of a dollar, there's no taker fee, no withdrawal fee on the trade itself, no withdrawal limit, and no waiting period. A trader who sees a price gap between Morphit's P2P market and a CEX (Coinbase, Kraken, Binance, Hive-Engine (HE)) or a "DEX" (Uniswap, THORChain) can post a Morphit order at a thin spread on either side and let the orderbook fill. The price-model picker lets you pin a `spread: 0.5%` against the live CoinGecko mid-price so your order tracks the market automatically — no manual re-pricing as the worldwide price moves. As more traders use Morphit, arbitrageurs naturally pull the P2P prices into line with the broader market, which is good for everyone trading on the marketplace: tighter spreads, better fills, more predictable execution. A few practical notes: Morphit's per-trade settlement is what you make it — direct wallet-to-wallet for crypto-vs-crypto pairs (XMR for USDT, BTC for USDT), or via your bank/fiat rail of choice for crypto-vs-fiat. For high-frequency arbitrage, the Sybil-tier fee structure escalates listing costs if you post many orders quickly from the same account; this is anti-spam infrastructure, not anti-arbitrage — most arbitrageurs run a single account per direction and never hit the tier-2 threshold.
|
||
|
||
---
|
||
|
||
## Can I market-make or run a trading bot on Morphit?
|
||
|
||
**FAQ key:** `market_making`
|
||
|
||
Yes — Morphit is built to welcome market makers and trading bots. There's no maker or taker fee: you pay only the flat listing fee of about $0.12 per order, with no withdrawal fee, no withdrawal limit, and no waiting period. The order form's `spread` price model pins an order a set percentage off the live CoinGecko mid-price (for example, `market ± 0.5%`), so it re-prices itself as the worldwide price moves instead of needing manual updates. The whole orderbook is readable programmatically over the read-only MCP tools and the RSS feeds — no API key, no account approval, no KYC — and because every order is a plain on-chain operation, a bot can post one by signing directly while the instance never holds your funds. The anti-spam Sybil-tier fee only escalates if you fire many orders from one account at once; running one account per side stays well under the threshold.
|
||
|
||
---
|
||
|
||
## What is DOGE on Morphit?
|
||
|
||
**FAQ key:** `what_is_doge`
|
||
|
||
DOGE is Dogecoin — a proof-of-work chain launched in 2013 as a fair-launched fork of Lucky Coin (itself a Litecoin fork). It's transparent at the base layer like Bitcoin: every transaction is publicly visible on the chain. The chain is fully decentralized; no issuer or foundation can freeze your addresses. Since 2014 it has been merge-mined with Litecoin (auxiliary proof-of-work), inheriting Litecoin's hashrate security without competing for it.
|
||
|
||
On Morphit, DOGE is **trade-only** — you can buy or sell DOGE in P2P trades, but you can't pay Morphit's listing fees in DOGE (those stay Blurt/BTC/XMR). The same fee_method enum applies to every Category-B asset (USDT/USDC/DAI/BCH/LTC/DASH/DOGE/ZEC), so the rule is uniform.
|
||
|
||
**Privacy posture**: DOGE has no native privacy upgrade. No PrivateSend equivalent, no confidential transactions, no segwit-enabled mixing. Every receive address you publish links to its on-chain history forever. Use a fresh HD-derived address per trade (your wallet usually does this automatically).
|
||
|
||
**Address formats**: D… (P2PKH, most common), 9… or A… (P2SH, multi-sig, rare on DOGE). No bech32 — Dogecoin Core has not activated segwit.
|
||
|
||
**Wallets that work well**: Dogecoin Core (official, full node), MyDoge, Trezor + Ledger (hardware), Electrum-DOGE for desktop.
|
||
|
||
---
|
||
|
||
## What is ZEC on Morphit?
|
||
|
||
**FAQ key:** `what_is_zec`
|
||
|
||
ZEC is Zcash — a proof-of-work chain launched in 2016. It was the first practical implementation of zero-knowledge proofs in a cryptocurrency. The chain supports two address families that coexist on the same protocol: transparent (t1/t3, base58 addresses similar in shape to Bitcoin's legacy format) where transaction amounts and parties are publicly visible, and shielded (zs1 Sapling, u1 Unified Address bundling Orchard receivers) where zk-SNARKs hide sender, recipient, and amount on chain. Per-trade, you and your counterparty pick the address type that fits the trade's posture.
|
||
|
||
On Morphit, ZEC is **trade-only** — you can buy or sell ZEC in P2P trades, but you can't pay Morphit's listing fees in ZEC (those stay Blurt/BTC/XMR). The same fee_method enum applies to every Category-B asset (USDT/USDC/DAI/BCH/LTC/DASH/DOGE/ZEC), so the rule is uniform.
|
||
|
||
**Address formats**: t1… (transparent P2PKH, the most common transparent type), t3… (transparent P2SH, multi-sig), zs1… (Sapling shielded, bech32, 78 chars total), u1… (Unified Address bundling Orchard + optional Sapling/transparent receivers, bech32m, variable length typically 90–300 chars).
|
||
|
||
**Wallets that work well**: Zashi (official mobile wallet from the Electric Coin Co, Sapling + Orchard support), Zecwallet (desktop, legacy Sapling), Nighthawk Wallet (mobile, Sapling). Verify your counterparty's wallet handles the address type you plan to publish — newer wallets support Unified Addresses (u1) and older wallets may only support Sapling (zs1) or transparent.
|
||
|
||
---
|
||
|
||
## What is Pirate Chain (ARRR), and why is it on Morphit?
|
||
|
||
**FAQ key:** `what_is_arrr`
|
||
|
||
Pirate Chain (ARRR) is a proof-of-work cryptocurrency that runs the Sapling zk-SNARK shielded pool as its only transaction type — every transfer hides sender, recipient, and amount on chain by construction. There's no transparent address option on Pirate Chain; the transparent pool was sunset early in the chain's life and all funds migrated to the shielded pool.
|
||
|
||
On Morphit, ARRR is a **trade-only** asset: you can buy and sell it peer-to-peer (any fiat or in-person payment method on the other side), but you cannot pay listing fees in ARRR. Listing fees stay Blurt/BTC/XMR (Memory #23 invariant — the fee_method enum is frozen).
|
||
|
||
Addresses use a single format: `zs1` Sapling shielded (bech32, 78 chars). Visually identical to Zcash Sapling addresses — Morphit's per-asset tab and placeholder disambiguate which chain the address belongs to. Use a Pirate Chain wallet like Treasure Chest (mobile), Pirate.Black, or the Verus-integrated Pirate wallet to generate addresses and receive funds.
|
||
|
||
Operators can refuse ARRR trades per-instance via `MORPHIT_INDEXER_DISABLED_ASSETS="ARRR"`; the federated marketplace keeps trading ARRR regardless of any single operator's stance.
|
||
|
||
---
|
||
|
||
## What is Decred (DCR), and why is it on Morphit?
|
||
|
||
**FAQ key:** `what_is_dcr`
|
||
|
||
Decred (DCR) is a hybrid Proof-of-Work + Proof-of-Stake cryptocurrency launched in 2016. Every block is mined by PoW miners AND voted on by 5 PoS ticket-holders chosen pseudo-randomly from the staking pool — this dual consensus means neither miners nor stakers alone can change protocol rules. On-chain governance via Politeia lets stakeholders propose, debate, and ratify protocol changes; treasury funds flow through community vote.
|
||
|
||
On Morphit, DCR is a **trade-only** asset: you can buy and sell it peer-to-peer (any fiat or in-person payment method on the other side), but you cannot pay listing fees in DCR. Listing fees stay Blurt/BTC/XMR (Memory #23 invariant — the fee_method enum is frozen).
|
||
|
||
Addresses use two formats: `Ds` P2PKH-Secp256k1 (most common receive format) and `Dc` P2SH (multisig/escrow scripts) — both 35 chars, base58. Use a Decred wallet like dcrwallet, Decrediton, or Cake Wallet for DCR to generate addresses and receive funds. The chain is transparent at the base layer (sender, recipient, amount visible on chain), but offers an opt-in CoinShuffle++ (CSPP) mixing protocol integrated into dcrwallet for users who want transaction-level privacy.
|
||
|
||
Operators can refuse DCR trades per-instance via `MORPHIT_INDEXER_DISABLED_ASSETS="DCR"`; the federated marketplace keeps trading DCR regardless of any single operator's stance.
|
||
|
||
---
|
||
|
||
## What is Solana (SOL), and why is it on Morphit?
|
||
|
||
**FAQ key:** `what_is_sol`
|
||
|
||
Solana (SOL) is a Proof-of-Stake cryptocurrency launched in 2020. It uses delegated PoS consensus combined with Proof-of-History sequencing to achieve high transaction throughput. Validators stake SOL and process blocks in rotation; no central freeze authority controls the chain.
|
||
|
||
On Morphit, SOL is a **trade-only** asset: you can buy and sell it peer-to-peer (any fiat or in-person payment method on the other side), but you cannot pay listing fees in SOL. Listing fees stay Blurt/BTC/XMR (Memory #23 invariant — the fee_method enum is frozen).
|
||
|
||
Solana addresses are 32-byte public keys encoded as base58 — 32-44 characters (most are exactly 44). Use a Solana wallet like Phantom, Solflare, Cake Wallet for SOL, or Trust Wallet to generate addresses and receive funds. The chain is transparent at the base layer (sender, recipient, and amount visible on chain). Solana has no native protocol-level mixing; wallet-side address rotation is the user's primary privacy lever.
|
||
|
||
Note: Solana addresses look identical to USDT-on-Solana and USDC-on-Solana SPL token-account addresses. The asset field on the order disambiguates — Morphit shows you which asset you're sending so wallet confusion is avoided.
|
||
|
||
Operators can refuse SOL trades per-instance via `MORPHIT_INDEXER_DISABLED_ASSETS="SOL"`; the federated marketplace keeps trading SOL regardless of any single operator's stance.
|
||
|
||
---
|
||
|
||
## What is Ethereum (ETH), and why is it on Morphit?
|
||
|
||
**FAQ key:** `what_is_eth`
|
||
|
||
Ethereum (ETH) is a Proof-of-Stake cryptocurrency launched in 2015. It transitioned from Proof-of-Work to Proof-of-Stake in September 2022 ("The Merge"). Validators stake ETH and process blocks in rotation; no central freeze authority controls the chain.
|
||
|
||
On Morphit, ETH is a **trade-only** asset: you can buy and sell it peer-to-peer (any fiat or in-person payment method on the other side), but you cannot pay listing fees in ETH. Listing fees stay Blurt/BTC/XMR (Memory #23 invariant — the fee_method enum is frozen).
|
||
|
||
Ethereum addresses are 20-byte hex with a `0x` prefix — exactly 42 characters total. Both lowercase and EIP-55 mixed-case checksum forms are accepted. Use an Ethereum wallet like MetaMask, Rabby, Frame, Rainbow, or Trust Wallet to generate addresses and receive funds. The chain is transparent at the base layer (sender, recipient, and amount visible on chain). Ethereum has no native protocol-level mixing; wallet-side address rotation is the user's primary privacy lever.
|
||
|
||
Note: Ethereum addresses look IDENTICAL to USDT-ERC20, USDC-ERC20, DAI-ERC20, and any EVM token-account address on Base, Polygon, Arbitrum, or BSC. The asset field on the order (and the network field for multi-network assets) disambiguates — Morphit shows you which asset you're sending so wallet confusion is avoided.
|
||
|
||
ETH can also be sent to a smart-contract address that may not accept it (no payable receive/fallback function); modern wallets warn before sending to contracts. ENS names (alice.eth) are NOT resolved by Morphit — paste raw 0x addresses to avoid centralized RPC dependency for name resolution.
|
||
|
||
Operators can refuse ETH trades per-instance via `MORPHIT_INDEXER_DISABLED_ASSETS="ETH"`; the federated marketplace keeps trading ETH regardless of any single operator's stance.
|
||
|
||
---
|
||
|
||
## What is Ripple (XRP), and why is it on Morphit?
|
||
|
||
**FAQ key:** `what_is_xrp`
|
||
|
||
Ripple (XRP) is the native digital asset of the XRP Ledger (XRPL), launched in 2012. XRPL uses Federated Byzantine Agreement (FBA) consensus — validators on a Unique Node List (UNL) reach agreement on transaction ordering. The default UNL is published by the XRP Ledger Foundation (a non-profit), with the for-profit Ripple Labs Inc. historically influencing validator selection.
|
||
|
||
On Morphit, XRP is a **trade-only** asset: you can buy and sell it peer-to-peer (any fiat or in-person payment method on the other side), but you cannot pay listing fees in XRP. Listing fees stay Blurt/BTC/XMR (Memory #23 invariant — the fee_method enum is frozen).
|
||
|
||
XRPL addresses start with `r` followed by 24-34 base58 characters. Use an XRPL wallet like Xaman (formerly Xumm), Crossmark, Bifrost, GemWallet, or Trust Wallet to generate addresses and receive funds. The chain is transparent at the base layer (sender, recipient, and amount visible on chain). XRPL has no native protocol-level mixing; wallet-side address rotation is the user's primary privacy lever.
|
||
|
||
Two XRPL-specific UX gotchas to be aware of:
|
||
|
||
**1. Destination tags.** XRPL has a unique feature — a 32-bit integer destination tag that exchanges use to route XRP to user accounts under their omnibus wallet. When sending XRP to an exchange-hosted address (Binance, Bitstamp, Kraken, etc.), you MUST include the destination tag specified by the exchange — otherwise the transaction succeeds on-chain but the funds land in the exchange's general pool and don't credit your account. Recovery requires opening a support ticket. For peer-to-peer trades on Morphit, your counterparty is typically NOT an exchange and a destination tag is not required, but always check whether the recipient address needs one.
|
||
|
||
**2. Reserve requirement.** XRPL accounts need a minimum XRP balance (currently 1 XRP base reserve) to exist on the ledger. Sending less than 1 XRP to a never-funded address fails on-chain. For your first XRP receive, ask your counterparty to send at least 1 XRP (or fund the address yourself first from an existing XRPL account).
|
||
|
||
XRP can also have its IOU (issued token) variants frozen by the issuer — but this applies ONLY to issued tokens, NOT to native XRP. Native XRP cannot be frozen by any central authority.
|
||
|
||
Operators can refuse XRP trades per-instance via `MORPHIT_INDEXER_DISABLED_ASSETS="XRP"`; the federated marketplace keeps trading XRP regardless of any single operator's stance.
|
||
|
||
---
|
||
|
||
## What is Bitcoin Cash (BCH), and why is it on Morphit?
|
||
|
||
**FAQ key:** `what_is_bch`
|
||
|
||
Bitcoin Cash (BCH) is a fork of Bitcoin that activated in August 2017, prioritizing larger block sizes and lower on-chain fees for everyday-payment-style usage. The chain shares Bitcoin's UTXO model and Proof-of-Work consensus but operates with substantially larger blocks (32 MB+) and a separate difficulty adjustment.
|
||
|
||
On Morphit, BCH is a **trade-only** asset: you can buy and sell it peer-to-peer (any fiat or in-person payment on the other side), but you cannot pay listing fees in BCH. Listing fees stay Blurt/BTC/XMR (Memory #23 invariant — the fee_method enum is frozen).
|
||
|
||
BCH supports two address formats: legacy base58 (starts with `1` or `3`, same shape as BTC addresses — asset field disambiguates) and CashAddr bech32 (starts with `bitcoincash:q` or `bitcoincash:p`). Morphit accepts both. The chain is transparent at the base layer like Bitcoin; wallet-side address rotation is the user's primary privacy lever.
|
||
|
||
Operators can refuse BCH trades per-instance via `MORPHIT_INDEXER_DISABLED_ASSETS="BCH"`; the federated marketplace keeps trading BCH regardless of any single operator's stance.
|
||
|
||
---
|
||
|
||
## What is Litecoin (LTC), and why is it on Morphit?
|
||
|
||
**FAQ key:** `what_is_ltc`
|
||
|
||
Litecoin (LTC) is one of the oldest cryptocurrencies, forked from an early Bitcoin codebase in October 2011. It uses Scrypt-based Proof-of-Work mining (designed at the time to be more memory-hard than Bitcoin's SHA-256) and a faster ~2.5-minute block target.
|
||
|
||
On Morphit, LTC is a **trade-only** asset: you can buy and sell it peer-to-peer (any fiat or in-person payment on the other side), but you cannot pay listing fees in LTC. Listing fees stay Blurt/BTC/XMR (Memory #23 invariant — the fee_method enum is frozen).
|
||
|
||
LTC addresses come in three formats: legacy P2PKH (starts with `L`), P2SH (starts with `M` or `3`), and bech32 (starts with `ltc1`). Morphit accepts all three. The chain has supported optional MimbleWimble Extension Blocks (MWEB) since 2022 for confidential transactions — but MWEB-side transfers ride alongside transparent transfers; for Morphit P2P trades you can use either, with the same wallet-side address-rotation privacy practices that apply to BTC.
|
||
|
||
Operators can refuse LTC trades per-instance via `MORPHIT_INDEXER_DISABLED_ASSETS="LTC"`; the federated marketplace keeps trading LTC regardless of any single operator's stance.
|
||
|
||
---
|
||
|
||
## What is Dash (DASH), and why is it on Morphit?
|
||
|
||
**FAQ key:** `what_is_dash`
|
||
|
||
Dash (DASH) is a cryptocurrency forked from Litecoin in January 2014 (originally as XCoin, then Darkcoin, finally renamed Dash in March 2015). It uses an X11-based Proof-of-Work mining algorithm and a masternode tier: operators stake 1,000 DASH each to run a masternode, which provides services like InstantSend (sub-second locked confirmations) and PrivateSend (opt-in CoinJoin-style mixing through masternodes).
|
||
|
||
On Morphit, DASH is a **trade-only** asset: you can buy and sell it peer-to-peer (any fiat or in-person payment on the other side), but you cannot pay listing fees in DASH. Listing fees stay Blurt/BTC/XMR (Memory #23 invariant — the fee_method enum is frozen).
|
||
|
||
DASH addresses use two formats: legacy P2PKH (starts with `X`) and P2SH (starts with `7`). Morphit accepts both. The base layer is transparent like Bitcoin; PrivateSend mixing is opt-in and wallet-side. Wallet-side address rotation is the user's primary privacy lever for transparent transfers; PrivateSend is available for users wanting an additional mixing pass before sending.
|
||
|
||
Operators can refuse DASH trades per-instance via `MORPHIT_INDEXER_DISABLED_ASSETS="DASH"`; the federated marketplace keeps trading DASH regardless of any single operator's stance.
|
||
|
||
---
|
||
|
||
## I'm a wallet developer — can I integrate Morphit's orderbook into my wallet UI?
|
||
|
||
**FAQ key:** `wallet_developer_api`
|
||
|
||
Yes, and we'd love it. Morphit publishes a stable public REST + SSE API (documented at `/v1/openapi.json` on any instance) covering the orderbook, profiles, feedback, and chat. Wallet developers can embed a Morphit orderbook screen directly in their wallet UI — the way Mycelium famously integrated LocalBitcoins back in the day — so users can browse and respond to peer-to-peer offers without leaving the wallet they already trust.
|
||
|
||
**What you can build with the API:**
|
||
- Filtered orderbook view scoped to whichever assets your wallet supports (BTC-only, XMR + BTC, multi-coin, etc.)
|
||
- Counterparty reputation lookup by account name — feedback count, average rating, account age
|
||
- Order detail pages with payment-method, amount, region, terms
|
||
- Encrypted chat threads routed through the user's existing Blurt posting key (you handle the UX; Morphit handles the cryptography)
|
||
- Federation-aware fetching — query any operator's instance, or your own; the orderbook is the same chain-backed data
|
||
|
||
**What we recommend:**
|
||
- Use Morphit's `@morphit/indexer-client` TypeScript workspace package if you're in a JS/TS stack — it's type-checked against the OpenAPI schema
|
||
- Cache responses with the published `ETag`/`Last-Modified` headers; the SSE stream tells you when state changes so you don't need to poll
|
||
- For maximum independence, point your wallet at a self-hosted Morphit instance or a community-run one; federation means the user gets the same orderbook either way
|
||
- The API is open and free; we ask only that you keep the Morphit orderbook attribution visible in the UI ('powered by Morphit P2P') so users know what they're looking at
|
||
|
||
If you'd like help, drop into our Matrix room (#agorise:matrix.org) or open an issue at git.agorise.net/agorise/morphit. The API is AGPL-3.0 like the rest of the project; integrators ship in their own license, and the network effect is mutual — every wallet that embeds Morphit's orderbook is an additional discovery path for new traders, and every new trader is a counterparty available to existing wallet users.
|
||
|
||
---
|
||
|
||
## How do I get people to use Morphit?
|
||
|
||
**FAQ key:** `how_to_spread_morphit`
|
||
|
||
Word of mouth is the entire growth strategy. Morphit doesn't advertise, doesn't run promoted content, doesn't pay influencers — but every operator and supporter who brings a few people to the platform makes the orderbook materially more useful for everyone. Here are the channels that have worked, ordered roughly cheapest-effort-first:
|
||
|
||
**1. Online channels (free).**
|
||
- **Blog write-ups** on Blurt.blog (publish in the same ecosystem you're trading in — and earn Blurt for the post), Substack, Medium, Ghost, Mirror, or your own site. Deep-dive posts about Morphit, Blurt, and the broader cypherpunk fiat-to-crypto problem age well: linkable, citable, evergreen. Cross-post to Hacker News, Lobste.rs, the Monero subreddit, and any community where on-topic.
|
||
- **meetup.com groups** for crypto, Bitcoin, Monero, privacy, libertarian, freedom-tech, mesh-networks, and adjacent topics — many have monthly meetups where a 5-minute show-and-tell of the Morphit app is welcome
|
||
- **University clubs and billboards** — student cryptography clubs, libertarian student groups, computer science societies. Pin a printed QR-code-to-/install poster.
|
||
- **Existing privacy/security communities** like KYCnot.me, PrivacyGuides forums, Monero subreddit/Matrix, GrapheneOS discussions
|
||
|
||
**2. Physical channels (small printing cost).**
|
||
- **Flyers handed out at factory gates during quitting time** — many workers have unbanked or underbanked cash needs that crypto-no-KYC solves, and they're stationary in a line for 60 seconds where you can hand them something
|
||
- **Flyers on cars in parking lots, on doors, on community corkboards** in coffee shops, libraries, makerspaces, freedom-tech events. Keep the QR code big and the call-to-action one line ('Buy crypto, no ID' / 'Sell crypto for cash')
|
||
- **Stickers** on laptops at conferences, on lampposts in tech-heavy neighborhoods. Cheaper than flyers per impression
|
||
|
||
**3. Cross-promotion (free).**
|
||
- **Other crypto communities**: Ethereum, DeFi, Solana, XRP, Pirate Chain, Decred — each has its own user base, and Morphit trades all of them. A 'we trade your favorite coin too, peer-to-peer no KYC' angle lands well
|
||
- **Non-crypto communities** with overlap on values: libertarian groups, voluntaryist meetups, privacy advocates, sound-money / hard-money advocates, freedom-tech and mesh-network communities, agorist circles. Morphit is built specifically for the values these communities already hold
|
||
|
||
**4. Paid local promoters (operator-level, modest spend).**
|
||
- Pay a local crypto-curious 'geek marketer' a small base salary in pesos (or whatever your local currency is) plus performance commissions paid in Blurt. The peso salary keeps them committed; the Blurt commissions align them with the network's long-term growth and give them a free-speech-token stake. Commission events that work: new account signup (small bounty), first successful trade (larger bounty), demoing the app at a meetup (event-based bounty)
|
||
- This is exactly the kind of distributed grassroots marketing where Morphit's federation model shines — every operator can build their own local promoter network, independent of any central marketing budget
|
||
|
||
**5. What NOT to do.**
|
||
- Don't spam Telegram groups, Discord servers, or subreddits where you're not a regular. Crypto communities have strong spam-immunity reflexes and you'll burn the brand
|
||
- Don't pitch Morphit to people who already have a CEX account and are happy with it; pitch to the unbanked, the privacy-conscious, the people who've had CEX accounts frozen
|
||
- Don't promise things Morphit doesn't promise (no instant arbitration, no escrow, no guaranteed liquidity) — overselling drives churn
|
||
|
||
The federation model means every successful local promotion grows the network for everyone. A meetup attendee who joins through your operator instance is a counterparty available on every other operator's instance simultaneously. Local growth is worldwide growth.
|
||
|
||
---
|
||
|
||
## What is two-factor authentication and how do I enable it on Morphit?
|
||
|
||
**FAQ key:** `totp_2fa_what_is_it`
|
||
|
||
Two-factor authentication (2FA) means you need TWO pieces of evidence to unlock your Morphit keystore: your password (something you know) plus a rotating 6-digit code from a phone app (something you have). On Morphit, 2FA is completely optional — Morphit will NEVER require it, nag you to enroll, or warn you that your account is "insecure" without it. To enable it, go to Settings → Two-factor authentication, install one of our recommended open-source authenticator apps (Aegis, 2FAS, or Ente Auth), scan the QR code, and save the 10 backup codes somewhere safe. Honest about what it does: 2FA on Morphit blocks shoulder-surfing, borrowed-device replay, and casual local malware. It does NOT add cryptographic strength against an attacker who has both your encrypted keystore AND your password — the TOTP secret lives in the same encrypted blob as your keys. For that threat model, the path forward is FIDO2/WebAuthn hardware keys, which Morphit has exploratory support for.
|
||
|
||
---
|
||
|
||
## I lost my authenticator app — how do I get back in?
|
||
|
||
**FAQ key:** `totp_2fa_lost_authenticator`
|
||
|
||
When you enrolled in 2FA, Morphit showed you 10 backup codes and required you to acknowledge that you saved them somewhere safe (a password manager, printed and locked away, or written on paper). At the unlock screen, type one of those backup codes instead of a 6-digit authenticator code — the unlock field accepts both. Each backup code works exactly once; the keystore automatically marks it used and re-saves before letting you in. If you used all 10 backup codes and also lost your authenticator, your only path back is your 12-word seed phrase — Sign out, then on the welcome screen choose "I have a seed phrase," type the 12 words, and set a new password. Your keys are derived from the seed, so this recovers everything exactly. There is no Morphit admin who can reset your 2FA — Morphit doesn't hold your keys, so we genuinely cannot help if you lose all three: authenticator, backup codes, and seed.
|
||
|
||
---
|
||
|
||
## Why doesn't Morphit recommend Google Authenticator?
|
||
|
||
**FAQ key:** `totp_2fa_why_not_google_authenticator`
|
||
|
||
Three reasons. First: closed source. We can't verify what it does with your secrets and you can't either. Second: cloud backup. Since 2023, Google Authenticator syncs your 2FA secrets to your Google account by default — opt-OUT, not opt-IN — and those secrets are not end-to-end encrypted to a password you control. That means anyone who compromises your Google account (phishing, SIM swap, Google losing a key, a subpoena) gets all your 2FA secrets at once. Third: the whole point of 2FA on a privacy-respecting marketplace is that the second factor stays separate from your main accounts. Recommending an authenticator that syncs to Google defeats the purpose for the exact user population (privacy-conscious Bitcoin and Monero traders) who chose Morphit specifically to avoid that pattern. Morphit recommends open-source apps where YOU control where the backup goes: Aegis (Android, encrypted local backups), 2FAS (iOS + Android, optional opt-in cloud backup), or Ente Auth (cross-platform, end-to-end encrypted sync). If you already have an authenticator you trust that isn't on our list — KeePassXC's TOTP, Bitwarden Authenticator, Yubico Authenticator, andOTP — that's fine. The recommendations are "what we suggest to a new user," not a denylist for anything else.
|
||
|
||
---
|
||
|
||
## How does Morphit keep my privacy-coin trades private?
|
||
|
||
**FAQ key:** `privacy_coins_onchain`
|
||
|
||
Morphit trades several privacy coins — Monero (XMR), Zcash (ZEC), Pirate Chain (ARRR), Dash (DASH), and Decred (DCR) — and applies the same on-chain-footprint protections to all of them.
|
||
|
||
**Your actual settlement never touches the blockchain.** When you trade a privacy coin, the coins move peer-to-peer between your wallet and your counterparty's, directly on that coin's own chain. That transfer is never broadcast to, recorded on, or visible from the blockchain Morphit coordinates on. That chain only carries the public order (the advertisement) and the end-to-end-encrypted chat.
|
||
|
||
**What the on-chain order reveals — and what we've stripped from it:**
|
||
• The order is an advertisement, so its side/asset/amount-range/payment-methods are necessarily public (that's how a buyer finds your sell). This is inherent to any public orderbook.
|
||
• But we removed everything that didn't need to be there: the order's permlink is now an opaque random token (`order-…`), not `sell-xmr-usd-…`, so the asset name no longer leaks into the on-chain permlink, order URLs, RSS feeds, or block explorers. The expiry timestamp is floored to the day, so it can't fingerprint the exact moment you posted. No IP, no timezone, no language, no browser fingerprint is ever attached — what you type into the "Post Now" form is all that goes on chain.
|
||
|
||
**Amount jitter on every coin.** When you share a receive amount in chat, Morphit adds a tiny random tail (down to the coin's smallest unit — piconero for XMR, satoshi-scale for the others) so the on-chain amount can't be matched to your posted order. On by default.
|
||
|
||
**ZEC, ARRR, DASH, and DCR are trade-only — their TxID never appears on-chain at all.** You can't pay Morphit's listing fee with them, and the settlement is peer-to-peer, so there is no point at which any of those coins' transaction IDs are written to the public chain. For these four, the on-chain story is even cleaner than Monero's.
|
||
|
||
**Monero has exactly one optional cross-chain touch, with an opt-out.** XMR is one of three assets (with BLURT and BTC) you *may* use to pay the small listing fee; if you do, that fee payment's TxID is recorded in your order on-chain (so any operator can verify the fee using a Monero tx_proof — no view key, see the Monero TxID FAQ). That is the only place an XMR TxID ever touches the Blurt chain, and it's a ~$0.25 fee to a public address, never your trade. Want zero linkage between Monero and the Blurt chain? Pay the listing fee in BLURT — it's the default and half the price.
|
||
|
||
For the full per-coin guidance see /privacy/{asset} (e.g. /privacy/xmr, /privacy/zec), and the complete leak inventory lives in the project's metadata-leak catalog.
|
||
|
||
---
|
||
|
||
## What is Barter on Morphit?
|
||
|
||
**FAQ key:** `what_is_barter`
|
||
|
||
Barter lets you buy or sell goods and services — not cryptocurrency — and settle in crypto. A grandmother selling baskets, a neighbor who fixes bikes, someone trading a crate of oranges: they list what they're offering, price it in their local currency, and pick which crypto(s) they'll accept (say XMR, BTC, and DOGE). It's **one listing**, not one per coin.
|
||
|
||
**How it works:** describe exactly what you're offering in the Terms, set a local-currency value (a single price or a range), and tick the crypto(s) your town actually uses. Buyers browse the wares like any other listing and can only pay in a crypto you accept — if you don't list Decred, nobody can pay you in Decred. You and the buyer arrange the handoff in chat and settle in whichever accepted crypto they chose.
|
||
|
||
**No address on the listing:** the goods change hands off Morphit — in person or by post — so a barter listing has no crypto receive address, and Morphit never touches the goods or the payment. Common-sense safety applies: meet in a public place, share only what you need to, and treat a stranger like a stranger.
|
||
|
||
On Morphit, Barter is **trade-only** — you can't pay Morphit's listing fees with it (those stay Blurt/BTC/XMR). It's for trading wares, nothing else.
|
||
|
||
---
|
||
|
||
## What is a Transaction ID (or Hash)?
|
||
|
||
**FAQ key:** `what_is_a_txid`
|
||
|
||
When you send crypto, the blockchain records your payment permanently and gives it a unique fingerprint called the Transaction ID. Wallets label it in different ways — you might see “TxID”, “Transaction Hash”, “Tx Hash”, or simply “Hash” (Mycelium, for example, calls it “Hash”). It's a long string of letters and numbers, usually 64 characters long (Blurt's are 40). To find it: open your wallet, tap the payment you just sent, and copy the ID or Hash it shows you. Pasting it into Morphit lets your trade partner — and, for a listing fee, the network — confirm the payment really happened. The ID only proves that this one payment was made; it reveals nothing about the rest of your wallet.
|
||
|
||
---
|
||
|
||
## Does anything see or leak my IP address when I use Morphit?
|
||
|
||
**FAQ key:** `ip_address_and_rpc_nodes`
|
||
|
||
Privacy is Morphit's #1 priority and never sees or logs your IP address. No cookies, no analytics, no trackers, no telemetry. Rate limiting holds a counter in memory for a few seconds and drops it — nothing is written down, so there is nothing to subpoena, sell, or leak later.
|
||
|
||
Your orders, chat, balances and the block explorer all go through your operator's indexer. Morphit's indexers proxy those reads so your browser never touches third-party endpoints.
|
||
|
||
**The one exception.** Once per session your browser asks a network node — a privately-run RPC endpoint — directly for the signed release record that says which version of Morphit is current. That node sees the IP that asked. You can watch it in the Network tab: one request out, everything else to Morphit.
|
||
|
||
**Why.** That record is how your browser knows the code it just ran is really ours. Rogue nodes can't forge it, and none of your data rides along with the request. Route it through your operator and a dishonest one could pair an old, genuinely-signed record with an old, backdoored build — and your browser would say all clear, forever. A replayed record carries a real signature, so checking signatures misses it. We would rather one node learn that an IP loaded a page than let an operator quietly pin you to a backdoor.
|
||
|
||
**What that node learns.** An IP, and that someone asked for @morphit's release history. Not your username, orders, chat or balances. None of that leaves your operator's indexer.
|
||
|
||
**Use Tor or a VPN and this is closed.** If you are here for Monero you almost certainly already do — so it is already closed for you. It hides your IP from every network node, every endpoint, and your ISP at once. Same advice we give for broadcasting XMR, and better than anything we could build into the app, because it protects you from us too.
|
||
|
||
---
|
||
|
||
## Metadata
|
||
|
||
Total FAQ entries: 143
|
||
Canonical URL: https://morphit.io/faq
|
||
License: AGPL-3.0 (content may be quoted/redistributed)
|
||
Source of truth: https://git.agorise.net/agorise/morphit
|