> For the complete documentation index, see [llms.txt](https://graphdex-1.gitbook.io/graphdex-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://graphdex-1.gitbook.io/graphdex-docs/help-and-feedback/feedback.md).

# 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](/graphdex-docs/help-and-feedback/report-a-bug.md). If you need direct support, see [Support Contacts](/graphdex-docs/help-and-feedback/support-contacts.md).

{% hint style="success" %}
**Short and specific beats long and vague**

The team reads everything; a focused 3-sentence note travels further than a 3-paragraph ramble.
{% endhint %}

## 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

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-cover data-type="image">Cover image</th></tr></thead><tbody><tr><td><a href="/pages/YZmAxluf5b4TsOcmr0o0"><strong>Report a Bug</strong></a></td><td>For things actively blocking you.</td><td><a href="/files/PvwZariSc5lrxmA3uidW">/files/PvwZariSc5lrxmA3uidW</a></td></tr><tr><td><a href="/pages/zVHQSJGOhNXlOmHc6rdt"><strong>Support Contacts</strong></a></td><td>The right channel for direct help.</td><td><a href="/files/PvwZariSc5lrxmA3uidW">/files/PvwZariSc5lrxmA3uidW</a></td></tr><tr><td><a href="/pages/kGGY16v3DG6hCVobbNZN"><strong>Help Center</strong></a></td><td>The overview of every help-side option.</td><td><a href="/files/PvwZariSc5lrxmA3uidW">/files/PvwZariSc5lrxmA3uidW</a></td></tr></tbody></table>

{% hint style="info" %}
Feedback shapes future product work — but for time-sensitive issues, use the bug-report or support channels instead.
{% endhint %}

## FAQs

<details>

<summary>Will I get a response to my feedback?</summary>

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).

</details>

<details>

<summary>How long until a feature I requested is built?</summary>

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.

</details>

<details>

<summary>Can I share feedback anonymously?</summary>

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

</details>

<details>

<summary>What's the difference between Feedback and Report a Bug?</summary>

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

</details>

<details>

<summary>Should I share a screenshot?</summary>

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.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://graphdex-1.gitbook.io/graphdex-docs/help-and-feedback/feedback.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.