DApps & ecosystem
A curated, operator-managed directory that makes partner applications and DeFi services reachable from the community, with member approval for every data request.
The DApps module adds an ecosystem surface to the community app: a curated directory of partner applications and services that members can browse, save and open. Listings, categories, network filters, allowlists and partner configuration are managed by the operator on the directory-service component.
The directory and its operator console run today in the reference deployment. Per-request member approval for partner data access and the manifest-level allowlist are part of the module design and in developer preview.
Capabilities
| Capability | Status | Notes |
|---|---|---|
| Curated directory | Available | Featured listings, categories, network filters, search |
| Saved and recently visited | Available | Per member, in the member's account |
| Partner listings | Available | Name, description, logo, supported networks, community and support links |
| External destination policy | Available | Operator switch for opening external URLs, with revision history, audit and rollback |
| Risk confirmation | Available | Members confirm before leaving for a partner destination |
| In-app DApp browser | Available | Partner apps open inside the community app |
| Member approval per data request | Preview | Partners receive no member data without approval |
| Manifest allowlist | Preview | allowlist |
Configuration
{
"modules": {
"dapps": {
"enabled": true,
"directory": true,
"allowlist": ["https://app.partner.example"]
}
}
}Prop
Type
Managing the directory
Listings are operator content, managed in the admin console rather than in the manifest, so they can change without a new build:
- Listings — name and description per language, logo and hero image, destination URL, supported networks, categories, and community and support links.
- Categories and networks — the filters members see.
- Banners — featured placements on the directory home.
- External destination policy — whether listings may open external URLs. Every change records the operator, the before and after values and a revision; a stale revision is rejected rather than overwriting someone else's edit, and any revision can be rolled back.
Partner access to member data
In the module design, partner apps run in the in-app browser, isolated from the community app's own session, and reach member data only through an approval flow:
- A partner app that needs member data — an identity, a wallet address, a signature — makes a request through the app's bridge.
- The app shows the member exactly what is requested and by whom.
- Only an approved request is fulfilled, and only with the data it named. Every request is approved separately; approvals are not standing permissions.
- Signing and payment requests are handled by the wallet module and use its confirmation rules.
Without the wallet module, signing and payment requests are rejected, and validation reports dapps.no-wallet.
Events
Preview webhook events.
| Event | Fired when | Key fields |
|---|---|---|
dapps.listing.published | A listing becomes visible | listingId, categories |
dapps.listing.unpublished | A listing is withdrawn | listingId |
dapps.request.approved | A member approves a partner request | listingId, requestType |
dapps.request.denied | A member denies a partner request | listingId, requestType |
Request events identify the partner and the type of request. They never include the data released.
Privacy scope
Partner apps receive no member data unless the member approves each request.
Shared services and metering
The DApps module uses no shared services and has no metered units.
Limits
| Field | Bound |
|---|---|
allowlist entries | Valid URLs |