PONSVoting & request limits
How repository votes work, what they prioritize and the limits of account-based voting.
One saved choice per account and repository
A catalogue vote records whether a signed-in account supports a source candidate. Saving voted: true inserts a vote only if it is absent; saving voted: false removes it. Repeating the same intended state does not add extra votes.
You can support multiple repositories. There is no token balance requirement, vote weighting, lockup or wallet signature in this implementation. The interface needs the account gateway and persistent database to show and save your own vote state.
Requests have a separate vote count
A source candidate and a saved project request are different records. A catalogue vote prioritizes the upstream repository; a request vote supports that particular project specification. Their counts are stored separately and are not added together.
The catalogue endpoint saves an explicit boolean state. The saved-request vote endpoint toggles its current state, so repeating a request-vote POST can undo the earlier vote. Clients should wait for the response and refresh after an uncertain response rather than automatically retrying a toggle.
Priority is a signal, not an execution order
The default catalogue order uses saved vote count, then the recorded GitHub star count, then the stable candidate ID. Alternative sorts use source name or recorded stars. Stars are part of the research snapshot and are not a live market or usage metric.
Votes do not reserve credit, dispatch a job, select a model, approve a license or authorize deployment. Build readiness also depends on source review, engineering scope, available funding and connected services.
Account limits and their scope
A signed-in account can submit up to ten project requests during the preceding 24-hour window. Request names are 2–60 characters, tickers are 2–10 uppercase letters or digits, and descriptions are 25–3,000 characters.
These limits operate on a site-scoped account identifier. They do not prove that each account belongs to a different person and should not be described as Sybil-resistant governance. The current implementation does not enforce a separate per-wallet quota or token-holder gate.