A-thon Software · jog-a-thons, read-a-thons, and fun runs, built on a floor
Pledge per lap, per minute, per book — and the donor sees the exact amount before any charge.
An a-thon is the pledge model: a supporter promises an amount for each lap run, each minute read, or each book finished, the event happens, the units are counted, and the promise resolves into a real amount. A-thon Software is the home for that model. The fundraising substrate it stands on is built and running today: the donor cover-fee flow, the FLOOR principle that keeps the school’s total whole, consent-gated peer-to-peer student pages, and leaderboards that never show a minor’s name. The a-thon execution surface — the pledge-per-unit container, the units-recorded entry point, and the resolve-and-charge step — is in honest early access. We name what is live and what is early access on every claim, and we never charge a pledge before the donor has seen the exact final figure.
This is the a-thon and pledge product home — deep on the promise-then-collect model, the exact-amount disclosure, and the FLOOR economics. The cross-catalog fundraising product home is at fundraising.software. The campaign-store sibling for PTOs and booster clubs is at schoolfundraiser.network. The booster-club and PTA operations home is at boosterclub.software. The full platform story is at homeroom.software.
The a-thon category problem: too much of what is raised does not reach the school
The a-thon is one of the fastest-growing school fundraisers, and it is also the category where the most is taken out of what a community gives. There are two shapes to the problem, and they compound.
The first shape: a done-for-you event company runs the whole thing — the staff, the prizes, the pep-rally production — and keeps roughly half of what is raised in exchange. The event is easy for the school, but the community gave twice as much as the school ended up with. The second shape: a low-touch software platform charges much less per event but skims a large share off the top of every pledge and every gift, and the exact cut is often difficult for a school to compute before it signs up. Either way, a family that pledged for their child’s laps rarely knows how much of that pledge actually reached the school.
A-thon Software is built around the opposite premise. The school’s total is never reduced by card processing — that cost is covered by a disclosed donor-side fee under the FLOOR principle, not taken from what the school receives. The exact final amount is shown to the donor before any charge is submitted, in plain figures, not embedded in a price or revealed at settlement. And the a-thon runs as one part of the whole school platform — the same place that runs picture day, the yearbook, and the booster console — not a separate tool bolted on for one event.
Two ways to pledge, one honest resolution
An a-thon on this platform supports both collection models, and many a-thons blend them. In both, the donor is notified of the exact final amount before any charge, and the FLOOR keeps the school’s total whole.
Pledge per unit (promise, then collect)
A supporter promises an amount for each unit a student completes — each lap run, each minute read, each book finished, each mile, or a unit the school names. Nothing is charged when the pledge is made. The event runs, the units are counted, and the pledge resolves to the promised amount per unit times the units completed. An optional cap lets a donor promise per lap but limit the total, so a strong run never charges more than the donor intended. This promise-then-collect container is the a-thon primitive. Early access
Flat gift (give a fixed amount up front)
A supporter can also give a fixed amount up front, independent of how far a student runs or how much they read. This is the ordinary donation flow, and it is built and running today: the donor names the gift, the processing fee is computed server-side, the donor is shown the exact total and asked whether to cover the fee, and the charge is assembled as an exact sum. Many a-thons run both models side by side on the same page. Live today
The exact amount, before any charge
The rule that governs both models: the donor is notified of the exact final amount before any charge is submitted. For a flat gift, that is the gift plus the processing fee if the donor covers it. For a per-unit pledge, the resolution happens after the units are counted, and the donor sees the resolved figure — the promised rate, the units completed, and the total — before a card is ever charged. No pledge becomes a charge the donor has not first confirmed. Early access — per-unit resolution
The FLOOR: the school’s total is never reduced by processing
The FLOOR is the foundational rule of the fundraising engine, and it applies to an a-thon exactly as it applies to any other campaign. One sentence: the donor-side processing fee covers the card cost, so the school’s fundraising total is never reduced by processing. If the collected donor fee ever under-covers the actual card cost, the shortfall comes out of the platform’s share — never out of the school’s net. This engine is built and running today.
The donor covers the card cost, by disclosure
When a donor covers the fee, the charge equals the gift plus a covered fee computed server-side. The donor never names the fee, so the disclosed amount cannot be gamed. The donor sees the gift, the processing fee, and the total in plain dollar figures before the charge is submitted. This exact-sum disclosure is built and running today. Live today
The platform eats the shortfall, never the school
If a donor fee falls short of the actual card cost — possible when a donor opts out of covering it — the shortfall is charged to the platform’s share, which may go negative. The school net is a floor by construction: the engine resolves the platform share as the remainder, and a processor cost the donor fee did not cover lands in that remainder, not in the school’s number. The engine asserts this on every compute path. Live today
Every cent is conserved
Every split is exact-integer-cents. The engine sums the school net, the platform share, and the processor cost exactly to the gross on every computation — there is no rounding residual that disappears silently, and a cent unaccounted for throws rather than drifts. The math is exact integer arithmetic, so there is no accumulation error across an a-thon with thousands of pledges. Live today
How an a-thon moves from pledge to collected amount
The a-thon flow has a clear sequence. Each step builds on the previous one; nothing is charged before the donor has seen the exact amount. The status of each step below is named honestly.
- The school sets up the a-thon. A coordinator names the event — a jog-a-thon, a read-a-thon, a fun run — picks the unit (lap, minute, book, mile, or a custom unit), sets an event window, and configures the goal. Peer-to-peer student pages are created for participating students, each consent-gated. The setup runs on the built campaign and page substrate. (Setup on the built substrate is live today; the a-thon-specific event container is early access.)
- Supporters pledge or give. A supporter visits a student’s page and either promises an amount per unit (a pledge, with an optional total cap) or gives a fixed amount up front (a flat gift). A pledge charges nothing yet. A flat gift runs through the built donation flow: the donor sees the exact total and chooses whether to cover the fee. (The flat-gift flow is live today; the per-unit pledge is early access.)
- The event happens and the units are counted. On event day, a coach, teacher, or the student records the units each participant completed — the laps run, the minutes read, the books finished. The count is the input that turns a promise into an amount. The units-recorded entry point is part of the a-thon build. (Early access.)
- Each pledge resolves to an exact amount. Once the units are counted, each per-unit pledge resolves: promised rate times units completed, clamped by the donor’s optional cap. The donor is notified of the exact resolved figure — the rate, the units, and the total — before anything is charged. The resolve step honors the same donor cover-fee and FLOOR rules as the flat-gift flow. (Early access.)
- The charge is confirmed and collected. After the donor has seen the exact resolved amount, the pledge moves to a charge on the same exact-integer-cents engine, with the FLOOR keeping the school’s total whole. Live money movement is money honest-off today: the compute-and-prove substrate is built, and the live charge rail is founder-gated. Every dollar that does settle today settles to the school. (The engine is built; the live charge rail is honest-off.)
Student participation is consent-gated, and leaderboards never expose a minor
An a-thon is built around student participation — a student runs the laps or reads the minutes, and their page is what supporters pledge against. The platform’s consent substrate governs every one of those surfaces, and the built peer-to-peer page substrate carries it today.
A minor’s page is consent-gated at the data layer
A minor student’s peer-to-peer page cannot be created or published without the appropriate consent record in the platform. The gate is at the data layer, enforced at the point of page creation, not as an application-level check a route could omit. A page that lacks the required consent record for a minor is rejected before it is created. This consent-gated page substrate is built and running today. Live today
Leaderboards that never show a minor’s identity
An a-thon runs on friendly competition — a class leaderboard, a grade-level total, a school thermometer. The leaderboard surfaces progress without exposing a minor’s identity: a class or team total, a first-name-and-initial or an opaque display handle where a school chooses, never a public roster of children tied to dollar amounts. A supporter sees momentum; they do not see a minor’s full identity on a public page. Live today
The pledged-against student is not the donation’s public identity
A pledge made against a specific student does not expose that student’s full record to the donor or to a public page. The reference to the student in the platform is an opaque identifier; the student’s name and record do not appear on the donor-facing surface. The school administrator can see which students participated; the donor sees the progress they pledged against, not a child’s record. Live today
An a-thon that runs with the whole school platform
An a-thon is not the only thing a school runs, and A-thon Software is not a standalone tool for one event. It is one surface of the whole school platform, which means the a-thon shares the same roster, the same consent substrate, and the same fundraising engine as every other part of the school’s year.
The roster the a-thon builds student pages from is the same roster picture day and the yearbook read from — a student is entered once, and every surface reads the same list, gated by the same privacy wall. A school running an a-thon toward a real goal — funding yearbooks for every child, for example — can aim the proceeds directly at that catalog line through the cross-catalog funding model, rather than collecting a separate deposit to apply later. The cross-catalog funding model is built as a substrate; the settlement leg that routes proceeds directly to a catalog payment is founder-gated and money honest-off today.
The people who run an a-thon — often a booster club or a PTA — have a first-class console for it. The booster or PTA role is a first-class role in the platform, with its own console for managing campaigns, viewing transparent totals, and tracking the ledger, and it does not have access to student PII. The booster-club and PTA operations home is at boosterclub.software; the cross-catalog fundraising engine this a-thon builds on is at fundraising.software.
What is live today and what is early access
A-thon Software stands on a built fundraising substrate and adds an a-thon execution surface that is being built now. Each piece below is named where it actually is — live today, early access, or money honest-off. We never present a planned piece as if it shipped.
The donor cover-fee flow and the FLOOR
The exact-sum donor cover-fee decomposition (charge equals gift plus covered fee), the FLOOR that keeps the school’s total whole, and the conservation of every cent are built and running on an exact-integer-cents engine. Live today
Consent-gated peer-to-peer student pages
The peer-to-peer student page substrate that an a-thon runs on — consent-gated for minors at the data layer, with progress thermometers and leaderboards that never expose a minor’s identity — is built and running today. Live today
The pledge-per-unit container
The a-thon event container — the unit type (lap, minute, book, mile, or custom), the per-unit rate, the optional total cap, and the event window — is the new a-thon primitive being built. Early access
The units-recorded entry point
The surface where a coach, teacher, or student records the units each participant completed — the input that turns a promise into an amount — is part of the a-thon build. Early access
The resolve-and-charge step
The step that resolves each per-unit pledge to an exact amount (rate times units, clamped by the cap), notifies the donor of the exact figure before charging, and moves it onto the built engine is part of the a-thon build. Early access
Live money movement
The compute-and-prove substrate is built; the live charge rail that moves money is founder-gated and money honest-off. There is no pricing, no checkout, and no live charge on this page. Every dollar that settles today settles to the school. Money honest-off
Common questions
What is an a-thon?
An a-thon is a pledge-based fundraiser: a supporter promises an amount for each unit a student completes — each lap in a jog-a-thon or fun run, each minute in a read-a-thon, each book, each mile. The event happens, the units are counted, and the pledge resolves to the promised rate times the units completed. It is the promise-then-collect model, distinct from a donate-now gift where a fixed amount is given up front. A-thon Software supports both, and many a-thons blend them.
Is the a-thon pledge surface available today?
The fundraising substrate an a-thon stands on is live today: the donor cover-fee flow, the FLOOR that keeps the school’s total whole, consent-gated peer-to-peer student pages, and leaderboards that never expose a minor. The a-thon execution surface — the pledge-per-unit container, the units-recorded entry point, and the resolve-and-charge step — is in honest early access. We name what is live and what is early access on every claim rather than presenting the whole thing as available today.
When is a pledge charged?
Never before the donor has seen the exact final amount. A per-unit pledge charges nothing when it is made. The event runs, the units are counted, and the pledge resolves to the promised rate times the units completed, clamped by the donor’s optional cap. The donor is notified of the exact resolved figure — the rate, the units, and the total — before any card is charged. A flat gift given up front shows the exact total (gift plus the fee if the donor covers it) before it is submitted.
How does the FLOOR keep the school whole?
The FLOOR is the foundational rule of the fundraising engine: the donor-side processing fee covers the card cost, so the school’s fundraising total is never reduced by processing. If the collected donor fee ever under-covers the actual card cost, the shortfall comes out of the platform’s share, which may go negative — never out of the school’s net. The engine asserts this on every compute path and throws before returning a result that would violate it. This engine is built and running today.
Can a donor cap a per-lap pledge?
Yes. A donor can promise an amount per unit and also set an optional total cap, so a strong run never charges more than the donor intended. If a student runs far enough that the per-lap total would exceed the cap, the pledge resolves to the cap. The donor sees the resolved amount, whether it landed on the raw per-unit total or the cap, before any charge. The pledge container and the cap are part of the a-thon build, in early access.
How is a student protected in an a-thon?
A minor student’s peer-to-peer page is consent-gated at the data layer — it cannot be created or published without the appropriate consent record, enforced at page creation, not as an application-level check. Leaderboards surface progress (a class total, a grade-level total, a thermometer) without exposing a minor’s full identity. A pledge made against a specific student references that student by an opaque identifier; the student’s name and record do not appear on the donor-facing surface. These protections run on the built page substrate and are live today.
Does an a-thon connect to the rest of the school platform?
Yes. An a-thon runs on the same roster picture day and the yearbook read from, the same consent substrate, and the same fundraising engine as the rest of the school. A school can aim the proceeds directly at a real catalog line — funding yearbooks for every child, for example — through the cross-catalog funding model. That model is built as a substrate; the settlement leg that routes proceeds directly to a catalog payment is founder-gated and money honest-off today. The booster or PTA that runs the a-thon has a first-class console for it.
Is live checkout available today?
No. The compute-and-prove substrate is built: the exact-integer-cents fee engine, the FLOOR, the donor cover-fee decomposition, the exact-sum invariant, and the consent-gated page substrate are built and running. The live checkout — the charge rail that moves money — is money honest-off (founder-gated). There is no pricing commitment, no live checkout, and no live charge on this page. Every dollar that settles today settles to the school.
What is the difference between athon.software and fundraising.software?
fundraising.software is the cross-catalog fundraising product home — the FLOOR economics, the donor cover-fee flow, and the model where a fundraiser’s proceeds fund a real catalog purchase. athon.software is the product home for one specific fundraiser shape: the a-thon and pledge model (jog-a-thon, read-a-thon, fun run), the promise-then-collect mechanic, and the exact-amount-before-any-charge rule. The a-thon builds on the fundraising engine; the two are siblings, not duplicates.
Related surfaces
The a-thon connects to the rest of the school through the shared roster, the fundraising engine, and the booster and PTA console. These destinations cover the adjacent surfaces.
fundraising.software
The cross-catalog fundraising product home: the FLOOR principle, the donor cover-fee flow, and the model where a fundraiser’s proceeds fund a real catalog purchase. The a-thon builds on this engine.
schoolfundraiser.network
The campaign-store sibling in the fleet: the product site for PTOs, booster clubs, and school offices running honest-math campaigns with school-set item catalogs. A sibling surface, not a duplicate of this page.
boosterclub.software
The booster-club and PTA operations home: the surface for the officers who often run an a-thon, manage the treasury, and coordinate volunteers. The booster and PTA console lives here.
homeroom.software
The flagship platform brand home: the full product story and the complete picture of the fundraising substrate and every other module on the platform.
What is built and what is honest-off
The donor cover-fee flow — charge equals gift plus covered fee, the fee computed server-side and disclosed before the charge — is live today. The FLOOR that keeps the school’s fundraising total whole (the platform eats a processing shortfall, never the school) is live today. The consent-gated peer-to-peer student page substrate, with leaderboards that never expose a minor’s identity, is live today. The flat-gift donation flow is live today. The a-thon execution surface — the pledge-per-unit container, the units-recorded entry point, and the resolve-and-charge step — is in early access: it is being built now, and we name that plainly rather than claim it as live today. Live money movement (the charge rail) is money honest-off (founder-gated): the compute-and-prove substrate is built; live charging is not active today, and every dollar that settles settles to the school. No pledge is ever charged before the donor has seen the exact final amount. No competitor brand names appear here. Money, pricing, and checkout are not on this page. No cookies.