Transition to the On-Chain Collective: Next Steps for the Ambassador Fellowship

[Lucy]

NB: Throughout this document, the term “we” refers to the Ambassador collective as a whole. While levels of participation have varied — from those who’ve been active since January to those who haven’t engaged at all — this collective identity reflects the shared structure we’re building together. Approximately 60 Ambassadors joined this week’s calls, with many others listening to the recordings. It’s not possible to capture every individual viewpoint, especially from those who haven’t participated, but “we” is used here to represent the broader group — including those who may not have voiced their perspectives directly.

---

Current Situation
We officially wrapped up the Genesis Cycle (Establishment & Incubation Phase) of the Ambassador Fellowship on 3 May 2025 — a phase designed to explore, test, and gather input on how we work together and contribute to the Polkadot ecosystem.

We have now agreed to launch the Ascent cycle, which marks our move on-chain as a formal collective. This will be a lightweight operational phase, anchored by a single funding request: a modest allocation from the Polkadot Treasury to support coordination and continued experimentation around tooling, rewards, and recognition.

Pallet Configuration and Process Overview
The pallet from Ambassador Programme 2.0 has been reconfigured in line with the Ambassador Fellowship Manifesto.

• Lucy Coulden [Rank III Ambassador] reached out to the Ambassadors and wider community for input and guidance after being asked to lead the conclusion of the first phase, as on-chain development had not yet begun.
• Luke Schoen [Rank II Ambassador] used the manifesto to draft a detailed technical specification for the pallet configuration.
• Lucy then translated this technical spec into simplified language, as requested earlier in the year by Joe Petrowski [Rank III Technical Fellow] and Bastian Kocher [Rank VI Technical Fellow].
• Lucy engaged Anaelle, the Technical Fellowship Secretary, to discuss timelines and costs, as the community had been promised an update by 3 May. Anaelle invited Jesse Cheijieh [Rank I Technical Fellow] and Oliver Tale-Yadzi [Rank III Technical Fellow] into a working group with Lucy and Joe.
• The group agreed on the price and timeline: Jesse would handle the coding, Oliver would review, and the changes would be included in the next runtime upgrade, with an estimated timeline of six weeks.
• All technical work was completed as planned. Jesse then requested the names and verified wallet addresses of the Ambassadors to establish the on-chain collective.

At this stage, concerns were raised by an individual, prompting a temporary pause. The collective has since regrouped and agreed to open a broader discussion on the pallet configuration, aiming to reach a solution with broad agreement.

Ambassadors: Affirmed Fellowship Members
This refers to the list of Cohort I and II Ambassadors who have reaffirmed their commitment to join the initial on-chain collective. Given that further changes may arise in the coming days, we are asking all Ambassadors to complete the Google Form linked below to ensure we have the most accurate and up-to-date list.

The Ask: an open community discussion about the current on-chain pallet configuration. The Technical Fellowship has configured the previous Ambassador 2.0 pallet to align with the Ambassador Fellowship manifesto.

---

Discussed Next Steps

• 7-day community discussion begins with this Forum post on Thursday 10 July 2025 @ 0200 UTC.
• All Cohort I and II Ambassadors to complete Ambassadors: Final Commitment to the On-Chain Fellowship by the end of the community discussion period to be included in the following vote and final on-chain collective.
• 72-hour Ambassador vote on Discord to follow, covering pallet changes and onboarding plans. Voters to be all Cohort I and II Ambassadors who have completed the final commitment form.
• Pending green lights from W3F and the Technical Fellowship, the final list of ambassadors will be submitted for inclusion in the next runtime upgrade.
• Merge cohorts and launch official on-chain request to the Technical Fellowship by Monday 21 July 2025, dependent on participation and alignment during this discussion phase.

---

Forum Discussion Reading Materials

Community Calls & Recordings
We recently hosted two community calls to align on where we are and where we are headed:

• Monday 7 July 2025: Recording
• Tuesday 8 July 2025: Recording

Key Takeaways

• Strong consensus emerged to move the Ambassador Fellowship on-chain using the current pallet, though some concerns remain.
• A 7-day discussion period begins immediately, followed by a vote if there’s sufficient support.
• The move aims to bring transparent governance, verifiable ranking, and greater legitimacy, while keeping social dynamics and clear rules in focus.
• Ranking mechanics need refinement to prevent power imbalances and ensure fair promotions.
  Cohort 2 ambassadors will join at rank 0, with promotion processes subject to community input.

1. On-Chain Implementation

• The system includes tip bot and treasury functionality.
• Enables transparent, verifiable ranking (not tied to compensation).
• Aligned with the Ambassador Fellowship Manifesto and reviewed by the Technical Fellowship.
• A process flow chart will be shared for community feedback.
• Requires thorough testnet testing before mainnet deployment.

2. Governance & Voting Mechanics

• Current structure could allow higher ranks to block promotions — a concern for fairness.
• Suggestions include opening voting to all ranks or leveraging OpenGov for dispute resolution.
• There’s a strong call for clear, codified rules to prevent abuse or gaming of voting power.

3. Ambassador Community Growth

• Genesis cohort: 162 ambassadors, 12 funded projects.
• 66% (106) of Cohort 1 want to move on-chain.
• 46 new applicants have submitted detailed forms for Cohort 2.
• Local initiatives (e.g., Florida events) highlight grassroots impact.
• There’s growing energy to expand to new cities and welcome more ambassadors.

4. Ambassador Role & Compensation

• The ambassador role remains recognition- and reputation-based, not salaried.
• Future compensated roles may be introduced separately.
• A Web3 Foundation proposal to reimburse travel and related costs is under review (not tied to ambassador rewards).

---

Documentation & Code

Ambassador Fellowship Manifesto

Polkadot Ambassador Fellowship: [detailed] Technical Specification

Polkadot Ambassador Fellowship: [Simple] Technical Specification

Ambassador Configurations #736

NB: During the call on Tuesday 8 July, there was a request for flow chart generation. This is not being shared as there are elements that need to be tested and adjusted as the configuration process was halted before the end. Rather than provide images that are 95% correct and distract the keen eyes from the conversation at hand, members of the Ambassador Fellowship are encouraged to generate UML diagrams based on the current and discussed processes themselves.

---

Concerns Raised [Please consider in your feedback / discussion points]
Vikk, Rank III Ambassador & Member of the Hungarian DAO

1. “Let members remove themselves easily by unlocking their DOT through a mechanism where an Ambassador must first inform the Fellowship of their departure before their DOT is unlocked and they are removed from the on-chain collective.”
   What happens if they do not inform the Fellowship and just unlock their DOT?

2. “The highest rank must go through a formal process with OpenGov if they wish to leave.”
   What is the formal process? Who decides on it? What happens if they do not go through the ‘formal process’ and just unlock their DOT?

3. “Internal rank-weighted voting – set up a voting system inside the Ambassador Fellowship where higher ranks have more voting power.”
   Where is the consensus on the increase of the voting power per rank?

4. “Create a small treasury just for tools and operational costs”
   What is small? Where would the money come from?

5. “Create a tipping pool as part of the treasury. This is separate but linked to the main treasury and is voted on internally by Ambassadors.”
   So is it part of the treasury or not? How is it linked? How big is it? Where would the money come from (main treasury?)?

6. “All voting takes place on the last working day of the month each month (Monday-Friday).”
   Voting time should be more than 1 day (maybe at least 3) and since we are in Web3 last working day of the month would be different in different parts of the world, so voting period should be better defined (like from 00:00 GMT on the first Tuesday to 24:00 CET on the first Thursday of the month).

7. “Money requests must include a short description (memo) explaining what the funds will be used for.”
   What money requests? Only tips? What amount? Ambassadors would request for themselves or for others who did a good job?

8. “Allow members to request promotions.”
   Originally it was discussed that a member should be put forward for promotion by vote by at least one rank higher (except if there isn’t one).

9. “Check members’ activity in online engagement, offline engagement, governance, community growth, partnerships, and leadership. Expectations will vary according to rank / tier. Each higher rank should have tougher requirements.”
   Where is this defined EXACTLY with everybody agreeing so all Ambassadors know what to achieve for a higher rank and there can not be a different interpretation of the rules by different people?

10. “Require a majority vote from members one rank higher for promotion.”
    This is a key difference from the manifesto. Originally if someone is being promoted to let’s say from R3 to R4 then ALL ambassadors would vote (according to their voting weight) and there is a SIMPLE MAJORITY (50% + 1 vote) the applicant advances up one rank. If this goes on-chain in its current format not only majority is not defined, but current R4s can KEEP ANYBODY ADVANCING TO R4 FOREVER EVEN IF ALL THE OTHER AMBASSADORS VOTE FOR THE APPLICANT TO ADVANCE. That is a serious flaw in the logic which should have been caught had it been discussed more thoroughly.

11. “Specialist Groups (verticals)”
    This the PIF (Phragmen Initiative Funding) which should be totally separate from the Ambassador Fellowship pallet. Again, this was not discussed fully.

12. “Members must act professionally, respectfully, and support the Polkadot network.”
    This is too vague and is open for different interpretations.

13. “Small clarifications can be voted on by Ambassadors through the internal voting system. All voting will happen on the last working day of the month (Monday-Friday), along with treasury spends, promotions / demotions / removals.”
    What is defined as “small clarifications” and again, the voting period needs to be defined better.

14. “Require major changes to go through the public Polkadot governance system.”
    I am not too sure what this refers to. If it is OpenGov then it needs to be clearly stated.

[Lucy]

I will kick off with some responses to Vikk’s concerns as discussed on the call on Tuesday 8 July. Please note these are my personal viewpoints only.

1. “Let members remove themselves easily by unlocking their DOT through a mechanism where an Ambassador must first inform the Fellowship of their departure before their DOT is unlocked and they are removed from the on-chain collective.”
   What happens if they do not inform the Fellowship and just unlock their DOT?*

A: This is not something that we intended to police when we wrote the manifesto. The intention of Fellowship was to be a vibrant space with many members, coming and going would be part of that. I would like to see that continue, but perhaps if an Ambassador is going into Tier 3 - Rank V and VI - there should be a forced mechanism by which they have to resign from their on-chain rank?

2. “The highest rank must go through a formal process with OpenGov if they wish to leave.”
   What is the formal process? Who decides on it? What happens if they do not go through the ‘formal process’ and just unlock their DOT?*

A: This process needs to be designed. These were conversations we hoped would happen within the Fellowship that have not happened organically. I still think below Rank V and VI, which are the most externally facing roles, we cannot heavily police who comes and goes. But if there is a process, forum post / X / notice period?

3. “Internal rank-weighted voting – set up a voting system inside the Ambassador Fellowship where higher ranks have more voting power.”
   Where is the consensus on the increase of the voting power per rank?*

A: This mirrors the Technical Fellowship and was voted in when the manifesto was voted in. It was also commented on in person by Gavin Wood at the meet up in Bangkok before the manifesto went live. It was strongly debated and I think stands with very strong consensus. The tech fellowship has demonstrated that it works, with their decisions being made mainly through cumulative rank voting - “members votes are weighted by their Rank as an item in the geometric series”.

4. “Create a small treasury just for tools and operational costs”
   What is small? Where would the money come from?*

A: The incubation phase from Jan-May was a testing ground to see what worked. Funding was part of this. We learned that $300 per month gets us the basic tools. A detailed rewards&recognition framework was built and workshopped live by Ambassadors (all details on the notion). This was roughly costed up to get to an R&R budget. We also tested marketing, finance and education budgets. All of this evidence is how we would now extract a monthly cost based on number of Ambassadors and current needs. The money would come from the main treasury, as per the Technical Fellowship. It would be kept in the Ambassador treasury which is part of the pallet. All payments would be made via the rank voting system.

5. “Create a tipping pool as part of the treasury. This is separate but linked to the main treasury and is voted on internally by Ambassadors.”
   Is it part of the treasury or not? How is it linked? How big is it? Where would the money come from (main treasury?)?

A: Transition to the On-Chain Collective: Next Steps for the Ambassador Fellowship Please see the tip bot here to understand how it works technically. I have answered the question about where the funds come from above. One thing that the W3F said was critical to their support in the on-chain Ambassador Fellowship was a mechanism to make sure that Ambassadors are paid for their contributions, so we have removed salaries (not in keeping with manifesto but were in the previous pallet) and introduced the tip bot.

6. “All voting takes place on the last working day of the month each month (Monday-Friday).”
   Voting time should be more than 1 day (maybe at least 3) and since we are in Web3 last working day of the month would be different in different parts of the world, so voting period should be better defined (like from 00:00 GMT on the first Tuesday to 24:00 CET on the first Thursday of the month).*

A: This makes complete sense. As long as there is a regular cadence so people get into a rhythm, a 72 time period seems very sensible.

7. “Money requests must include a short description (memo) explaining what the funds will be used for.”
   What money requests? Only tips? What amount? Ambassadors would request for themselves or for others who did a good job?*

A: Any expenses that come from the treasury. In the beginning, we would anticipate this being ongoing tooling costs and tips for Ambassador work, either self-proposed or nominated, voted on at the end of each month over a 72 hr period (as suggested above).

8. “Allow members to request promotions.”
   Originally it was discussed that a member should be put forward for promotion by vote by at least one rank higher (except if there isn’t one).*

A: To my recollection, was never discussed, but I could be wrong. It seems that it would be a difficult system if an Ambassador had to rely on another Ambassador to recommend them for promotion. As Ambassadors are not paid roles and do not require consistent input, it could be quite an ask to be someones ‘sponsor’. This would also allow for favouritism and cliques to form - overlooking contributions. That would be my fear. If someone has a portfolio of work, the Ambassadors should vote on that and perhaps some testimonials in support would be great for any Ambassador.

9. “Check members’ activity in online engagement, offline engagement, governance, community growth, partnerships, and leadership. Expectations will vary according to rank / tier. Each higher rank should have tougher requirements.”
   Where is this defined EXACTLY with everybody agreeing so all Ambassadors know what to achieve for a higher rank and there can not be a different interpretation of the rules by different people?*

A: As discussed at length when the manifesto was being written, we kept things flexible so that the Fellowship could adapt over time. What I believe you would hope to see is the bar rising as time goes on. As an Ambassador can be from any background, skillset, geography, ability, the differentiation in how their contributions are measured are too wide to tickbox at this point in time. Which is why having such a vibrant community will help to level out the voting playing field as we begin to better understand what each rank looks like. If definite skillsets and requirements emerge over time, these can be written into the manifesto, which should be considered a work in progress at all times (like all of us!).

10. “Require a majority vote from members one rank higher for promotion.”
    This is a key difference from the manifesto. Originally if someone is being promoted to let’s say from R3 to R4 then ALL ambassadors would vote (according to their voting weight) and there is a SIMPLE MAJORITY (50% + 1 vote) the applicant advances up one rank. If this goes on-chain in its current format not only majority is not defined, but current R4s can KEEP ANYBODY ADVANCING TO R4 FOREVER EVEN IF ALL THE OTHER AMBASSADORS VOTE FOR THE APPLICANT TO ADVANCE. That is a serious flaw in the logic which should have been caught had it been discussed more thoroughly.*

A: As the manifesto currently states, Ambassadors one rank and above the intended promotion level are able to vote. This is similar to the technical fellowship, but reduces the number of ranks higher (tech fellowship is two and above). Again, we did not think we needed to reinvent the wheel as this works very well for the technical fellowship and there is no reason it should not for us. The highest rank applications will always have to go through OpenGov, not just the first. For example, if person A applies to OpenGov to move from a Rank IV to V, it will be voted on. If they are approved and they are the 1st Rank V, they will not vote the next person in, person B will also have to go to OpenGov to move to Rank V. The only time it could be a problem is at Rank V and VI, so maybe there is a number of Rank VIs required in place before people stop going to Open Gov for that role, or anyone that ever applies for Rank V and VI has to go through OpenGov. This might make sense as it is a high leadership role, so the person should have a very strong standing across the whole community.

11. “Specialist Groups (verticals)”
    This the PIF (Phragmen Initiative Funding) which should be totally separate from the Ambassador Fellowship pallet. Again, this was not discussed fully.*

A: Two things here: 1. specialist verticals are not PIF. We need to separate the idea of PIF completely from the Fellowship. I think there was confusion over some of the original narrative, but PIF is a funding mechanism only. It was tested with some community and solo agents in Q1 2025, but it is nothing to do with the Fellowship or manifesto. Specialist verticals are the areas we would hope to see Ambassadors congregating according to their skillset. ie. Developers / BD / Marketing / Content Creation. There could be individuals that do this on a full-time basis and are also Ambassadors or receive a regular tip for leading a specialist vertical within the Fellowship, but it is not directly linked to the PIF funding mechanism (which does not currently exist and if and when it does, it will be for the entirety of the Polkadot community). 2. Specialist verticals are not here yet and that requires more thought from the Ambassadors to start configuring those groups and then from the technical side to see how we might work these into the pallet. For now, it is a complexity that we do not need and can be changed at a later date.

12. “Members must act professionally, respectfully, and support the Polkadot network.”
    This is too vague and is open for different interpretations.*

A: Again, this is in the technical fellowship and in the absence of any code of conduct or people values in the Polkadot ecosystem, it is better than nothing It has been widely agreed of late that we need to better define both of these things, but I do not think (personal opinion only) that there is anything that you can build into the pallet that will be impacted by decisions made on this point?

13. “Small clarifications can be voted on by Ambassadors through the internal voting system. All voting will happen on the last working day of the month (Monday-Friday), along with treasury spends, promotions / demotions / removals.”
    What is defined as “small clarifications” and again, the voting period needs to be defined better.*

A: This definitely needs to be better defined. We could state - typo, etc - or just go blanket, any changes. The voting period for everything could work as once a month for 72 hours to start with if that is agreeable to everyone.

14. “Require major changes to go through the public Polkadot governance system.”
    I am not too sure what this refers to. If it is OpenGov then it needs to be clearly stated.*

A: As above, I agree and think maybe moving forward it should be any changes. And with each change is a new draft number.

[0xTaylor]

This was your last message in KusDAO on Ref #1614.

What is going on?

At this stage, concerns were raised by an individual, prompting a temporary pause.

What? What concerns?

[Lucy]

While I stepped away from the proposal, I never stepped away from the Fellowship.

Since then, several factors have led me to continue supporting the on-chain advancement of the Fellowship. This includes direct encouragement from Ambassadors and leadership figures within the Polkadot ecosystem, who urged me not to disengage. I also took time for personal reflection and realised that I was not ready to walk away from the important work that has already been accomplished by so many.

This initiative has been a long-standing ambition of many within the Ambassador community, and if I’m still in a position to help move it forward, I feel a responsibility to do so. Given the current volatility in the ecosystem, I don’t view this renewed focus as a dramatic shift, rather, a continuation of my long-standing commitment. My motivation remains the same. I’ve faced challenges along the way, but now is not the time to step back for me personally.

[Lucy]

Apologies for not being clearer earlier. The concerns being referenced are the 14 points listed at the bottom of the post. I’ve responded to each from my perspective in an effort to open up dialogue and move the conversation forward.

Following two productive and well-attended calls, one of which included participation from both Vikk and Spectra, there was agreement that I would share this update in an operational and facilitative capacity. The general sentiment among the Ambassador collective is that moving on-chain represents the next logical and widely supported step. This thread is intended to serve as the space for open discussion, so we can work through remaining questions and move toward that goal together.

[jslusser]

I’m looking forward to the Ambassador Fellowship moving on-chain as a formal collective, and the Jul 7 + 8 call recordings are helpful for anyone who may have not been able to participate.

[jrguilherme]

I fully support the move to take the Ambassador Fellowship on-chain. It’s a big step toward more transparency, accountability, and a solid structure for everyone involved.

[Mork]

I’ve dropped this post in the pub chat too…

At this stage, let’s get onchain. Some issues have been raised with it but none that, imho, given the particular verge-of-falling-apart situation we’re in right now, justify delaying.

What seems more important to me is that:
Looks like there are many criticisms that people want heard,
and yet, there are not many people contributing to the debate.

Is this because the only people with criticisms are a small minority?
Or because most people are fatigued by all of the drama and staying out of the conversation?
Or is it simply that of the 167 ambassadors, and 121 in the pub chat, only a few are bothered at all?

It feels to me like, if we go forward into a new phase without input (even just ‘sure sounds fine’) from significantly more ambassadors than we have so far been hearing from, that the lack of trust we are seeing right now is likely to persist.

So, IMHO, a discussion needs to be had.
How should we do that?
In this thread? Or another?
Should the forum be the pace for it or is it too public? Better a series of calls?
Should some of the louder voices sit out the discussion?
Should we discuss in smaller groups and reconvene?

All input welcome..

[ltfschoen]

Thoughts on Operations, Governance and Values Alignment in the Ambassador Fellowship

12. “Members must act professionally, respectfully, and support the Polkadot network.”
    This is too vague and is open for different interpretations.*

Values Alignment

Values Alignment Checklist

I recently prepared a comprehensive Ambassador Fellowship Commitment Checklist (v0.1) and shared that draft for refinement privately for feedback to one other member.

The checklist would use a tiered approach with increasing requirements by rank and would serve a crucial purpose in ensuring values alignment and would be about verifying that ambassadors who are representing the ecosystem understand and commit to Web3 and Polkadot values and fundamental technical understanding.

Values Alignment Staking Requirement

The checklist has a staking requirement that includes multiple accessible alternatives to staking for so it isn’t about wealth but ensuring ambassadors have “skin in the game”, because when ambassadors stake a native ecosystem token like DOT, KSM, PAS, or WND or an accessible alternative of similar equivalent value, their economic interests align with the ecosystem’s health, they signal genuine commitment, and face accountability through potential slashing. Without such requirements, we risk misaligned incentives, low-quality participation, vulnerability to governance attacks, and inconsistent messaging about Polkadot’s principles.

Pre-funding vs. Retroactive Compensation

The checklist supports standardisation by requiring detailed scope documentation before beginning work. It highlights that pre-funding ensures participation that isn’t limited to those who can afford to work without guaranteed compensation to be more aligned with Polkadot’s “inclusive” value, since retroactive compensation models create unsustainable dynamics where contributors must self-fund work upfront with no guarantee of fair compensation or even recognition.

I’ve decided not to publish the comprehensive checklist for community discussion yet, as it would require a phased approach with a “simplified” version initially, similar to how we’ve only implemented the “simplified” version of the technical specification that maps to the Ambassador Fellowship Manifesto rather than the “detailed” version that I prepared.

The initial version would focus first on the social values component while developing any technical aspects later.

The goal would be to ensure representatives truly understand and embody our core values, since those unwilling to engage with those values may not be ideal ambassador representatives regardless of status or experience.

Values Assurance Group

Even if the checklist approach isn’t initially adopted (since it’s more hands-on and requires members to explicitly complete checklists on an ongoing basis), then we must at least proactively perform random verification of alignment with values through a Values Assurance Group.

Alignment with the following would be expected:

• Polkadot Vision - Polkadot 1.0 - Polkadot Wiki
• Polkadot Mission - About
• Polkadot Values (adapted to the Ambassador Fellowship)
  • Interoperability: Building bridges between communities and facilitating cross-ecosystem collaboration, ensuring ambassadors can effectively communicate Polkadot’s vision across diverse audiences and technological backgrounds.
  • Decentralization: Promoting distributed leadership and equitable participation within the Ambassador Fellowship, avoiding power concentration and ensuring diverse regional representation in decision-making processes.
  • Autonomy: Empowering ambassadors to initiate independent projects while maintaining alignment with ecosystem values, encouraging self-governance and personal accountability in community representation.
  • Innovation: Embracing creative approaches to community building, education, and outreach that challenge conventional methods and demonstrate Polkadot’s forward-thinking ethos.
  • Adaptability: Remaining responsive to evolving community needs and governance practices, continuously refining ambassador approaches based on feedback and changing ecosystem priorities.
  • Inclusivity: Creating welcoming spaces for participants regardless of technical background, socioeconomic status, or geographic location, actively seeking diverse perspectives and ensuring governance processes are accessible to all.
  • Community: Fostering supportive relationships among ambassadors and ecosystem participants, prioritizing collective success over individual recognition, and building sustainable networks of mutual support.
  • Security: Maintaining information integrity in communications, protecting community members from misinformation, and ensuring transparent, verifiable governance processes with clear accountability mechanisms.
  • Sustainability: Developing ambassador practices that can be maintained long-term without contributor burnout, emphasizing pre-funded work models and equitable compensation for specialized contributions.
  • Utility: Focusing ambassador efforts on activities that deliver tangible value to the ecosystem and address real community needs rather than superficial metrics or vanity projects.
  • Accessibility: Removing barriers to participation in the Ambassador Fellowship by providing multilingual resources, accommodating different learning styles, and creating clear pathways for newcomers to contribute meaningfully.
• Polkadot DAO Constitution
• Web3 Values
• Ambassador Fellowship Values
• Ambassador Fellowship Code of Conduct
• Kusama Code of Conduct
• Universal Declaration of Human Rights (UDHR)

Technical Implementation Improvements & Deployment Approach

“an open community discussion about the current on-chain pallet configuration. The Technical Fellowship has configured the previous Ambassador 2.0 pallet to align with the Ambassador Fellowship manifesto”

It’s important for all Ambassador Fellowship members to know that the “current on-chain pallet configuration” that was implemented by Jesse in this Pull Request reflects the Polkadot Ambassador Fellowship: “Simple” Technical Specification and NOT the Polkadot Ambassador Fellowship: “Detailed” Technical Specification

“moving on-chain represents the next logical and widely supported step”

I have a question, and that is, given that there’s no guarantee that we’ll be paid even retroactively for even essential operational or governance work for the Ambassador Fellowship, why are we deploying to “production” on Polkadot before deploying on the canary “staging” environment on Kusama and before first properly “testing” it on Polkadot Testnet like Paseo or Westend?

I’m currently implementing this “AND” Gate on-chain pallet that will provide an on-chain “conditional approval” supported by on-chain comments (remarks) feature that could be integrated into the Ambassador Fellowship on-chain implementation to require pre-approval by a threshold of approvals from a group of members from a diversity of ranks that aren’t just members but have also ratified on-chain their understanding and commitment to ecosystem values and that follow strict and transparent evaluation criteria when qualifying value alignment of tip proposals before the tip proposals proceed to voting by other members, so there’d be structured on-chain comments to supplement approval of tip proposals that use the tip bot and providing more robust governance.

UML Diagrams and Documentation

“flow chart generation”

I’d like to highlight that whilst it’s quite easy to generate comprehensive UML diagrams using generative AI of both the “simplified” and “detailed” technical specifications, the reason I decided not to publish them is because I haven’t formally reviewed the implementation.

As Lucy mentioned, if I did so then it might require additional tests, adjustments and independent verification to accurately reflect even just the current configuration. I wouldn’t want them to have any mistakes since that’d just invite criticism.

I don’t want to face unnecessary attacks for unpaid volunteer work, and because the community might even assume I’m getting paid for it when I’m not, or that my selfless efforts to help other members is just a strategy to ultimately “grift” the treasury.

Conclusion

In summary, I believe we need to establish proper governance processes with clear accountability mechanisms, pre-funded work arrangements, and transparent value alignment verification to ensure the Ambassador Fellowship truly represents the principles of the Polkadot ecosystem. These improvements would strengthen our governance while making participation more inclusive and sustainable.

[jslusser]

@ltfschoen

why are we deploying to “production” on Polkadot before deploying on the canary “staging” environment on Kusama and before first properly “testing” it on Polkadot Testnet like Paseo or Westend?

I would look for an answer from the working group referenced above that included Anaelle, Jesse Cheijieh, Oliver Tale-Yadzi, Joe Petrowski (all from the Technical Fellowship) and @Lucy. My presumption is they’ve signed off on it and it will work, or they wouldn’t have requested to include it in the next runtime upgrade. But I don’t know what I don’t know. I also respect you, your work and your opinion, and if you truly have a concern, I would like for it to be addressed.

[Lucy]

I mentioned that Jesse had suggested that we do this on a smart contract on Kusama. It will take one month and he is happy to do the work for us.

On one of the calls last week, it was immediately dismissed as an idea with the counter argument being that we didn’t want to do anything on a test net / Kusama as the wait to go on Polkadot had been long enough.

IMO, Luke and Jesse’s suggestion makes a lot of sense given there will be changes as we grow and adapt and in the absence of smart contracts on Polkadot, this is an option to get us started on a more flexible pallet before moving over the hub when a lot of these other decisions being discussed on the side (next proposal, cohort II ranks, promotions) have been made.

I don’t see that this would change the process we have going on here. If there is a general consensus that we deploy on a kusama smart contract, then we can include in a vote for those who have opted to on chain maybe?

[SpectraCV]

While the proposed timeline demonstrates an admirable desire to move the on-chain program forward, there are several compelling reasons why this 7-day discussion period is insufficient for such a foundational decision:

Timing Concerns:
The mid-July timeframe poses significant challenges as it coincides with peak summer period when many community members are on vacation or have reduced availability. More critically, scheduling this discussion right before Web3Summit creates a direct conflict of priorities. Many ambassadors and key stakeholders will be focused on preparation for this major industry event, potentially limiting their ability to engage meaningfully in discussions that will shape the future of the on-chain program.

Importance of Deliberation:
The on-chain fellowship represents a fundamental shift in how the program operates. These are not incremental changes but foundational structural decisions that will impact the ecosystem for years to come. Seven days simply doesn’t provide adequate time for:

• Thorough review of pallet changes and their implications
• Meaningful community feedback and iteration
• Proper consideration of onboarding plans and their long-term effects
• Resolution of potential concerns or conflicts that may arise

Risk of Rushed Implementation:
History shows that hastily implemented foundational changes often require significant time and resources to rectify later. The principle of “measure twice, cut once” applies particularly well here. Taking additional time now to ensure proper community alignment and technical soundness will save considerable effort down the road. The cost of delays pales in comparison to the potential cost of having to restructure or fix rushed decisions post-implementation.

Governance Process Integrity:
The mention that this requires a vote on OpenGov to be included in the RTU (Runtime Upgrade) underscores the significance of these decisions. Such consequential changes deserve the full democratic process that OpenGov provides, which inherently requires adequate time for proposal review, community discussion, and informed voting.

Recommendation:
Consider extending the discussion period to at least 14-21 days, scheduled after Web3Summit when the community can dedicate proper attention to these crucial decisions. This would demonstrate respect for the importance of the on-chain program while ensuring robust community participation and thorough deliberation.

[Lucy]

These concerns are entirely understandable and the points regarding timing, deliberation, and governance integrity are well taken.

However, it is important to note that this discussion is not beginning from scratch. The current 7-day period follows several months of open dialogue, multiple working sessions, and iterative feedback from a broad group of contributors, including the calls held at the beginning of last week, where many, including you, played an active role. Given both the significance of the topic and the process to date, it’s unclear why the recommendation to extend the timeline was not raised earlier, rather than at the close of the forum period.

Further delay risks reinforcing a cycle of inertia. Whether intentional or not, repeatedly deferring decisions - especially when there has been ample opportunity for earlier input - undermines momentum. At some point, there must be a transition from discussion to decision-making, or we risk never implementing the widely acknowledged and needed changes.

While it’s reasonable to ensure sufficient deliberation, it is equally important to respect the time and effort already invested by the broader community.

Perhaps an additional 10-day discussion period could follow immediately after the current one, extending the forum’s closure and vote scheduling to Sunday 26 July. The vote could then be held from Monday, 27 July through Wednesday, 29 July?

[jslusser]

While I agree that there has been ample opportunity for community engagement and thoughtful dialogue up to this point, I hear and appreciate the concerns raised by @SpectraCV and @Lucy. The proposed extension of the discussion period through July 26 strikes a reasonable balance and I support it.

That said, I’d now like to hear from others who haven’t yet contributed to the conversation - especially once they’ve had a chance to re-engage after the Web3 Summit.

[hatch]

I’m ready to move on-chain. It’s a good logical next step. From there, we can actually activate the entire fellowship to do something as a collective.

I’m proud to be part of this OpenGov experiment we are all on. Furthermore, I am willing to register my support by forging a block or two to solidify my role as an Ambassador of this amazing ecosystem.

[Lucy]

Given Spectra’s concerns, James’ comments and conversations had by many at the Web3 Summit, it seems the above dates make sense. If there are further comments on extending the period, they should of course happen, but it seems sensible to confirm this next timeline.

Currently 62 Ambassadors have completed the form to vote on 27 July. Please remember to submit this final form (very short, 30 seconds) by that date. Ambassadors: Final Commitment to the On-Chain Fellowship.

Looking forward to further conversation next week following the Summit!

[OliverTY]

@jslusser

I would look for an answer from the working group referenced above that included Anaelle, Jesse Cheijieh, Oliver Tale-Yadzi, Joe Petrowski (all from the Technical Fellowship) and @Lucy

As a side note about development time: there are Ambassador Pallets on-chain on Polkadot since over a year and not being used.

It even has Subsquare integration:

But it is what the previous iteration of the ambassador program was supposed to be. Now with the new Manifesto it requires to remove/change that.

I would also prefer it to be smart contracts, as it removes the painful bottleneck of Parity/Fellowship/Runtime Upgrade, but not sure how it aligns with the timelines. It is kind of silly that we have to jump through all those hopes to make some changes that anyone could do if it were a contract..

Anyway, just a comment. Not a critiquing the current approach, just past decisions coming to haunt us.

[Mork]

Wouldn’t things be great if the principle of ‘measure twice, cut once’ applied in crypto.
By all means measure twice, but you’ll be cutting, fixing and patching far more than twice either way!

Imho, the danger of making mistakes from rolling-out quickly needs to be balanced against: the increased time between iterations that this implies; and the unknown-unknown risks of loss of momentum.

My opinion is go for it.
The crucial thing is that we get maximum engagement once we are onchain and that any flaws are widely identified so that we can get them fixed.
(There are also learnings from the process of how we got here - relevant in this convo is that blocking-level objections came up late in the day which may have been avoided if there were fuller engagement in the earlier stages of the deliberation. How to get that fuller engagement is something that is magic to most people, but it’s something we need to bear in mind as we go forward into a new phase with even more deliberating to be done)

[Lucy]

I agree with Mork, though I do heed Oliver’s warning.

Based on all of the conversations happening here and last week in Berlin, I still believe we need to move this beast on chain asap. People are very keen to get moving and the only way to do that successfully is to move on chain and let people start to vote.

With this in mind, I have suggested to the technical fellowship (to check we would have their go ahead if it is agreed via the vote on Monday-Wednesday next week):

• We put the current pallet in the next runtime upgrade and we go on chain with a pallet on Polkadot.
• When smart contracts are ready for Polkadot, we build an Ambassador one with any changes we have identified in the first few weeks / months.

Reasons for suggesting the above:

• We need to move on chain to reach a consensus without anyone else getting beaten up in the process.
• We need to move on chain whilst the iron is still (just about) hot. Any longer and we will have nothing left to motivate.
• The smart contracts on Polkadot are not going to be ready until at least September and the Ambassador one will likely not be a priority, so that could be more months down the road, whereas the next runtime upgrade is soon.
• We could do a Kusama smart contract, but given another smart contract on Polkadot would have to be built, doesn’t it make sense to save the time, use what we have (the pallet) and only rebuild once

What do people think?

[olanod]

Getting the ambassador program to a mature state will need a good amount of iteration and relying on the fellowship and runtime upgrades will not help with the needed agility.

A good hybrid approach that gives anyone a proper native DAO with it’s own OpenGov that can be extended with smart contracts and gets recognized anywhere in the ecosystem as a XCM plurality like the fellowship, is to make use of the “OpenGov for DAOs infrastructure” that will soon be available on Kusama AH after this recently approved WFC.
My team and I will be glad to help in any way that is needed to give ambassadors whatever tool they need during this early agile stage, from setting up the DAOs and DAOs within DAOs, any contract extension that might be needed or specialized UIs.