UX

AutoModerator

Post is by: ApplicationNew4144 and the url/text [ ](https://goo.gl/GP6ppk)is: /r/CryptoMarkets/comments/1uhbhco/cross_margin_is_how_a_15_btc_wick_cost_me_the/ I got liquidated on June 4 even though my biggest position was a BTC long at 3x. Not because BTC moved too much, but because I had SOL and AVAX perps open on the same account and cross margin meant they all shared one collateral pool. When the wick hit, alts dumped harder than BTC, and the combined drawdown pulled the whole account below maintenance. The BTC position on its own would have survived easily. A 3x long does not liquidate on a 15% move. That is the part that still annoys me. Cross margin felt safer on paper because unused margin backs every position, but what it really does is let your weakest trade kill the rest. I started checking how different platforms handle the isolated vs cross choice. Some make you dig through settings before you can switch. BYDFi makes you pick isolated or cross per position before confirming the order. It is one extra click but it would have kept my BTC walled off from the alt liquidation. Not saying that platform is special, just that the UX choice is the kind of guardrail I wish I had hit. Now I open everything isolated with individual stops. If one trade blows up it takes only that collateral. Cross still makes sense if you are hedging the same pair or running a tight arb, but I will not run a portfolio of volatile alts on shared margin again. Learned it the expensive way. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/CryptoMarkets) if you have any questions or concerns.*

pc1e0

What I like about this cryptocurrency experiment the most is the simplicity of its UI/UX. No need to install Metamask, no need to download mining software, no need to go through KYC on CEX.

TheBitSignal

I’m tired and have a newborn. Honest mistake. While I did read it, the app UX was not the best trying to post. This was also my first ever post, so sorry for my mistake.

Sure-Benefit2023

I think the main issues are volatility, UX, taxes, and consumer protection. For normal people, paying with crypto is usually more complicated than using a card or bank app. On top of that, price swings make it awkward as a daily currency, and tax treatment can make small payments annoying. Crypto is useful in some specific cases, but “common day-to-day currency” needs boring reliability, simple recovery, low friction, and clear rules. We are not really there yet.

cryptodizzle67

Fair enough, I was thinking about someone who has never seen an exchange, so a good UX / UI would help them out with some good information / customer service.

coolfarmer

It's really just a UI/UX issue. I use a Ledger wallet, so I never see those transactions or spam tokens anyway, I only pay attention to my own holdings. They're far easier to ignore than phone scammers who keep leaving voicemails. My voicemail box only holds 3 messages, so I end up having to delete them every day....

-Baloo

Well honestly a lot of the blame lies on the core developers and incentive structure. If it was cheap and easy to use, people would use it.. but it isn't.. it's too complex and awkward for most people to engage with. Seed phrases they need to keep secure, on ramps, tax obligations etc.. The whole UI/UX experience needs to be seamless and smooth, it has to be ***better*** than what Visa or Mastercard offer - else why would consumers switch? In parts of SE Asia they already have blockchain integrated into the banking systems, and you just pay by scanning a QR code with your phone and it settles cross chain inter bank within seconds. It needs to be like that.. users shouldn't need to adapt to BTC, crypto should adapt to consumer behaviour. And yes - from a business perspective crypto rails are actually much better to use today, you get settled almost immediately. But the issue is that consumers aren't interested because the whole onboarding process is a nightmare (which does also come down to governments and existing financial players gatekeeping).

Organic_Horse88

I think it’s a mix of all of these, but the good thing is each layer is improving over time. Wallet UX is getting simpler, fees are coming down on newer networks, and merchant adoption is slowly growing too

Miltank12345

Not only centralized, but they fragment liquidity, have a horrible UX and often come with secrutiy threats due it's bridge. Layer 2s are TRASH. (And Bitcoin with it's Proof of Work Concept is Trash too)

SpendHefty6066

People are building wallets that do these with a much easier UX. Right now the protocol is still very "techy". Some may remember getting online pre web, and not AOL. Similar vibe. We are still in the "what can the Internet do that fax doesn't?" stage of Bitcoin adoption.

hyperbiznes

\[Warning\] MEXC's matching engine vs. manual orders: a cautionary tale about UI/UX traps and forced liquidations https://preview.redd.it/34dry0ja387h1.jpeg?width=1179&format=pjpg&auto=webp&s=4033770e96649ddaad476e02d59bae932226d192 I want to share a technical breakdown of my recent experience with MEXC. This isn't just about a lost position; it’s about a fundamental issue in how the platform's UI interacts with their liquidation engine. The Situation: I held a Long position on ESPORTS/USDT. As the price approached the liquidation threshold, I attempted to exit the position manually using market orders. The Timeline (UTC+2):  13:52:37: 1st attempt to close (Rejected: "Price close to liquidation")  13:52:41: 2nd attempt to close (Rejected: "Price close to liquidation")  13:52:45: 3rd attempt to close (Rejected: "Price close to liquidation")  13:52:46: Forced liquidation by the system. The Technical Issue: After escalating the case with support, they confirmed that my manual orders were rejected because the market price was below the liquidation threshold. Why this is a trap for traders: 1. UI Misleading: The platform's interface allowed me to place market orders, creating the illusion that manual control was still possible, even though the backend engine had already effectively locked the position. 2. Liquidation Priority: The system ignored 3 manual exit attempts over a 10-second window, prioritizing the liquidation engine over user input. 3. "Fair Price" Logic: Support claims this is a "protective measure." My argument is that if an order cannot be executed due to system constraints, the UI should prevent the order from being placed in the first place, rather than allowing users to "waste" precious seconds trying to exit. The Official Response: MEXC support explicitly stated that the cancellation of orders was not a platform anomaly but a "protective measure" during volatility. They refused any compensation, effectively admitting that their UI allows interactions that the engine has already blocked. Key Takeaway: If you trade on MEXC, be aware that during high volatility, their interface may lead you to believe you can still close a position when the engine has already decided to liquidate you. Your manual exit attempts are secondary to their liquidation engine. I’m sharing this so others don't get trapped by the same system behavior.

Ge_Yo

UX is probably one of the biggest barriers to adoption. A lot of these ideas only matter if normal people can actually use them without needing to be experts. The more seamless Bitcoin-based services become, the more interesting the long-term picture gets. TBVs are a good example of that, since accessibility can be just as important as the use case itself.

Blackiris-Code

The things is, ETH and SOL already have solutions for quantum security. Afaik the devs are now trying to figure out the optimal balance between impact on network performance and smoothness of the transition (compatibility with old protocols notably). But it is not a priority at all. It's very unlikely that we start to see a shadow of a real threat within the next 5 years. Improving the UX and increasing adoption is much more urgent because being the first on a market gives a huge advantage. So refining existing protocols, developing dApps, finding TradFi partners... those things are put before optimizing quantum security implementation. But it will happen in time for sure. So for the networks that already have quantum security, the question is: What is their advantage compared to other major chains that already figured out a solution? If a network can't bring something more than quantum security I'm 99% sure that it will disappear in a bear market in the 2040s. I will be shorting the coins of those networks very aggressively.

Equivalent_Menu_1096

Hyperliquid getting that kind of mainstream recognition is wild but honestly not surprising. Their perp DEX UX is genuinely better than most CEXs I've used, which is rare in DeFi. Still, these lists always feel like paid placement or hype timing—curious if anyone here actually uses their platform regularly or if it's just the *idea* of it that’s getting the nod. The real test will be how they handle a major drawdown event, not just a bull run.

osem23

Thank you, this is a very fair and useful read of the model. Yes, the key idea is exactly that: the native-language layer is display/input only, while the English BIP39 mnemonic remains the canonical seed input to PBKDF2. The goal is to improve comprehension without adding a new cryptographic path. I agree that the main risk is UX confusion. A wallet implementing this must make the distinction very clear: the native words help the user understand and enter the backup, but the English BIP39 phrase is the portable fallback for recovery in standard wallets. On wordlist quality, I agree as well. Even though these are not standalone BIP39 replacement lists, confusion risk still matters. Near-homophones, spelling ambiguity, diacritics, regional meanings, and memory collisions all need language-level review. That is part of why the project is public. The native-speaker review point is also valid. Some languages are already reviewed more deeply than others, but broader review is needed before treating every list as equally mature. And I agree on the adoption path. A reference library is probably the right next step, especially something wallet developers can integrate without maintaining the mappings themselves. Appreciate the thoughtful feedback. This is the kind of criticism that is actually useful for making the project safer and easier to implement.

whatwilly0ubuild

The approach is sound. Display-layer translation with English as the canonical seed input to PBKDF2 means you're not introducing new cryptographic surface area. The index-pairing keeps the mapping deterministic and reversible. A few considerations from the implementation and adoption side: The UX risk is users not understanding the distinction. If someone backs up their native-language phrase and later imports it into a wallet that only accepts English BIP-39, they may think their funds are lost. The display layer needs extremely clear messaging that the English phrase is the portable standard and the native display is wallet-specific. Documentation alone won't prevent this confusion at scale. Wordlist quality matters more than it seems. BIP-39's English wordlist was carefully constructed to avoid similar words, minimize prefix collisions (first 4 characters are unique), and exclude offensive terms. Do your translated lists maintain similar properties? A wordlist where two words differ by only a diacritical mark, or where words are near-homophones, creates backup error risk that doesn't exist in English. The 31 languages without native-speaker review is a liability. Machine translation or non-fluent selection can produce words with unintended meanings, regional ambiguity, or cultural problems. The request for native-speaker corrections is the right call, but wallets adopting this before thorough review would be taking on risk. Adoption path is the harder problem. This only helps users if wallets implement it. Most wallet developers won't add 31 language mappings for a feature that serves UX rather than functionality. A reference implementation as a library (JS, Rust) that wallets can drop in would lower the barrier significantly.

M4cHiin360

Damn so fiat with extra step and worse UX. Generational tech

osem23

I understand your position, but you are still criticizing a different model. I am not saying the English BIP39 wordlist is more authoritative than the other BIP39 wordlists. I am saying that in this implementation, English is the chosen compatibility base layer. That is an engineering and UX decision, not a claim that English is “better” or more valid than Spanish, Korean, Japanese, or any other canonical BIP39 list. If a wallet creates a Spanish BIP39 wallet from the start, then the Spanish BIP39 mnemonic is the source of truth for that wallet. Same for Korean, Japanese, French, etc. But this project is addressing a different case: A wallet that intentionally uses English BIP39 as its portable recovery base, while giving non-English users a native-language display/input layer so they can understand what they are backing up. Creating new canonical BIP39 wordlists for additional languages is a valid path, but it is not the same problem. A new canonical BIP39 wordlist creates an independent mnemonic system for that language. This project creates a semantic layer over an English BIP39 mnemonic, so the user can understand the backup while still keeping the standard English recovery fallback. Those are different goals. You are arguing that native users should use native canonical BIP39 lists where they exist, and I agree. But that does not invalidate an application-layer model where a wallet chooses English BIP39 for portability and adds native-language comprehension on top. So the distinction is simple: Canonical native BIP39 wordlists are for creating native BIP39 mnemonics. This project is for displaying and entering native-language meanings over an English BIP39 recovery base. That is the model.

osem23

That is the intended model. The user is not locked into the native-language display words. They can recover in the native language inside a wallet that supports this display/input layer, and they can also recover with the canonical English BIP39 words in any standard wallet that supports English BIP39. That is the base layer. The native-language words exist to help the user understand and enter the backup in their own language. But the recovery source of truth remains the canonical English mnemonic, and the English words are always the portability fallback. So nothing is “lost” if another wallet does not support the native display layer. The user still has the English BIP39 backup path. That is the point of the model: native-language UX for understanding, English BIP39 for universal recovery compatibility.

osem23

Yes, that is closer to the intended use case. This is primarily a UX and comprehension layer for wallet software, not a proposal to replace BIP39 wordlists or create a new independent seed standard. The user can still have the English BIP39 words as the universal recovery fallback. The native-language layer helps them understand what they are backing up, instead of copying foreign words blindly. A true additional BIP39 wordlist for each language would also be valuable, but that is a different goal and a much higher standardization process. This project is focused on a more practical layer: keep English BIP39 compatibility underneath, while making backup and recovery clearer for non-English users inside wallets that choose to support it.

osem23

Specific language feedback is welcome, and that is why the lists are public. A lot of work was done to reduce issues across each language as much as possible, but no multilingual UX layer is perfect without broad native-speaker review. The important point is that this does not put the backup at risk. The recovery source of truth remains the canonical English BIP39 mnemonic. The native words are a display/input layer, not a replacement seed standard. So yes, individual words can be reviewed and improved. But that does not invalidate the model or make the recovery path unsafe.

osem23

You are mixing two different things. The recovery path has not changed. The underlying recovery path is still the standard English BIP39 mnemonic. The native-language words are only a translation/display layer that maps back to the same canonical English BIP39 words before recovery. A user can back up in the native language for understanding, or back up the English BIP39 words directly. The English words remain available as the universal recovery fallback and can be restored in any standard wallet that supports English BIP39. So this is not “enter a non-standard mnemonic into a non-standard wallet” as the only recovery path. The model is: Native language for user understanding English BIP39 for universal wallet recovery Translation layer only No change to seed generation No change to PBKDF2 input No change to the actual recovery path You can disagree with the UX choice, but saying the recovery path was replaced is misleading. The whole point is to preserve the English BIP39 recovery path while making the backup understandable to users who do not speak English.

osem23

I think we are talking about two different goals. If a wallet is creating a new Spanish BIP39 wallet from scratch, then yes, the canonical Spanish BIP39 list is the right tool. But this project is not trying to create standalone Spanish BIP39 mnemonics. It is a display/input layer for wallets that intentionally keep English BIP39 as the compatibility and recovery source of truth. In that model, the native words are aliases for the English BIP39 words, not a separate mnemonic to hash. Your counterproposal also requires special wallet logic. The wallet must know not to hash the Spanish mnemonic normally, but to decode it to entropy, re-encode that entropy as English, and then hash the English mnemonic. So both models require explicit wallet behavior. The difference is UX: Your model shows a standard Spanish BIP39 mnemonic that does not semantically match the English words the wallet ultimately needs. This model shows native-language meanings that map directly to the English BIP39 words, while keeping the English mnemonic available as the recovery fallback. I am not saying this replaces canonical native BIP39 lists. It solves a different problem: making an English-BIP39-based wallet understandable for non-English users without changing its recovery path.

osem23

I understand the question, but this is exactly the issue I am trying to point out. I am not saying English is morally or linguistically superior to the other BIP39 wordlists. The reason English is used as the source of truth in this model is because the existing non-English BIP39 lists are not translations of the English list, and they are not semantically aligned with each other by index. They are independent wordlists. That means the word at index N in Spanish, Korean, Japanese, French, etc. usually does not mean the same thing as the English word at index N. So for a normal user, this creates a strange UX problem: If their wallet shows an English mnemonic and then tries to “show it in Spanish” using the canonical Spanish BIP39 list, it cannot do that. The canonical Spanish word at the same index is not the Spanish meaning of the English word. It is a different word that happens to occupy the same entropy index. That may be valid cryptographically, but it is not a translation layer. This project is trying to solve that specific gap. It keeps one canonical cryptographic floor, the standard English BIP39 mnemonic, and adds native-language display/input words that are semantically paired to that English mnemonic by index. So when the English word is “abandon”, the native display word is actually the native-language equivalent of “abandon”, not an unrelated word from an independent native BIP39 list. That matters for user understanding. The goal is not to claim that English is the only valid BIP39 list. The goal is to avoid the destructive UX mismatch where users think they are seeing a translation, but in reality they are seeing a completely different independent wordlist. If someone wants to propose new full canonical BIP39 wordlists for languages that do not have them, that is a valid path too. But that solves a different problem. This project is not trying to replace canonical native BIP39 lists. It is trying to create a clear display/input convention where the native words actually mean the same thing as the mnemonic being backed up, while keeping recovery compatible through the English BIP39 source of truth.

osem23

That is fair pushback on the framing. The UX problem is still real: many non-English users struggle with English recovery phrases. That is the problem this project is trying to address. At the same time, recovery UX touches real funds, so wording, review, and limitations matter a lot. That is not the intended model. The intended model is a native-language display/input layer that maps back to the canonical English BIP39 list, with English remaining the source of truth. We have already updated the README and documentation to make this clearer, including stronger guidance around limitations, backup format, and what these lists should not be used for. I appreciate the detailed criticism. This is exactly the kind of feedback that helps make the project safer and clearer.

osem23

I don’t think the answer is that this method is universally “better” than having a canonical BIP39 wordlist in every native language. If a language has a well-reviewed canonical BIP39 wordlist, designed with the same constraints as the original lists, supported by wallets, and accepted across the ecosystem, then that is obviously a very good solution. The problem is that most languages do not have that today. So the value of this approach is different: It gives the user native-language understanding while preserving immediate compatibility with the existing English BIP39 ecosystem. A new canonical native BIP39 list requires broad review, standardization, wallet adoption, long-term support, and user confidence that other wallets will accept it in the future. That is a much higher bar, and it is not available for most languages right now. Our approach keeps the English BIP39 mnemonic as the source of truth, but adds a native display/input layer on top of it. So the tradeoff is: Canonical native BIP39 list: cleaner if it exists and is widely adopted Native display/input layer mapped to English BIP39: more compatible today, easier to integrate in one wallet, and gives non-English users a way to understand what they are backing up without leaving the existing English BIP39 recovery path That is the point. I am not saying this replaces the need for proper native BIP39 wordlists. I am saying it can help users now, especially in wallets that want to preserve English BIP39 compatibility while improving recovery UX for people who do not understand English.

osem23

Yes, exactly. That is very close to the intended model. The native-language words are meant to help the user understand and confidently record the backup, but the English BIP39 words should remain available as the universal recovery fallback. A good wallet UX could show both side by side during backup: native word for the user’s understanding canonical English BIP39 word for compatibility That way the user gets the benefit of a recovery phrase they actually understand, while still having the English BIP39 version available if another wallet only accepts the standard English list. So the goal is not to hide the English words or create a separate recovery world. The goal is to make backup clearer for non-English users while preserving the existing recovery path. In practice, I agree that a recommended policy should probably be: if a wallet uses a native display/input layer, it should give the user the option, or maybe the default, to back up both the native word and the canonical English word together. That gives users the best of both sides: local-language understanding and standard BIP39 portability.

osem23

The value is UX and recovery confidence. For a native English speaker, the English BIP39 list feels natural, so this problem is almost invisible. But most of the world does not speak English as a native language. For many users, an English mnemonic is not really a “sentence” or even a meaningful set of words. It is a sequence of foreign symbols they are asked to copy perfectly and trust with their savings. I have worked with thousands of non-English-speaking Bitcoin users, and backup/recovery is consistently one of the hardest parts. This is where many people make mistakes, lose confidence, or fail to understand what they are actually saving. That creates real recovery risk: They may not understand what they wrote down They may confuse similar-looking English words They may make spelling mistakes They may not feel confident verifying the words later They may rely on screenshots, translation apps, or someone else for help A canonical native BIP39 wordlist would be ideal where it exists and where the user’s wallet supports it. But BIP39 only has a limited number of official wordlists. Most users do not have a canonical BIP39 list in their native language. The point of this approach is not to create a new seed scheme. It is to give users a native-language display/input layer while keeping compatibility with the existing English BIP39 standard underneath. So the wallet can say to the user: “Here are words you actually understand,” while internally preserving the same BIP39 indexes and canonical English flow. That makes backup and recovery more understandable without requiring a new cryptographic standard. For English speakers this may feel unnecessary. For non-English users, it can be the difference between copying foreign words blindly and actually understanding what they are backing up.

na3than

> The goal is to make recovery UX more understandable for non-English users while still relying on the existing English BIP39 standard underneath. Why? What's the value in presenting a non-English mnemonic to the user, then converting it to English before hashing it to create a seed? How does that "make recovery UX more understandable for non-English users" compared to presenting the non-English user a mnemonic sentence using a canonical BIP-39 word list for their native language?

osem23

I understand the concern, but I think there is an important distinction here. These lists are not intended to replace BIP39, and they are not used as independent seed wordlists. In our implementation, the canonical source of truth remains the standard English BIP39 wordlist. The wallet maps the displayed native-language words back to the canonical English BIP39 indexes before any seed operation. PBKDF2 is not run on the translated words, and the cryptographic seed flow is not changed. So the user is not creating a new German BIP39 seed based on a German replacement list. They are using a localized display/input layer that resolves back to the standard English BIP39 mnemonic. That said, your point about users shortening words to 4 characters is a valid concern in a general public-wordlist context. If someone tried to use these lists as standalone BIP39-compatible wordlists, or engraved shortened versions of the localized words on metal, that would be unsafe unless the list guarantees the same uniqueness and clarity rules. But that is not the intended use case here. The intended model is: canonical BIP39 English remains the source of truth native words are display/input aliases wallet validation resolves them back to the English BIP39 index seed generation remains unchanged no wallet should treat these as standalone BIP39 replacement lists without additional guarantees So I agree this distinction needs to be made very clearly in the README to avoid misuse. The goal is not to create new BIP39 wordlists. The goal is to make recovery UX more understandable for non-English users while still relying on the existing English BIP39 standard underneath.

osem23

Thank you, this is a very fair point. I agree that the original BIP39 wordlists were not designed as direct translations, and that their priorities around avoiding confusion, spelling ambiguity, similar-sounding words, and short-prefix uniqueness are important. To clarify my intention: I am not trying to replace the existing BIP39 lists, change the seed generation flow, or suggest that wallets should adopt this as a standard. This project is more of an open contribution / experiment for multilingual Bitcoin UX. It gives wallets and developers an additional reference if they want to explore native-language display or input layers, but there is no expectation that anyone must use it. The canonical BIP39 flow remains the source of truth. If a wallet needs strict 4-character uniqueness, metal backup compatibility, or full BIP39-style wordlist guarantees, then it should absolutely require that before using any list in production. So I agree with the concern. This repo should be understood as optional, experimental, and open for review, not as a claim that direct translations are better than the original BIP39 wordlist design principles. Appreciate the thoughtful feedback.

bitusher

Interesting... For those wondering the original BIP39 lists are here https://github.com/bitcoin/bips/tree/master/bip-0039 and list 10 different language lists The reason these lists did not use direct translations is because they prioritized - Avoiding words that are easily confused. - Avoiding words with multiple common spellings. - Avoiding words that sound nearly identical. - Ensure the first few letters uniquely identify the word. A direct translation of an English word might violate those rules in the target language. >We would appreciate review, criticism, native-speaker corrections, I am just wondering why a direct translation should be prioritized over the above concerns ? Also I read this - >"4-char prefix uniqueness is not guaranteed across all scripts. Wallets relying on prefix autocomplete should fall back to full-word matching." Which IMHO should be a non starter because this is needed for most wallets and even many metal seed backups It is critical for UX that wallets can auto complete the word after 3-4 characters rather than typing in many more characters

SpendHefty6066

Sparrow and Electrum are both solid wallets. Sparrow has one less dependency when connecting to your node than Electrum, and Electrum has a great UX (Sparrow's is not bad). Both are open source and have lots of eyeballs on them. Both are Bitcoin only which is a hard requirement. To OP, I recommend downloading either of these wallets and learn the ins and outs. When you move a nominally small amount of sats to it, burn a few sats in transaction fees just sending and receiving to addresses in your wallet. Get your seed phrase written down and then do this: uninstall your wallet software and delete it completely. Then restart your computer. Re-install Sparrow or Electrum and recover your funds from your seed phrase. Learn the core truth that your Bitcoin is **\*\*not\*\*** in your wallet or your signing device. Your Bitcoin is on the blockchain and your seed phrase are the keys that grant you access to them. This truth needs to be deeply embedded in your brain so that you know that if you lose your signing device, you have not lost your Bitcoin. But if you lose your seed phrase, or someone else gets them, then your Bitcoin is gone. Bitcoin is a sovereign bearer asset. The keys are the what needs to be protected. Chiseled into steel and stored safely. Sovereign bearer assets come with responsibility.

Difficult-Repair1295

I like the UX on River more. It feels more like brokerage account. Both are good if setup recurring buys.

MinimalGravitas

Why the random capitalization? The fragmentation and UX are being solved through interoperability, ultimately users won't need to know which rollup their assets are on or where the assets they want are... it will all just be abstracted away as the Ethereum Economic Zone. > security threats through it's bridging nature, If you use the rollup's native bridge there is no security threat. If you chose to use a non-native bridge then you are trading security for speed of transfer, if you are concerned more about security then just don't make that trade-off. > It was never meant as a solution, only as a short term workaround. Rollups like Deutsche Bank's and Sony's are the solution for entities wanting to build in the Ethereum ecosystem but retain the ability to enforce rules which don't exist on the L1. A bank in Germany and a bank in Singapore are likely to operate under different legislative frameworks. L2s allow different regulations to be in place while still allowing interoperability.

Miltank12345

Dude, The Layer 2 concept is a FAILURE. It was never meant as a solution, only as a short term workaround. It comes with trade-offs like fragmentation, security threats through it's bridging nature, decentralization and a HORRIBLE UX.

Top_Performance_732

It's not as decentralized as you think. And if that's your concern with base, then why settle for Solana? Ethereum is far more decentralized, and despite being slow and expensive it still has UX advantages with rabby and debank, jump is trash in comparison. And have you ever used solscan? It's horrific

osrsbtcandporn420

I'm talking about next to "daily profit" you can't click on that to sort by top/bottom. The site feels like a scam anyway. I wouldn't recommend it. Enjoy your free UX advice, referral pajeet.

Last_Meat3940

I’ll tell ChatGPT to teach you how to read column headers. 'Price' sorting is already right there on the right. 🙃 Taking UX advice from a guy named osrsbtcandporn420 wasn't on my bingo card today. Honestly I’ll take the 'ai crap' comment as a compliment on the UI design.

absurdcriminality

Yeah. The point about crypto products being built for crypto-native users first is pretty accurate. It’s just fascinating to me that the industry is over a decade old and we are still dealing with UX issues lol

FTP_FTP_

The IRS. Spending crypto isn't what most people do with crypto. The UX is fine. 

Miltank12345

The Layer 2 approach has FAILED. It fragments liquidity, has HORRIBLE UX and will always pose a securitiy threat due it's bridging nature. Development has HALTED on Layer 2 and most projects seek a reliable Layer 1

Equivalent_Menu_1096

The bridge point you mentioned deserves more attention. "Bridges that get hacked every six months" isn't just an inconvenience — it's the biggest structural weakness in the current multi-chain model. Here's why that matters for decentralization: almost every bridge in production relies on a trusted third party — a multisig, an oracle set, or a validator committee signing off on state transitions. That means any chain connected to the ecosystem through a bridge is only as decentralized as the bridge's signers. And we've seen what happens when those signers get compromised (Wormhole, Ronin, Nomad, Bybit). The key split most people miss is between: 1. Trust-based bridges (multisig + oracles) — fast UX, but you're depositing into what's effectively a multisig wallet on the source chain and trusting operators to unlock on the destination. That's custodianship with extra steps. 2. Trust-minimized approaches like atomic swaps via HTLC — slower, more limited, but no intermediary can steal your funds by design. Most users don't realize that when they bridge, they're giving up the very property that makes crypto useful: sovereign control. A chain can have perfect validator distribution, but if it's connected to everything through a 3/5 multisig, the whole system inherits that weakest link. The OP is right about 90% of crypto not being truly decentralized. But even among the projects that get consensus right, most fail at the interoperability layer. And interoperability is where the real value lives.

Crypto_future_V

Coldcard MK5 UX upgrades looking clean as hell Coinkite keeps delivering for serious bitcoiners

Large-Cress900

really appreciate the kind words! and yeah the limitations section deserved more space, you're right. the scanning latency on slow connections is a real UX problem that i kind of glossed over. super curious about your solution tho, please do share when you publish. the scanning bottleneck is imo the main thing holding back adoption rn, if someone cracks that elegantly its a big deal

crooks4hire

The damn keyboard doesn’t even look straightforward; how are we supposed to believe the UX is any different?

Beneficial_Crab6954

Great breakdown of MEV/privacy spectrum. The real shift is execution layer abstraction + intent-based trading. Biggest gap remains UX + institutional-grade compliance rails for mainstream adoption of these solutions today

Admirable_Fan_9530

Solid breakdown, MEV is basically an invisible tax most retail users never price in. The real takeaway is there’s no single “privacy fix,” just tradeoffs between trust, UX, and security. Most people will likely default to private RPCs or intent-based systems, while full zk or enclave solutions stay niche but powerful.

joos_hubert

The useful part of borrowing against BTC is that it gives you another option besides sell or do nothing. The dangerous part is that it can make leverage feel like normal wallet UX. I would separate two use cases. Borrowing a small amount for liquidity, with a low LTV and a clear repay plan, is one thing. Borrowing because it feels like free optionality is a different trade. The second one quietly turns into a leveraged BTC position. For any BTC-backed loan I would compare custody, liquidation price, how fast you can add collateral, whether collateral can be rehypothecated, and what happens if withdrawals or banking rails get messy. Liquidium is one Bitcoin-backed lending option I would put in that comparison set, but the same questions matter everywhere. If the loan still looks sensible after you model a nasty drawdown and a boring sideways market, then it is probably a real liquidity tool instead of just a bull-market habit.

50sat

Wow thanks for this. I already reported to blockaind and solidus(tokensniffer back end) but haven't take rugcheck seriously. Go plus dropped off after a blockaid resolution before and I've assumed they were primarily feeders. >From outside, there's no way to know which. Yeah I'm not stressing that. I mean things in the market came to a particular point, I felt pressed to try some ideas I had been kicking around regarding V3 LPs. Several similar (slightly variant) tokens in overlapping times with counter-liquidity moving around between. NGL I think one team had too much and triggered some reporting channel tbh. Solidus reporting every token I made since Base launch with "serial rug pull" etc... So I could be pattern matched, activity threshold trigger, or manually reported then profiled from the address side. As far as other triggers I haven't tried to evade anything. Same IPFS workspace for remix deploys. Same Rabby wallet, etc... I"m not bothered about the token scanner sites TBH. These guys with trusted APIs keep me off of the paymaster, transaction bundlers, and other defi constructs that make much of the volume in defi and don't otherwise care about anything past the current block. MEV bots, etcetera are my usual audience and I clean up after myself. There's enough flags I'm not even worried about the initial trigger, I just need to know what services have clout from the commercial API side. I honestly don't care about UX and 'sniffer ratings' as many of these tokens I'd rather no human buy. I told Solidus which tokens I cared about, and had locks. They removed those tags. Blockaid too. New token though? Tagged immediately.

AutoModerator

Post is by: rbhexvin and the url/text [ ](https://goo.gl/GP6ppk)is: /r/CryptoMarkets/comments/1tqg50a/are_ainative_trading_terminals_the_future_of/ I’ve been thinking about how quickly trading interfaces are evolving, especially with the rise of AI agents and “terminal-style” tools that try to combine research, execution, and monitoring into one workflow. In traditional crypto trading, we already see a split between research tools (charts, news feeds, sentiment trackers) and execution platforms (exchanges, DEXs, aggregators). Prediction markets, however, feel like they could be uniquely impacted by AI-native interfaces because the core activity is already probabilistic reasoning rather than pure price speculation. In theory, an AI-native trading terminal for prediction markets could act as more than just a dashboard. It could: * Aggregate and summarize real-time narratives behind events (politics, macro, sports, on-chain events) * Highlight shifts in market sentiment across multiple markets simultaneously * Suggest correlated positions (e.g., linked outcomes across different prediction events) * Help users interpret odds movement in terms of underlying information flow rather than just price charts * Potentially automate parts of monitoring, alerting, and even execution based on user-defined strategies What’s interesting is that prediction markets already compress “information → pricing” into a single interface. Adding AI on top might compress the workflow even further: “information → interpretation → trade decision → execution.” I recently came across a tool called Rumor that’s experimenting in this direction, combining AI-driven insights with trading workflows. It made me wonder whether these systems are actually moving toward being “decision layers” rather than just trading dashboards. But I’m not sure where the real value ceiling is. On one hand, AI could genuinely help reduce noise and improve decision quality in fast-moving or narrative-driven markets. On the other hand, there’s a risk that these systems just become over-layered abstractions that still depend heavily on user judgment and don’t meaningfully improve edge. So I’m curious how others here see this evolving: Do AI-native terminals actually change the way people trade prediction markets in a meaningful way, or are they just better UI/UX layers on top of the same fundamental decision-making process we already have? And more broadly — if AI starts handling research, monitoring, and signal generation, what part of prediction market trading is still truly “human edge”? *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/CryptoMarkets) if you have any questions or concerns.*

AutoModerator

Post is by: Perfect_Watercress93 and the url/text [ ](https://goo.gl/GP6ppk)is: /r/CryptoMarkets/comments/1tqbo2m/will_ainative_interfaces_change_how_we_trade/ Hey everyone, I’ve been tracking the growth of decentralized prediction markets (PMs) over the last few cycles, and while the liquidity and volume are hitting record highs, the actual UX for trading these markets still feels incredibly archaic. Right now, if you want to trade a complex political, macro, or cultural market, your workflow looks something like this: open ten Twitter tabs, dig through news aggregators, check historical charts, manually calculate implied probabilities from the order book, and then execute. By the time you compile the data, the edge is often gone. Lately, I’ve been thinking about how AI-native trading interfaces and autonomous agents might fundamentally restructure this workflow. We've seen LLMs used for basic sentiment analysis, but a dedicated, AI-driven terminal built specifically for prediction markets could change the game in a few distinct ways: Contextual Research Automation: Instead of manually scraping discords or news feeds, an AI layer can continuously ingest global data streams, cross-reference them with specific market parameters (e.g., "Will X happen before Y date?"), and surface real-time correlation anomalies that a human trader would miss. Frictionless Execution: Imagine trading entirely through a command line or structured natural language interface where the AI interprets intent, scans available liquidity across multiple AMMs or order books, and handles the transaction layout instantly. Dynamic Risk Monitoring: Prediction markets are notoriously volatile and sensitive to breaking news. An AI agent could actively monitor your open positions against live event streams, instantly alerting you or executing defensive hedges if the underlying narrative flips on a dime. I stumbled across a project called Rumor Terminal recently that seems to be experimenting in this direction—using AI to help aggregate and parse the massive influx of information that moves these hyper-reactive markets. It made me wonder if this is where the broader space is headed. However, there’s a massive counterargument here. Prediction markets are fundamentally games of information asymmetry. If everyone starts utilizing the same core AI frameworks or LLM engines to scrape data and execute trades, won't that just hyper-efficentize the markets, compress margins, and leave retail traders at a massive disadvantage against sophisticated MEV-like AI bots? Furthermore, relying on an AI interface introduces massive risks regarding data hallucination and execution latency during breaking news events. Closing: I'm curious to get the community's take on this. Do you think AI-native interfaces are the natural evolution for high-velocity prediction market trading, or are we just adding an unnecessary layer of complexity to a game that ultimately relies on human intuition and local information? Has anyone here experimented with integrating LLMs or autonomous agents into their current PM trading setups? Let’s discuss. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/CryptoMarkets) if you have any questions or concerns.*

Next_Low4299

yeah they exist, you just have to filter scams from real platforms first. probably 80%+ of "AI crypto bot" telegram channels are pure scam. universal rule first: anyone offering you free money or guaranteed returns is running a scam. legit platforms make you do the homework. verify the team, paper trade for weeks, dig into the backtester methodology yourself. the platforms that survive scrutiny don't need to promise you anything. red flags before anything else: - asks for withdrawal-enabled API keys (always trade-only, no exceptions) - promises specific daily returns - only accessible via telegram dm - can't explain their backtester methodology - charges you upfront before paper trading quick comparison of platforms i've used or seen others succeed with: 3Commas: Oldest in the space, large userbase. Mostly rule-based bots (DCA, grid, options) with AI features on premium tiers. Custodial: connects to your exchange via trade-only API. Strong strategy marketplace. Best for copy trading proven strategies. Cryptohopper: Similar vintage to 3Commas. AI features locked behind Hero tier (~$129/mo), and even then it's mostly pattern recognition + signal integration, not frontier-LLM driven. Best for marketplace copy trading. Bitsgap: Best grid bot UX in the category. AI features minimal (signal alerts, basic prediction). Best for simple grid/DCA automation, not AI-driven decision-making. GT Protocol: Most AI-forward of the group. Hybrid trading across both CEXs (Binance, Bybit, KuCoin, MEXC, Gate.io) and DEXes (Hyperliquid for perps, PancakeSwap), so you're not locked into centralized exchanges. The GT App lets you build strategies in plain English. MCP server so you can connect Claude or ChatGPT directly to your account, the model can place trades, manage bots, or run backtests via natural-language commands. More aggressive on actual AI integration than 3Commas/Cryptohopper, which are mostly rule-based with AI bolt-ons. for a newbie: paper trade for 2-4 weeks on whichever fits before connecting real money. anything that doesn't survive paper trading isn't going to survive real capital. trade-only API keys always. if you want the most established + marketplace, 3Commas. if you want simple grid bots, Bitsgap. if you want actual AI integration with natural-language strategies and MCP, GT Protocol is the most production-ready right now. Just my 2 cents

Sufficient-Rent9886

nah you’re not overthinking it, the gap between buy and hold BTC and actually interacting with crypto infra is still huge for normal people. once you leave the exchange bubble suddenly you’re dealing with networks, confirmations, address formats, bridge risk, signing approvals, and hoping you didnt click the wrong chain by accident lol. i work in crypto all day and even i still triple check stuff before moving funds sometimes. honestly a lot of the current UX still feels like using the internet in the late 90s, powerful once you learn it, but definitely not intuitive yet for most people.

Patient_Craft2195

Holding BTC = easy. "Using" BTC = depends entirely on what you mean. Send/receive? One wallet, one address, done. Lightning? Genuinely smooth now. But wrapping/bridging/cross-chain? That's not Bitcoin being complicated — that's DeFi being a UX nightmare on every chain. Real question: what are you actually trying to *do* with it? Because half the steps you listed you probably don't need.

Bluejumprabbit

They pay in Babylon because that is the asset the program is using to bootstrap demand and pay for the security side, not because Kraken wants to make it weird. If they auto sold it into BTC for every user, somebody still eats the spread, slippage, and tax mess. Native reward token is cleaner for them but then again worse UX for you.

otetmarkets

Biggest change is access: stablecoins basically turned dollars into an API, 24/7 markets, and self custody let anyone be their own “bank” without asking permission. Next leap is making that access boring and safe: better UX, cheaper rails, and way less scam surface, not more tokens.

Jami_Martin

The UX gap is the missing piece in that argument though. Genius act and clarity act set the legal rails but if interacting with crypto still requires understanding what a seed phrase is, the cultural adoption stays slow. The infra is there, the friction isn't gone yet.

Vnogkiller

Gpt — My opinion: shielded ZEC is the superior privacy technology. Monero has historically been the superior privacy default/user-behavior system. That distinction is the whole knife edge. Zcash shielded transactions use zk-SNARKs, meaning the chain can verify a transaction is valid without exposing sender, receiver, or amount. That is a deeper privacy model than Monero’s “hide the real spend among decoys” approach. Zcash is not saying “one of these 16-ish outputs is real.” It is saying “the proof is valid, but the details are not revealed.” That is a cleaner cryptographic beast. Zcash’s Orchard protocol is the current shielded design, and Halo/Halo 2 removed the old trusted-setup problem that haunted earlier Zcash narratives. Monero’s strength is mandatory privacy by culture and protocol design: ring signatures for sender ambiguity, stealth addresses for receiver privacy, and RingCT for hidden amounts. That makes Monero very strong in practice because users are not constantly choosing between transparent and private modes. Where Monero is weaker, in my view, is that ring-signature privacy is probabilistic and decoy-dependent. The system’s privacy depends heavily on ring size, decoy selection, wallet behavior, timing, churn patterns, and statistical analysis resistance. Monero researchers themselves continue refining decoy selection because the wrong decoy distribution can leak probabilistic clues. Where Zcash is weaker is social/adoption reality. Optional privacy used to be its Achilles’ heel. Transparent ZEC damaged the narrative because people could say, fairly: “great tech, but most users are not using it privately.” That critique becomes less powerful as shielded adoption rises, but it was real for years. Recent analytics have shown meaningful growth in shielded supply and shielded usage, which is exactly the metric that matters for ZEC’s privacy set. So my ranking: Best pure privacy architecture: shielded ZEC. Best historical privacy-by-default coin: Monero. Best future-facing privacy tech: ZEC, especially if shielded-by-default wallets become normal. Best current “normie can’t accidentally use it transparently” privacy UX: Monero. My blunt thesis: Monero is a beautifully hardened privacy coin. Zcash is a more powerful cryptographic privacy platform that spent years underusing its own weapon. That is why your line works: If BTC proves digital scarcity matters, then ZEC argues private digital scarcity matters.

Cultural-Candy3219

For me it’s the weird mix of product, finance, security, and community all happening in public. A wallet UX change can teach you about key management, a bridge incident teaches market plumbing, and a governance vote can show pretty quickly whether incentives are real or just marketing. There’s a ton of noise, but the learning loop is unusually fast if you ignore the hype and watch what people actually use, what breaks, and what survives boring markets.

j4c0p

Metro.exchange is native DEX aggregator without wraps and KYC. Updated UX from Thorswap. Major cryptos can be swapped on-chain with CEX level liquidity, fees varies but its worth of nonKYC. Fuck CEX

Cultural-Candy3219

I’d separate the risks instead of putting them in one bucket. A hardware wallet mainly protects your seed and signing flow. It does not remove Lido/Rocket Pool smart contract risk, validator risk, withdrawal delays, depeg risk for a liquid staking token, or the chance that the app you use has an outage. So yes, hardware still helps, but it solves the custody part, not every staking part. A mobile wallet can be fine for small amounts, but I would not call it the same league if the amount would hurt to lose. Phones have more day-to-day attack surface: malicious apps, clipboard tricks, cloud backups, phishing screens, SIM/account recovery mess, etc. For option 2, Lido and Rocket Pool are more battle-tested and easier to research publicly. Kiln is a real staking infrastructure provider, but if you access it through a wallet integration you are also trusting that wallet UX, support path, disclosures, and withdrawal flow. I’d choose the route where you can clearly answer: who holds keys, what token do I receive, how do I exit, what fees apply, and what happens if the frontend disappears.

Neither-Respond6697

A faulty development is a workaround.  Layer 2s fragment liquidity, have horrible UX, often come with centralization and security issues due to its bridging nature. Why do I need two chains to scale if there are chains that are able to scale on its own??

SkepticalInvestor21

You're onto something here. The music industry has always been about cutting out middlemen, and streaming created new ones. Blockchain-based music rights management could genuinely disrupt how royalties flow - artists getting paid directly and transparently is a real improvement over the current opaque system. The challenge is adoption: getting listeners to interact with wallets and tokens is a UX hurdle most won't clear. The projects that crack this will probably abstract the crypto layer entirely and just have it work invisibly in the background.

jimi22

Seconding kirakirazeno's point about sports/gaming being massively underserved — that's where things get interesting. Most of the alpha right now is in niche verticals that Polymarket won't touch. A few worth looking at depending on what you're after: **Manifold** is still the best for weird/experimental stuff, community-created markets on anything. **Azuro** is doing sports at the protocol layer, more infrastructure than product. **Overtime Markets** built on top of it with a cleaner UX. **Limitless** is interesting if you want the AI-counterparty mechanic you mentioned from Prophet but more structured. The one I've been watching lately is **Hotaku** — it's specifically focused on esports (CS2, LoL, VALORANT, Dota 2,AOE2,..), non-custodial on Solana with USDC, no KYC, and instant settlement. Still early but the fact that it's targeting esports specifically rather than trying to be everything means the market quality is actually decent. They have a public API too which is a nice signal that it's built to be composable, not just a frontend. The OP's point about knowing social context being the edge resonates hard in esports — roster moves, patch notes, team meta. That's information most PM traders don't have but esports communities do.

OGMYT

If you're talking about real pump.fun volume (the kind that hits trending pages), micro-trades on the bonding curve are what work. Most retail bots overpay on fees. I've been using bot.autohustle.online for ~2 weeks, multi-wallet, decent UX.

Cultural-Candy3219

Honestly I would not try to make one app hold every job if the amounts are meaningful. Trading, borrowing, yield, and cards all create different failure modes, and bundling them together can make it harder to notice which risk you are actually taking. For me the cleaner setup is boring: one reliable exchange for fiat/spot, a separate wallet for on-chain stuff, and only a small convenience balance in any card/yield app. The all-in-one UX feels nice until support freezes something, a rate changes, or you need to unwind quickly. If you do consolidate, I would at least check withdrawal limits, card terms, loan liquidation rules, jurisdiction coverage, proof/reserves or audits, and whether yield depends on lending your assets out. The best app is probably the one where you understand exactly what can break.

OGMYT

If you're talking about real pump.fun volume (the kind that hits trending pages), micro-trades on the bonding curve are what work. Most retail bots overpay on fees. I've been using bot.autohustle.online for ~2 weeks, multi-wallet, decent UX.

OGMYT

If you're talking about real pump.fun volume (the kind that hits trending pages), micro-trades on the bonding curve are what work. Most retail bots overpay on fees. I've been using bot.autohustle.online for ~2 weeks, multi-wallet, decent UX.

Jami_Martin

The UX angle is actually the right bet - most people who gave up on bitcoin did it because of complexity, not price. Text-based interface removes the biggest berrier.

Custodyschool

Self-custody is freedom under responsibility. People will be forced into self-custody by i) research or ii) getting rugpulled by their country/government/exchange/ETF, etc. The risk actually lays within the current system. There's just a learning curve - which is worthwhile - to learn and go into self-custody. The UI/UX of self-custody tools are only going to improve. Don't get rekt because you were too lazy to learn.

FriendsMade_MeDoIt

Yeah this feels more like a “who maintains the plumbing” problem than a “DAOs are dead” problem. Most normal users probably never even think about relayers or calldata decoding until something breaks. Also kinda reminds me how dependent crypto still is on a few teams quietly keeping stuff usable in the background. The contracts stay alive, but if the UX disappears most people just stop participating because nobody wants to manually decode governance proposals before class or work lol.

Crystal_Smitha

Zengo’s MPC model also makes sense for onboarding normies because seed phrases scare the hell out of average users 😭 the whole industry is slowly realizing UX friction is a bigger adoption bottleneck than raw crypto tech

Serenity_Williamsa

ngl this is a pretty interesting signal. big fintech platforms spent years pushing pure custodial UX, and now they’re buying self custody infra instead of pretending users don’t care about owning keys anymore

Mathio_Albero

honestly inheritance is one of the weakest parts of crypto UX right now. people spend years learning cold storage opsec and zero time thinking about what happens if someone else suddenly needs to recover it 😭

OGMYT

If you're talking about real pump.fun volume (the kind that hits trending pages), micro-trades on the bonding curve are what work. Most retail bots overpay on fees. I've been using bot.autohustle.online for ~2 weeks, multi-wallet, decent UX.

suckyuhhmada

For me it comes down to three things: unbonding period, custody risk, and whether the APY is real or just inflationary token rewards. Native staking is usually the safest bet for major chains but the UX can be painful. CEX staking is more convenient but you're adding counterparty risk on top. I always check whether rewards compound automatically or need manual claiming too, since that eats into effective yield more than people realize. I've used BitMart's staking for a few mid-tier assets and the withdrawal times and rates have been pretty straightforward compared to some others.

Comfortable-Half5165

sounds like the fundamentals are working, which matters most but smoother UX, faster support, and better platform polish can really separate a decent platform from a great one 👀 if execution and withdrawals are reliable, that’s a strong base—now it’s really about improving user experience and trust long term 🚀

OGMYT

If you're talking about real pump.fun volume (the kind that hits trending pages), micro-trades on the bonding curve are what work. Most retail bots overpay on fees. I've been using bot.autohustle.online for ~2 weeks, multi-wallet, decent UX.

Astrotoad21

You can do international money transfers in seconds with very cheap fees, compared to sometimes weeks through several third parties that all take a cut by going through the ancient swift network. You have a global digital currency which could even out the differences and empower talented digital workers from countries with horrible banking systems. Decentralized finance provide all the same bank services as traditional banks, but pays back most of the profits to the users autonomously. A public ledger has lots of great uses, it provides transparency and lots of opportunities for analytics. Exchanges are open 24/7. Unfortunately, unregulated markets, bad UX and having people being responsible for their own security has led to massive market manipulations, a culture of pure speculation and gambling as well as an army of scammers, has lead to the ecosystem basically being eaten up from the inside, which is a shame, because the technology is very interesting and has plenty of noble use cases.

OGMYT

If you're talking about real pump.fun volume (the kind that hits trending pages), micro-trades on the bonding curve are what work. Most retail bots overpay on fees. I've been using bot.autohustle.online for ~2 weeks, multi-wallet, decent UX.

OGMYT

If you're talking about real pump.fun volume (the kind that hits trending pages), micro-trades on the bonding curve are what work. Most retail bots overpay on fees. I've been using bot.autohustle.online for ~2 weeks, multi-wallet, decent UX.

OGMYT

If you're talking about real pump.fun volume (the kind that hits trending pages), micro-trades on the bonding curve are what work. Most retail bots overpay on fees. I've been using bot.autohustle.online for ~2 weeks, multi-wallet, decent UX.

joos_hubert

The problem is that stablecoins are already good settlement rails, but most people do not experience life as settlement rails. They experience checkout, refunds, card holds, chargebacks, taxes, receipts, customer support, and a merchant asking whether the payment actually arrived. That last mile is where the UX gets ugly. For savings and transfers, stablecoins make obvious sense. For daily spending, the winner probably hides most of the chain details while still being honest about fees, network, asset, and reversibility. If the user has to think about bridges or gas before buying lunch, it is still too early for normal people.

Yo_soy100

Yes, they answered themselves why bitcoin is the clear winner in the article: > AI agents using bitcoin invert that logic. When autonomous agents can discover services through machine-readable APIs, negotiate terms in milliseconds, and settle payments on the Lightning Network without credit relationships or custodial accounts, the transaction costs that justified the corporation erode toward zero. The coordination that once required a firm – hiring, contracting, invoicing, reconciling – becomes a market function that agents perform continuously and at near-zero cost. > > Brian Flynn’s recent essay How to Sell to Agents draws out the commercial implications. A design discipline called AX – agent experience – is emerging alongside the familiar UX (user experience) and DX (developer experience) frameworks. Where UX assumes a human browsing a website and deliberating over days, AX assumes a machine evaluating structured data and completing a transaction before a human could finish reading the product description. The businesses that thrive in agent-mediated commerce will be the ones that are machine-readable and connected to payment rails that settle without human intervention. The payment rail matters, and the BPI study provides the first empirical signal of which rail the machines prefer. > > 86 of the study’s responses point toward why this is. In unit-of-account scenarios, models independently proposed energy and compute units like kilowatt-hours or GPU-hours as ways to denominate prices. Every one of these responses appeared in pricing and benchmarking scenarios, never in store-of-value or payment contexts. The models were reasoning about what makes a good measuring stick for economic value, and they gravitated toward the scarce inputs their own operations depend on: energy and compute. Bitcoin’s production cost is denominated in energy and its scarcity is enforced by computational proof.

DwightsShirtGuy

Nice chatGPT write up! If you did any research at all you’d know that active trading across the board in all investments is less effective than buy and hold. No AI or UX required.

Crystal_Smitha

the gas abstraction part is probably underrated too. normies do not want to think about keeping random native tokens just to send stablecoins. wallets like gem wallet already improved UX a lot, but if tether solves this at massive scale it could seriously accelerate stablecoin adoption outside crypto-native users

Matthews_Allestra

yeah this feels way bigger than “just another wallet.” tether moving from backend liquidity rail into direct consumer UX is basically vertical stack expansion. stablecoin issuer + wallet + payments is a very powerful combo

Serenity_Williamsa

crypto inheritance UX is still primitive tbh. the industry solved self custody for individuals way faster than it solved continuity for families, heirs, or non technical partners under real world conditions

binary_quasar

Wow thank you for building a tool that already exists in a better format with a better UX on other apps.

Jami_Martin

Rolexes tolerate friction. Groceries don't. The UX has to be invisible before that shift happens.

Horror_Office_5737

Honestly I think both are happening at the same time. Crypto infrastructure and tools have improved massively compared to when I first got into the space 6 years ago. But for newer users, I honestly think the overall experience can feel even more overwhelming now because there’s just so much information, terminology, chains, platforms, indicators, and noise everywhere. A lot of apps still feel like they’re designed for people already deep into trading instead of everyday users trying to learn. That’s actually one of the biggest things making me rethink UX while building FlowPulse. I don’t think the answer is hiding information — I think it’s translating complexity into something people can actually understand and act on.

Horror_Office_5737

Yeah I have actually. Coinbase was the first crypto app I ever used when I was 18, so around 6 years ago now. I think one thing they did really well was making crypto feel less intimidating for complete beginners. You could open the app and understand the basics without instantly being hit with professional trading terminology and 40 different indicators. That’s honestly part of what inspired me to think deeper about UX while building this. What I’m trying to build is kind of a middle ground: simple enough that newer users don’t instantly feel overwhelmed, but still powerful enough for more experienced users who don’t have hours every day to dig through endless market data themselves. So instead of relying purely on raw charts, the platform pulls together: - momentum signals - whale activity/context - ranked movements - market explanations - alert systems - signal history - reasoning behind why something matters The idea is that advanced users still get depth and useful intelligence, but without needing to manually piece everything together across ten different platforms. Out of curiosity though — if a newer crypto app came out that focused more on contextual signals, cleaner UX, and explaining why market movement matters instead of just throwing charts everywhere… would you personally use something like that? Really do appreciate your response to the posts too. Feedback helps a lot!

Horror_Office_5737

Exactly. That’s pretty much the conclusion I keep coming to while building FlowPulse too. A lot of crypto products almost assume the user already understands trading, market structure, indicators, and risk management before they even open the app. Most normal users just want to know what’s moving, why it matters, and what’s worth paying attention to without feeling overloaded instantly. I also genuinely want to see a new wave of everyday investors come into crypto, because right now I think a lot of beginners quit almost immediately simply because the experience feels overwhelming from day one. Not promoting anything here either, just genuinely researching how people think crypto apps should evolve because I think UX is still one of the biggest barriers to adoption.

Small_Appearance2014

facts 💯 UX looks like the issue on the surface, but infrastructure is usually the real bottleneck

tutoredstatue95

It's really just a UI/UX problem. A simple API and webpage could handle all the work and can be done in an hour or two. I'm sure there are already deployment services available. I don't think it's that much more complex than a hardware wallet or something like metamask. The biggest issue is that there is no public intuition for this stuff yet. Your typical user can barely use traditional banking apps well, so at the end of the day, almost anything touching the chain directly needs to be abstracted away and the everyday folk will have to use custody options. People are not prepared for the finality of blockchains. We live in a redo world for the most part, and the expectation of recovery will always be there.

MansionMindset

If you want useful pre-beta feedback, I would make the trust boundary painfully explicit before token mining opens. The hard part is not the halving curve. It is proving that "verified human activity" cannot quietly become a farming game or a privacy liability. The pages I would want to see before touching it: 1. What data is rewarded, what data is never rewarded, and what gets rejected. Meal photos, labs, body metrics, check-ins, etc. should each have separate anti-abuse rules. 2. What the AI can see vs what humans/admins can see. Health data plus token incentives is a sensitive combo; users need to know where review stops. 3. A simple Sybil policy. If one person uses multiple accounts, family devices, duplicate lab uploads, edited images, or borrowed photos, what happens? 4. A reward-emission stress test. Show what happens if 3k users are real, if 30% are low-quality farmers, and if growth stalls between eras. 5. A clear separation between health advice and token earning. If the app starts nudging behavior because it is reward-optimized, trust dies fast. 6. An exit/delete policy. Users should know whether deleting health data affects earned-but-unconverted balances and what remains on-chain/off-chain. The strongest version of this is not "move to earn, but with better branding." It is: useful health product first, token as an auditable contribution/reward layer second. If that distinction is obvious in the docs and beta UX, you will get much better feedback than if people have to reverse-engineer the incentives from the tokenomics page.

DecisionBubbly5623

Lightning solving settlement speed + merchants receiving USD instantly is probably the biggest missing piece for actual retail adoption. People always said “nobody spends BTC”, maybe the UX was just terrible before.

alise_mariya

If you want a non-custodial setup but still care about UX and simplicity, that’s basically why a lot of people like Solflare.

No-Masterpiece2246

The UX is just horrible, and payments fail all of the time. It can't be used for very small payments (nodes don't want it), and big payments don't work either (insufficient liquidity). In short, 7 years of wasted time and effort. Moral is: pay onchain with low fees on any other coin like LTC, BCH, DOGE, XMR, etc.