Marty: the answer has to cover what a member is risking when they send POL to somebody they have not spoken to and have no commitment from. The canned answer now leads the advice with "do not send anything until you have actually talked to that person and they have told you they will use it", then says plainly: the transfer is wallet to wallet and irreversible, there is no refund and no chargeback, support cannot pull it back, the gift is theirs whatever they do with it, and they are free to go quiet or spend it on something else without breaking any rule. It names the worst case for what it is, which is that a tank member joined with nobody working with them and may never have engaged, so an unanswered PIF is the easiest money on this site to lose. It gives the arithmetic both ways rather than only the upside: a gift that works costs about half, because the contract pays the sponsor 50 percent when they buy; a gift to someone who never answers costs all of it. It ends on never gift money you need and never borrow to do it. The same guidance goes into the AI prompt as a standing rule, so PIF is never sold as a tactic on any phrasing that misses the canned pattern, and a "should I PIF someone from the tank" question starts with talk to them first, not the mechanics. qa/chatbot-parse.mjs is now 16 assertions: the 9 response-shape cases plus 7 that pin each risk line, so a future rewrite cannot quietly drop them. qa/run.sh member: 0 bugs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
InstantAdPay — site
Membership advertising with immutable on-chain settlement. Zero-dependency Node server (RM Circle pattern): static pages + JSON API + SSE ledger.
Architecture
server.js— http server: pages,/api/*,/join/<id>sponsor links, SSE feedchain.js— contract reader + persistent event indexer (free public RPCs)auth.js— SIWE wallet sign-in (EIP-4361), sessions in the volumeaccounts.js— site-side records only (free members, last-touch sponsor attribution, handles). The CHAIN is the source of truth for money/credits.public/— landing, live ledger, member area; no client libraries
Chain flip (rehearsal → mainnet)
Everything chain-specific lives in data/config.json (volume):
{contract, chainId, chainName, explorer, rpcs, deployBlock}.
Defaults point at the Amoy rehearsal deployment. Launch = deploy the
mainnet contract, wipe accounts.json/sessions.json/chain-index.json,
PATCH /api/admin/chain with the mainnet values, set rehearsal:false via
/api/admin/site. Same code, different config.
Run
PORT=3100 node server.js # DATA_DIR defaults to ./data
Admin API auth: Authorization: Bearer $ADMIN_PASSWORD.
Spec: ../CONTRACT-SPEC.md (v1.0.3-frozen). Contracts: ../contracts/.
Chatbot knowledge is part of every change
chatbot.js answers members two ways: CANNED regex answers and systemPrompt() for the AI. Any
change that a member could ask about (a new pane, a rule, a price, a limit, a fix they noticed) is not
done until both are updated in the same commit, and KNOWLEDGE_DATE in chatbot.js is bumped. The QA
runner (bash qa/run.sh public) fails when a release note on the live site is newer than that date.