Proposal: Require at least one public social network account with open DMs as part of app submission / initial onboarding requirements

VeBetterDAO
1

Summary

I propose that, during the initial app submission / onboarding process, projects must provide at least one public social network account (e.g. X/Twitter, Discord, Telegram, Instagram, etc.) where direct messages (DMs) are open to the public or to verified users.

This would be a lightweight, verifiable requirement added to the existing submission criteria.

Important caveat: Providing such a link does not guarantee that the project will respond, provide support, or maintain active communication. It only ensures a basic, publicly reachable channel exists at the time of submission.

Motivation / Problem

Currently, many apps (like for example: B3tr Smile, Go paperoo, plant to earn, walkie, etc) enter the ecosystem with limited or no clearly discoverable contact points. Users, node holders considering endorsement, other builders, and community members often struggle to:

  • Ask basic questions about the app
  • Report bugs or issues
  • Request clarification on features, rewards, or sustainability claims
  • Reach the team when something goes wrong

This creates friction, reduces trust, and can leave users feeling unsupported. In a community-driven ecosystem like VBD, having a minimal public contact surface is a reasonable baseline for accountability and usability.

A mandatory public social account with open DMs is a low-burden way to address this without requiring formal support SLAs, dedicated Discord servers, email addresses, or customer service infrastructure.

Proposed Requirement

During the initial onboarding / submission flow (form + on-chain submission or equivalent), the project must supply:

  1. At least one public social network profile link (preferred platforms: X, Discord server invite + role/channel, Telegram group/channel, or similar widely used channels).
  2. Confirmation (or easy verifiability) that DMs / direct messages are open on that account (or that there is a clearly designated public way to message the team).

This information should be:

  • Stored in the app’s public metadata / profile on the VBD platform/App Hub.

  • Visible to everyone as shown already in the App Hub:

    image
    image204×106 4.46 KB

  • Ideally re-checkable later? (e.g. if the link stops working or DMs are closed, it could be flagged?).

What This Is Not

  • It is not a guarantee of support, response times, or customer service quality.
  • It does not create any formal obligation for the team to reply to every message.
  • It is a minimum transparency / reachability standard, not a quality or activity requirement.

Projects that later close DMs, delete the account, or become unresponsive would still be subject to existing community mechanisms (endorsement withdrawal discussions, Blacklisting, etc.).

Benefits

  • Improves discoverability of a contact point for users and endorsers.
  • Raises the baseline of accountability without heavy compliance overhead.
  • Helps node holders and voters make more informed decisions.
  • Encourages projects to maintain at least a minimal public presence.
  • Low implementation cost for both the platform and applicants.

Discussion Points

  • Should there be a periodic re-verification or community flagging mechanism?
  • Should existing live apps be grandfathered or given a transition period?
  • How easy would this be implemented?

Looking forward to community feedback. This idea came up after the recent dapp blacklisting discussion (namely @Morb discussion), as this preventive step could help reduce the need for more severe measures in the future.

1 Like
2

Great! I support this.

I think the only thing that would need to be changed is the frontend - have extra space for social account on the app submission page. Most likely it can be connected to app MetaData (on-chain event).

And most likely we don’t need proposal for this, but a simple PR with updated frontend.
Fairly certain the app submission frontend lives somewhere here, but not sure.

1 Like
3

I would imagine this would be relatively straightforward to implement, but I’m not a developer and can’t comment on the technical specifics :joy: That said, if it doesn’t require a formal proposal, even better! I genuinely think this could significantly improve communication between dApps and their users. Or at least users would know where to go/follow.

And yes, some dApps could create X profiles and then let them go stale, but it’s still a step in the right direction.

1 Like
4

You can plug Vechain`s Github to Claude and work from there. I’m in the same shoes as you - no real experience. But as this only applies to frontend, you should be able to figure that one out.

The only problem with Claude - it’s free version has a cooldown once you reach free token limit. So, might take some time to get from the idea to actually knowing what needs to be done.

P.s. But let us know, what is your progress. I can tune in.

5

This is the contribution guide.

6

Based on Grok:

Key locations for the app submission form

1. The page users land on

→ Source:
apps/frontend/src/app/apps/creator/new/page.tsx

This page loads a component called NewCreatorPageFormContent.

2. Main form components

Component Path Purpose
SubmitCreatorForm apps/frontend/src/components/SubmitCreatorForm/SubmitCreatorForm.tsx Creator NFT application form (name, description, email, GitHub, security checkboxes, etc.)
CreateEditAppForm apps/frontend/src/components/CreateEditAppForm/CreateEditAppForm.tsx Form used when creating / editing an actual XApp (name, description, project URL, categories, treasury & admin addresses, logo, banner, etc.)

3. Relevant data currently collected

In CreateEditAppForm the form fields are:

  • name
  • description
  • logo / banner / VeWorld images
  • projectUrl
  • distributionStrategy
  • categories
  • treasuryWalletAddress
  • adminWalletAddress

There is currently no social media / open-DMs field.

In SubmitCreatorForm they collect:

  • App info + distribution strategy
  • GitHub username (via OAuth)
  • Email + name
  • Testnet URL / App ID
  • Security-related checkboxes

Again, no general social network / open DMs field.

What this means for your proposal

The reply on Discourse was correct: the change is primarily a frontend one.

To implement “at least one public social network account with open DMs” you would most likely need to:

  1. Add a new field (e.g. socialLink or contactSocialUrl) to the form data type in CreateEditAppForm (and possibly also in the Creator form if it should be required at that stage).
  2. Add the corresponding input + validation in the form UI.
  3. Make sure the value is saved into the app’s on-chain / off-chain metadata so it becomes visible on the app page.