Sharon Burns described a platform that could help nonprofits compare funding, grants, and partnership opportunities. Her proposal raised a harder question than how to organize the records: if a platform is supposed to help a community, who gets to shape and own it?
In the third part of my Voice of Blockchain recap, Sharon Burns, Lindsay Nguyen, and Paul Doherty approached that question through nonprofit data, privacy, representation, and smart-city design. Equity was not a side conversation after the technical model. It was part of deciding whether the system should exist and how it should be governed.
Better discovery is not enough if the community stays outside the model
Sharon Burns described a practical nonprofit problem. Funding, grants, and collaborative opportunities are difficult to compare or discover consistently because the records are fragmented. Her proposed answer was a platform that could standardize information and help nonprofits find funders, peers, and direct support.
The stronger part of her framework was not the directory logic. It was the ownership logic. She wanted participating organizations to help shape and own the platform rather than appear as passive entries inside someone else's data product.
That distinction matters well beyond nonprofits. When a community platform is built for people without giving them a real role in governance, the data may become organized while the power stays exactly where it was.
Privacy has to be understandable to the person living with the risk
Lindsay Nguyen pushed this issue further by focusing on immutable systems and personally sensitive data. Her warning was direct. If people put names, addresses, medical information, or other identifying details into a system they do not fully understand, the risk does not disappear just because the technology sounds secure.
That is a useful standard. Privacy is not only a backend decision. It is a user-trust decision. If the person affected cannot understand what is stored, who can see it, and what happens next, the project is already asking for more trust than it has earned.
Representation changes what the team notices
Lindsay Nguyen also described underrepresentation in blockchain spaces and the danger of symbolic diversity work that never reaches accountability, procurement, or decision-making. Borrowing a direct challenge from her father, she said, “Don't talk about it, be about it.” Design choices reflect who is in the room, whose questions get raised, and whose risk is treated as normal.
Paul Doherty and I reached a similar issue through a different route when we discussed smart-city and post-disaster development. A technology plan can look rational from outside and still feel imposed on the people who have to live with it. If the system ignores local culture, priorities, and history, it may be efficient on paper and destabilizing in practice.
Paul reduced smart-city priorities to safety, security, and quality of life. That simplification helped because it pulled the conversation away from feature overload and back to the lived purpose of the system.
That is the question leaders can use in any community data project: what would improve life for the people affected, and how would they know the project is serving them rather than studying them?
Three filters make that test more concrete on any community-facing platform or database. Who helped define the problem? Who carries the privacy risk? Who keeps power when the system scales? Those questions expose whether the project is building shared value or just better extraction.
A community-facing system needs more than clean data. The people living with its decisions need enough control to shape what gets built, what gets protected, and what the project refuses to collect.
