WikiDeal Funding MVP — Technical Specifications

WikiDeal (a project of the Netizen3) raises subscriptions to fund its Prototype 1. Donors and Early Supporters receive Subscription Tokens, which are progressively compensated in cash by the income of WikiDeal subscriptions. The MVP is the minimal working system that supports this loop:

1. Subscription payments by credit card (Stripe), PayPal, or bank transfer, in CHF.
2. Subscription Token activation — automatic at card payment time, manual (operator registry) for bank transfers and Early Supporters.
3. Subscriptions — CHF 1/month or CHF 10/year (annual recommended).
4. Subscription income distribution to holders of already-activated Subscription Tokens, visible on each user's dashboard.
5. Accounts with single sign-on shared with the MediaWiki at wikideal.net.

Outgoing payouts to users' bank accounts are not part of the MVP (Phase 2, see §4).

• Subscription form (mockup: funding-subscription-form.html) with amount input in CHF. The form must link to the subscription agreement (funding-subscription-agreement.html) and include: (a) a checkbox "I have read the subscription contract" and (b) the acknowledgement sentence "I have taken note of this subscription: it is a subscription, not a donation, and once made it cannot be revoked (no refund)."
• Minimum CHF 250, maximum CHF 5'000 per card payment. Above the card ceiling, the UI directs the donor to bank transfer (F3).
• From CHF 2'000, bank transfer is offered as a recommended option (not mandatory — card remains possible up to the ceiling), to avoid card processing costs.
• At subscription time, the donor chooses which share of the resulting Subscription Tokens they keep and which share they leave to the project as pure support (subscription form step 3). The share left to the project carries no special name and generates no Subscription Tokens for the donor.
• Payment processed by Stripe (Checkout or Payment Element) or PayPal, currency CHF.
• Stripe processing fees are added on top and paid by the donor (Netizen3 receives the full subscription amount). The fee amount is displayed before confirmation.
• On successful payment: e-mail receipt / subscription certificate (mockup: funding-certificate.html) and immediate Subscription Token activation (F2).

• Multiplier applies to subscriptions only. Fixed multiplier ×100: a subscription of CHF 1'000 attributes and activates 100'000 Subscription Tokens. The calculated Subscription Token amount is displayed to the donor before payment confirmation. No bonding curve in the MVP (the multiplier is a configuration variable, to prepare Phase 2).
• Early Supporters are NOT subject to the multiplier. They receive a fixed allocation of Subscription Tokens — a predetermined total amount distributed among all Early Supporters, as determined by the Foundation — and no per-CHF calculation applies to them.
• Activation happens synchronously in the payment confirmation flow (webhook-driven: checkout.session.completed or equivalent).
• The new balance is immediately visible on the donor's dashboard (F7).

• For amounts above the card ceiling (and as an option for any donor), the subscription is made by bank transfer to the Netizen3 account. The system displays the bank details and a payment reference.
• No bank-API integration in the MVP: the Foundation secretariat checks the account, then activates the Subscription Tokens manually within 7 days using the operator registry (F5).
• The donor sees a “pending activation” state on their dashboard until activation.

• Two plans, CHF only: CHF 1/month or CHF 10/year. The UI clearly recommends the annual plan (mockup: funding-signup.html).
• Recurring billing via Stripe Billing (subscriptions), card payment.
• Subscribers receive access to WikiDeal member benefits (see the wiki page Subscriptions); subscriptions do not create Subscription Tokens. As marketplace services open, an active subscription will be required to access them with low commissions (example: a taxi driver pays CHF 10/year and gets far lower per-ride commissions than on incumbent platforms, in exchange for light participation in the community, e.g. the annual general assembly).
• Standard lifecycle: subscribe, renew, cancel, failed-payment dunning (Stripe defaults acceptable).

• Web interface for the Foundation secretariat (mockup: funding-validation.html).
• The WikiDeal admin can search by email address and manually confirm ("OK") the Subscription Token attribution for a specific person.
• An online table associating an e-mail address → attributed Subscription Token amount, with an Activate action per row.
• Manual activation is required in the following cases:
  • (a) Subscriptions above CHF 2'000 via bank transfer: the money arrives on the Foundation account (e.g. PostFinance) without any automated system trigger. A human must verify the arrival of funds, then activate the correct person in the admin interface (the bank cannot trigger activation automatically). Activation within 7 days of confirmed receipt.
  • (b) Early Supporter activation: two conditions must both be verified before the admin confirms the Subscription Token attribution — subscription paid AND webinar attended.
• Merging subscription tokens (dual status): when a person is both an Early Supporter and a Donor (a frequent case), Subscription Tokens from both sources are merged and cumulated into a single balance visible on the person's dashboard.
• Every attribution/activation is logged (who, what, when — simple action log as shown in the mockup).
• Access restricted to authenticated operator accounts.

• Each subscription payment received is distributed according to the 25/25/50 rule published on the wiki (Revenue Structure):
• 25% to donors (holders whose Subscription Tokens come from a subscription);
• 25% to Early Supporters;
• 50% retained by the Foundation for project operations.
• Allocation key within each group: equal share per activated Subscription Token. Each group's share of every subscription franc is divided by the number of Subscription Tokens activated in that group at distribution time. Only activated Subscription Tokens participate (see the published Subscription Tokens FAQ).
• Worked example: CHF 500'000 raised out of the expected 1M; donors hold 37'000'000 activated Subscription Tokens. A subscriber pays CHF 1: the donors' share (CHF 0.25) is divided by 37 million — each activated donor Subscription Token is credited CHF 0.25 / 37'000'000. Small per-event, but it accumulates with every subscriber.
• Nominal unit: 1 Subscription Token = CHF 1 when cashed out (published: Subscription Tokens portal). As cash is credited, attributed Subscription Tokens are consumed 1:1 (CHF 1 credited = 1 Subscription Token moved from the promised column to the cash-out balance).
• Distribution may run as a periodic batch job (e.g. daily) rather than per-transaction, provided dashboard figures stay consistent.
• Full auditability: every distribution event is stored (source payment, date, per-holder credit).

• Authenticated dashboard per the mockup funding-dashboard-proposal-c.html (public view: funding-dashboard-unauth.html).
• Displays at minimum: attributed (promised) Subscription Tokens not yet compensated · activated status · cash-out balance in CHF (obtained) · history of distributions received.
• The cash-out balance accumulates freely; the UI states that no transfer is possible below CHF 100 and that bank payout will open in a later phase (mockup: funding-how-to-cash.html). No outgoing payment is implemented in the MVP.

• An account is required to hold Subscription Tokens, subscribe, and edit the wiki. Editing wikideal.net is never anonymous, but pseudonymous accounts are allowed: first name, last name and e-mail address are not exposed publicly.
• SSO approach: the existing MediaWiki (wikideal.net) acts as the identity provider — e.g. via the MediaWiki OAuth extension (or OpenID Connect equivalent) — and the funding dashboard authenticates against it. One account gives access to both wiki editing and the funding dashboard. This is the lowest-cost option and the preferred one; respondents may propose an equivalent-cost alternative with justification.
• Account creation flow per mockup funding-signup.html.

• Bank account details are optional at subscription/signup time — no administrative burden is imposed on the donor at the moment of giving. Fields for bank details are present in the form but marked with an asterisk (*) and the note: "* Optional now — required to activate a future cashout."
• To activate cashout, a separate second step is required: the user must provide their international bank account (IBAN), postal address, and a copy of their identity document.
• Rationale: keeping the signup and subscription steps as simple as possible avoids administrative heaviness at the start. Users who do not plan to cash out are not required to provide this information upfront.
• Cashout method: international bank transfer only in this phase. Additional payout methods (e.g. PayPal) will be considered in later phases.
• Minimum cashout: CHF 100 (unchanged). The actual bank transfer is Phase 2 (see §4); the MVP covers the user-facing step of providing and storing cashout information.

• Single Sign-On scope: a user's account gives access to the wiki and to a subscriber-only area — accessible only to users who have paid their WikiDeal subscription.
• The subscriber-only area contains contract templates (e.g. letters to contest parking or speeding fines, simple everyday legal templates), presented as a browsable list of available templates.
• Each template displays a validation status clearly: "validated by lawyers" or "not yet validated by a lawyer".
• The paid-templates area must be clearly identified as subscriber-only, and access must be independent from the rest of the public wiki.
• It should feel like an independent, app-like space (dedicated graphic presentation) while remaining technologically simple.

The following will be developed after the MVP, in a second stage. The MVP architecture should not block them, but no Phase-2 work is expected or paid within this envelope:

• Bonding curve: the fixed ×100 multiplier evolves along a defined curve (×100 → ×30, fixed algorithm).
• Funding Stabilizer: automatic mechanism adjusting distribution according to Foundation needs.
• Cash-out transfers (automatic): automatic periodic payout of the cashout balance (≥ CHF 100) to the user's bank account. In the MVP, the system collects cashout information (IBAN, address, ID — see F9) but does not execute bank transfers. Actual cashout disbursements are Phase 2.

Indicative only — respondents may propose their own schema, provided the auditability requirements hold.

An append-only ledger style for Subscription Token and cash movements is strongly recommended (no destructive updates of balances).

• Currency: CHF everywhere. No EUR, no other currency, no crypto.
• Hosting: deployable on Netizen3 infrastructure (Linux/nginx environment, same family as aidev.wikideal.net).
• Licensing: all delivered code under a free license (Free Licensing policy of the project).
• Privacy: pseudonymity supported; personal data (e-mail, name if given) never exposed publicly; data minimization; EU/Swiss data-protection compliance.
• Auditability: every money and Subscription Token movement traceable and exportable (CSV at minimum).
• Transactional integrity: Stripe webhooks idempotent; no double activation or double credit.
• Languages: UI in English for the MVP; architecture must not block later French localization.
• E-mail: transactional e-mails for receipt/certificate, activation confirmation, subscription events.
• Graphic design: two theme variants must be provided for the user-facing platform: a dark background theme and a light background theme.

Suggested option (not mandatory): Laravel + VueJS, matching the team's existing base (subscription-dashboard repository serving aidev.wikideal.net) and the current developer's proposal. Respondents may propose another stack, with justification, provided it satisfies §6 (hostable on Foundation infrastructure, free license, maintainable).

1. Fixed price in CHF for the full MVP scope (§3), within the CHF 3'000 – 5'000 envelope. If the envelope cannot be met, state which requirements you propose to defer and the resulting price.
2. Delivery timeline (calendar weeks from kick-off).
3. Stack & architecture summary (1 page max), including the SSO approach for F8.
4. Included / excluded items, assumptions, and Stripe account prerequisites.
5. Maintenance: proposed conditions after delivery (optional).

The mockups below define the expected result. Latest versions, maintained at the Funding hub:

• 1A. Dashboard — public view
• 1B. Dashboard — authenticated cockpit
• 1C. Subscription certificate (e-mail)
• 2. Registration & subscription
• 3. Subscription form
• 4. Operator activation interface
• 5. How to cash
• 6. Subscription agreement (FR)

v0.2 (2026-08-18) — all v0.1 open points settled with the project owner and cross-checked against the published wiki rules:

1. Card / bank-transfer threshold: bank transfer is optional and recommended from CHF 2'000; card remains possible up to the CHF 5'000 ceiling; above CHF 5'000, bank transfer only. (F1, F3)
2. Subscription income split: 25% donors / 25% Early Supporters / 50% Foundation operations — the published 25/25/50 rule. (F6)
3. Allocation key: equal share per activated Subscription Token within each group. (F6)
4. Consumption: nominal unit 1 Subscription Token = CHF 1 when cashed out; 1:1 consumption as cash is credited. (F6)
5. Subscriber benefits: referenced from the wiki Subscriptions page; marketplace low-commission access will require an active subscription. (F4)

These rules go in this tendency and are proposed as the working basis; final details are settled with the selected respondent before contract signature.

v0.3 (2026-08-25) — updates integrated from session 2026-08-25:

1. Multiplier — subscriptions only (F2): ×100 applies exclusively to subscriptions; Early Supporters receive a fixed allocation with no multiplier.
2. Cashout activation — new section (F9): second step to activate cashout (IBAN, postal address, ID copy); bank account details optional at subscription time, marked with asterisk (*); cashout only via international bank transfer; actual transfer = Phase 2.
3. Subscription form requirements (F1): form must link to the subscription agreement, include a "I have read the subscription contract" checkbox, and the irrevocability acknowledgement sentence.
4. Operator interface expanded (F5): admin searches by email, manually confirms ("OK"); two explicit activation cases: (a) bank transfer >CHF 2'000, (b) early supporter (subscription paid + webinar attended); merged balance when a person is both donor and early supporter.
5. SSO subscriber-only wiki area — new section (F10): contract templates behind a paid-subscription gate; TO BE DISCUSSED with Ricardo.
6. Cashout algorithm — placeholder (F11): specification pending, proposal from Ricardo to be integrated.
7. Graphic design (§6): two theme variants required — dark background and light background.
8. Payments (F1): PayPal added as a subscription payment option alongside Stripe.