[VebetterDAO Proposal] Standard Support Ticket Protocol for all VeBetterDAO dApps

VeBetterDAO
1

Proposal: Standard Support Ticket Protocol for all VeBetterDAO dApps

Hello VeBetter members,
I am back with a proposal based on the feedback I collect every day while introducing VeBetter to people coming from web2.

Current problem

Right now, user support across dApps is a jungle:

  • some dApps offer support only via DMs on X

  • others only on Telegram

  • others use scattered and unclear channels

This creates a lot of friction for onboarding, especially for web2 users. More than once, people asked me how to get support and when they discovered that some dApps answer only on X, they told me:
“Ok never mind then, I do not use X.”

Result: they stop using the dApp.
If our goal is to grow VeBetter and make onboarding truly web2-friendly, we must provide tools that make support simple, standardized, and accessible to everyone.

Goal

Create a single standardized support system, consistent for every dApp, accessible directly inside the VeBetter ecosystem.

Proposed solution: VeBetter “Standard Support Ticket”

I propose an official web form (accessible from the VeBetter interface), available 24/7, that allows any user to open a support ticket in a simple way.

What the user must do (very simple)

The form should include these fields:

  1. Select the dApp for which the user is requesting support (dropdown menu)

  2. Describe the issue (text field)

  3. Enter the email address where the user will receive the reply

Extra key feature: user-defined Anti-Phishing ID code

To mitigate phishing risks and protect users, I also propose adding:

  1. Custom ID code (chosen by the user)

How it works:

  • the user sets a personal code/ID (a simple keyword or string, e.g. “VB-ALFA-739”)

  • when support replies by email, they must always include that code (in the subject and/or body)

  • if the user receives a “support” email without the code, they can immediately treat it as suspicious and ignore it

This is extremely simple even for web2 users and provides a concrete layer of protection against email phishing.

How it would work in practice

  • The VeBetter platform only guarantees that the form is always available 24/7

  • Each dApp provides an official support email address (e.g. support@dappname.com)

  • When the user submits a ticket:

    • the system automatically routes the request to the email address of the selected dApp

    • the request includes the user-defined Anti-Phishing ID code

    • the dApp replies to the user by email and must include that code

Important: VeBetter should not provide support on behalf of dApps. VeBetter provides the standardized infrastructure (form + routing), while each dApp handles the actual support replies.

Adoption rules (to make it effective)

To ensure this becomes a real standard and not just a nice idea, it should be mandatory:

  • Existing dApps: must adapt within a transition period by providing their official support email and adopting this standard

  • New dApps: if they do not provide the required information (support email and agreement to use the standard), they should not be approved / should not receive the Creator NFT

Main benefits

  • easier and more professional onboarding for web2 users

  • fewer users lost due to confusion or lack of clear support channels

  • one consistent support process for the entire ecosystem

  • less dependency on specific social platforms (X, Telegram, etc.)

  • reduced phishing risk thanks to the user-defined ID code

Conclusion and open discussion

This proposal is a practical foundation to make VeBetter support simpler, standardized, and safer.

This forum thread is open: any additions or improvements (for example minimum requirements for dApps, suggested response times, email templates including the ID code, attachments/screenshots handling, ticket tracking, etc.) are welcome.
I invite everyone, community members and developers, to share ideas, concerns, and practical solutions to make this proposal more complete and effective.

4 Likes
2

Robert back at it again with another great proposal.

I agree, things are far too scattered, and makes onboarding even harder. This is something that would make the user experience better in so many ways, and also improves the quality of dApps, as many dApps don’t even have support channels, or are abandoned.

As you said, fewer hoops for newbies to jump through isn’t just a nice addition, it’s a necessity.

Looking forward to seeing more discussion on this.

3

Great idea but VeBetter should only define a support standard, not act as a support provider.
Each dApp must host its own support page on its own domain.
VeBetter only supplies a mandatory template, rules, and Anti-Phishing ID standard.
All support requests and replies are handled directly by the dApp.
This avoids confusion, removes liability from VeBetter, and keeps the ecosystem decentralized.

My 2c.

2 Likes
4

Yes I agree, I think I even highlighted it by writing it :grinning_face_with_smiling_eyes:

Vebetter does not offer support but only performs the automatic sorting function, for example if I select support for greencart in the form my support request automatically goes to the greencart team

2 Likes
5

Great idea that rationalizes the need for support.

6

We need to make sure dApps are not getting spam support tickets, that overwhelm them so they cannot get to the real ones. I would propose that the support form also includes:

  • A Recaptcha to prevent Bots from filling the form
  • That users must sign a certificate from VeWorld to submit the form - this is appended to the end of the email send to dApps, so they can verify it if needed
  • Basic checking of temporary email addresses, so that disposable email addresses from the user cannot be submitted with the form

Without these a dApp can simply be hammered with fake support tickets.

7

Great suggestions, I will incorporate them into the proposal construction.

8

Proposal: Standard Support Ticket Routing Protocol for all VeBetterDAO dApps

Hello VeBetter members,
I am back with a proposal based on the feedback I collect every day while introducing VeBetter to people coming from web2.

Current problem

Right now, user support across dApps is a jungle:

  • some dApps offer support only via DMs on X

  • others only on Telegram

  • others use scattered and unclear channels

This creates friction for onboarding, especially for web2 users. More than once, people told me:
“Ok never mind then, I do not use X.”
Result: they stop using the dApp.

If our goal is to grow VeBetter and make onboarding truly web2-friendly, then support must be simple, standardized, and accessible to everyone.

Goal

Create one standardized support ticket process for the entire ecosystem, accessible inside VeBetter, while keeping responsibilities decentralized through automation.

Core principle (important)

VeBetter must NOT become a support provider or a human-managed helpdesk.

VeBetter should only provide:

  • one official standard support form available 24/7

  • automatic validation and anti-abuse checks

  • automatic routing of tickets to the correct dApp support endpoint

  • (optional) automatic ticket confirmation to the user

All real support operations (investigation, replies, resolution) remain the responsibility of each dApp team.

This avoids confusion, reduces liability, and keeps the system decentralized in practice because everything is handled by automatic processes.

Proposed solution: VeBetter Standard Support Ticket Form with automatic routing

A) One official VeBetter support form (24/7)

VeBetter provides a single support form accessible from the VeBetter interface. The experience must be consistent for all dApps and easy for web2 users.

Mandatory fields:

  1. Select the dApp (dropdown)

  2. Describe the issue (text field)

  3. User email address to receive the reply

  4. User-defined Anti-Phishing ID code (mandatory)

  5. VeWorld signature proof (mandatory, see anti-spam section)

Optional fields (phase 2):

  • wallet address auto-filled from VeWorld

  • attachments (screenshots/logs)

B) User-defined Anti-Phishing ID code (mandatory)

To mitigate phishing risks, every ticket must include a custom ID code chosen by the user.

How it works:

  • the user sets a personal code/ID (simple string, e.g. “VB-ALFA-739”)

  • the dApp must include this code in every email reply (subject and/or body)

  • if the user receives a “support” email without the code, it can be treated as suspicious and ignored

This is simple for web2 users and provides a strong extra security layer against phishing.

C) Automatic routing only (VeBetter acts as a router, not a helpdesk)

VeBetter does not read tickets and does not respond to users.
VeBetter only executes automatic processes to route the request to the correct dApp.

Routing flow:

  1. User submits the form

  2. VeBetter performs automated checks (anti-spam and validation)

  3. VeBetter forwards the ticket to the selected dApp support endpoint (email or API)

  4. VeBetter sends an automatic confirmation to the user with a ticket reference (recommended)

Then:

  • the dApp receives the ticket and handles it internally

  • the dApp replies directly to the user by email, always including the Anti-Phishing ID code

D) Each dApp defines its support endpoint

Each dApp must provide, and keep updated:

  • a support email address or a support API endpoint (helpdesk system)

  • agreement to include the user Anti-Phishing ID code in replies

  • a minimum metadata format for tickets (so routing is consistent)

VeBetter only routes based on this declared endpoint.

Mandatory anti-spam and anti-abuse protections (automatic)

We must ensure dApps cannot be flooded with fake tickets. Without protections, a dApp could be bombarded with spam and miss real requests.

VeBetter should apply these automated protections before routing:

  1. Bot protection
  • reCAPTCHA or an equivalent system
  1. VeWorld signature proof (required)

  • before submitting, the user signs a short message in VeWorld (example: "Support Ticket - - ")

  • the signature and wallet address are attached to the routed ticket

  • the dApp can verify the signature if needed

  1. Disposable email detection

  • block known temporary/disposable email domains

  • email format validation

  1. Rate limiting
  • limit tickets per wallet, per email, and per IP (example: max X tickets per day)

All of the above are automatic checks. No human review is required.

Adoption rules (to make it effective)

To ensure this becomes a real standard and not just a nice idea:

  • Existing dApps: must integrate and provide the required support endpoint within a transition period

  • New dApps: if they do not provide the required support endpoint and compliance with the standard, they should not be approved / should not receive the Creator NFT

Main benefits

  • easier and more professional onboarding for web2 users

  • fewer users lost due to confusion or lack of support access

  • one consistent support entry point for the entire ecosystem

  • less dependency on social platforms (X, Telegram, etc.)

  • reduced phishing risk thanks to the user-defined ID code

  • reduced spam risk thanks to reCAPTCHA, signature proof, disposable email checks, and rate limits

  • decentralized responsibilities: VeBetter routes automatically, dApps handle support directly

  • reduced liability and confusion for VeBetter

Conclusion and open discussion

This proposal creates a simple and standardized support entry point for users, while keeping the ecosystem decentralized through automatic routing and dApp-owned support handling.

This forum thread is open: any additions or improvements (minimum dApp requirements, suggested response times, email templates including the ID code, attachments handling, ticket tracking, etc.) are welcome.
I invite everyone, community members and developers, to share ideas, concerns, and practical solutions to make this proposal more complete and effective.

1 Like
9

I support the idea.
What happens if an existing dapp fails to provide required support endpoint within a transition period?

10

Hi Morb, thank you for your support of the idea and thank you from me for making that dapps audit public. I hope it can open the eyes of many community users (closing the off-topic here :slight_smile: )"

My proposal is the following:

For existing dapps that already have the NFT Creator status, I suggest a 10-week timeline to provide the required data:

Timeline:

  • Weeks 1-6: Dapps must submit the required data = All good

  • Weeks 7-10: If a dapp fails to submit data in the first 6 weeks, it gets frozen by the DAO without receiving any allocation but has 4 more weeks to comply

  • After week 10: Any dapp that still hasn’t provided the data gets removed from the DAO

Why removal after 10 weeks? I believe failing to provide such basic information shows disrespect to users and lack of interest in the DAO’s growth.

My thoughts: I’m open to suggestions, but honestly, providing this type of information should take maximum 2 weeks (so 10 weeks is already very generous).

11

To keep the process transparent for collecting the required data from the dApps that are already in the DAO, I would like to propose this:

  1. Could @VeChainOps provide an official contact (for example an email address) where existing dApps can send the required information, specifically the support email address that will receive the routed tickets?

  2. Also, during the 10-week transition period given to dApps to provide this information, would @VeChainOps be willing to update this thread with a public status list so everyone can track progress?

Example:

  • Mugshot: OK, information provided

  • GreenCart: OK, information provided

  • Evearn: information not provided yet

12

Your set timelines for dapps to provide this information feel reasonable. Plenty of time even if there’s a force majeure event.

But when it comes to providing support e-mail and burning creator nft, and blacklisting an app, I’d prefer if we use decentralized options.
(I apologize, I have surface level knowledge on this, so someone more proficient would need to correct/supplement me)

The event of providing a support e-mail is on-chain emitted

There’s a specific function updateAppMetadata function updateAppMetadata(bytes32 _appId, string _newMetadataURI) public which allows to change App metadata that contains information that is public on VBD apps page for each app. This function can be called by an admin wallet (it is set when an app is submitted) or a moderator wallet (can be added by an admin wallet).
I don’t fully understand how this works, but if there’s a way to add extra string in the metadata "support e-mail": "support@appname.com" this would be a more decentralized and transparent way to provide this information as the transaction is emitted on-chain and for everyone to check.

Burning Creator NFT and blacklisting an app
I’d prefer if instead of someone from Vechain had to manually check and burn creator nft and blacklist an app, it was done automatically via smart contract.
A smart contract that would be initiated during the 10 week period. After the 10 weeks, smart contract “checks“ if during that period of time an on-chain function updateAppMetadata is called by each dapp.
If no or if yes, but the metadata does not contain "support e-mail": "support@appname.com", function burn(uint256 tokenId) public and function removeXAppSubmission(bytes32 _appId) public virtual are executed.

In this way we improve decentralization (smart contracts) and increase transparency (on-chain transactions).

I feel this solution is a better fit for the decentralization, transferring the responsibility to collect data and enforce from single entity to autonomous smart contracts and protocol-level enforcement.

2 Likes