Expanding Membership Options to Subscriptions with Customisable Permissions
As Territories (writer-reader communities) grew on t2, community admins lacked a way to customise how new members can join, engage, and contribute. Originally, users had to deposit "time points" (a t2-native point system accumulated from reading and writing posts). While it fostered engagement, it also introduced friction:
1. New users had to “earn their way in,” slowing down onboarding and limiting growth.
2. Communities couldn’t monetize access, since there was no paid option available.
“Membership Roles” provide subscription-based roles with customisable permissions, such as creating content , community management and access to rewards.
Admins are now able to create various member subscription scales with custom role permissions
Key Solutions
Choosing a Membership UX
In the early stages of Membership Roles, I collaborated closely with Product and Engineering to define how memberships would work across the platform. We explored two membership models:
Users join a Territory (community) first, then apply for roles separately — similar to how Discord handles roles and permissions.
Membership comes with pre-set role permissions— a more integrated Web-3 approach
SEPARATED MEMBERSHIPS & ROLES
INTEGRATED MEMBERSHIP ROLES
(01) Separated Memberships and Roles (2) Streamlined Membership Roles
User Flow for Creating/Editing Roles, Checkout Flow, and Role-based Territory UX & Management
Balancing the New & Existing
As we introduced Membership Roles, we had to redesign around the already existing system where joining a Territory required Time Points.
Should Time Points be grouped with paid roles? Should we make paid memberships a default to drive monetization?
These questions forced us to distinguish between earned value vs. monetary value, and how different users perceive "membership."
Through user research, we found that:
Users join a Territory (community) first, then apply for roles separately — similar to how Discord handles roles and permissions.
Making monetization mandatory would alienate communities who valued experimentation or accessibility.
Thus, Time Points and USDC payments were separated to keep value types clear. Monetization is optional, empowering admins to choose what fits their community — whether free, earned through participation, or paid directly.
Giving admins flexibility to define entry requirements that fit their values
Gut Checks with Admins
We conducted usability testing with 5 Territory admins to refine Membership Roles. Key takeaways led to three major design adjustments:
Final Designs
To simplify the process of setting up Membership Roles, we designed a step-by-step tabbed structure that guided admins through role configuration—balancing flexibility with ease of use. Permissions were grouped into clear categories (Content, Moderation, Rewards), and a real-time preview helped admins understand how roles would appear to members before publishing.
Tab Step-by-step flow → Prevents confusion and ensures clarity.
Clear permission structure → Grouped into Content Creation, Management, Moderation, and Rewards.
Preview before publishing → Allows admins to see exactly what members will experience.
Diverse Territory Experience based on the user's role permission level → Gives different levels of access to community that can be earned overtime.
Measuring Impact
🎉 Generated first $10K Revenue Stream through Paid Membership Roles
Membership Roles introduced flexible role structures, allowing admins to shape their Territories based on unique needs. It was really affirming speaking to admins again, and hearing how they would actively use this feature, with setups ranging from storytelling experiments to tiered contributor access.
Jamie (t/StoryProf) used Membership Roles to create fictional characters within a shared narrative, letting members embody and contribute to a collective storytelling experiment.
Ana (t/amigos) structured roles for editors, curators, and moderators, shaping an editorial workflow for a community-run newsletter.
T/Stories with a free, t.p. and paid membership
t/Fashion with different t.p. membership roles
Live use cases for Membership Roles
Learnings & Reflections
One key learning: just because a feature is innovative doesn’t mean it’s the right first step. In hindsight, starting with a simpler fiat payment model could’ve helped us validate monetization faster and reduced onboarding friction.
This project deepened my belief in the importance of meeting users where they are. Many admins valued the flexibility to offer free, earned (Time Points), or paid access—so our design had to reflect that plurality without pushing one model over the other.
Ultimately, this experience reinforced my approach to product design: leading with clarity, listening deeply, and building systems that empower different kinds of communities to thrive on their own terms.