For the complete documentation index, see llms.txt. This page is also available as Markdown.

Feedback

For suggestions, usability issues, and general comments — not urgent support requests.

Feedback is the channel for product input that's not actively blocking you. Suggestions, friction reports, feature requests, and general comments all belong here. If a bug is breaking your account right now, see Report a Bug. If you need direct support, see Support Contacts.

What to Include

A useful feedback submission usually answers four questions:

  • Where? The page or feature you're referring to.

  • What did you expect? The behaviour you anticipated.

  • What felt off? What was confusing, missing, or slow.

  • What were you using? Device, browser, and (when relevant) wallet / token context.

Don't worry about length — a clear description of the problem or suggestion is usually enough. Screenshots help, but a precise sentence often beats a screenshot without context.

Feature Requests

For feature requests, the team can act faster when you describe the workflow, not just the missing button:

  • The workflow you're trying to improve.

  • Where the feature should appear in the terminal.

  • What action the user should be able to take.

  • Why the current flow isn't enough.

Frame it as a use-case, not a wishlist item — "I tried to do X and got blocked at Y" beats "please add X".

General Comments

Feedback also covers broader topics:

  • Product direction.

  • Documentation gaps or improvements.

  • Usability and accessibility observations.

  • Comparative perspective ("here's how another product handles this").

These help the team understand user needs, but submitting feedback doesn't mean the change will be built or prioritized. Treat it as input, not commitment.

What Not to Include

  • Seed phrases / private keys. Ever. For any reason.

  • Wallet passwords or one-time codes.

  • Sensitive personal data that isn't necessary to understand the request.

If a request genuinely requires wallet context, share the public wallet address — never the secrets that control it.

More to Explore

Cover

For things actively blocking you.

Cover

The right channel for direct help.

Cover

The overview of every help-side option.

Feedback shapes future product work — but for time-sensitive issues, use the bug-report or support channels instead.

FAQs

Will I get a response to my feedback?

Feedback is read by the team but doesn't always receive an individual reply. For issues that require a direct response, use [Support Contacts](support-contacts.md).

How long until a feature I requested is built?

There's no SLA on feature requests. Product roadmap decisions weigh many factors; a single request rarely jumps the queue, but consistent feedback patterns inform priorities over time.

Can I share feedback anonymously?

Depends on the current feedback channel. If anonymity matters, check the form options before submitting.

What's the difference between Feedback and Report a Bug?

Bugs are things broken now — wrong behaviour, errors, blocking issues. Feedback is everything else — suggestions, friction, requests, general comments.

Should I share a screenshot?

Helpful when the issue is visual or when text alone can't describe the layout. Strip any sensitive details (wallet addresses, balances) before sharing if they aren't relevant.

Last updated