Internet Identity intake canister replaces open Discord invites

On October 17, 2026, forum user tkhs-hyt reported that a Motoko canister with Internet Identity login has replaced their community's public Discord invite link, live on mainnet since late August 2026, and received one application in seven weeks. Operators dealing with AI-written spam can copy the design now, and should follow the planned ICRC-2 "pay only on a spam verdict" step before turning on anything paid.

What changed

The thread started on 2026-08-07 as an idea. The October update reports how it works in production.

• The public invite link is gone. Joining goes through an application page. The author notes that Discord's own screening only limits what members can do once inside; the invite link itself stays "public and forwardable", and that is the hole the canister closes.
• Internet Identity at submit time. Applicants choose a reason (join or propose), write a few lines and sign in with Internet Identity when they submit, not before. A human reviews each application from a browser admin panel.
• One-time invite, fetched by update call. In the August prototype write-up, an approved applicant sees a one-time Discord invite on the same page. Nothing is emailed or sent by DM. The link is fetched with an update call because query responses are not certified.
• Status on mainnet. "Live on mainnet since late August 2026." The free types (join, propose) are on. The hold-and-refund paid type from the prototype is "deployed but disabled".
• Result so far. "In seven weeks, one application has arrived. It was LLM-style boilerplate." The author rejected it.

The prototype passed "59/59 locally, including an upgrade test" before launch. The author also lists three problems that turned out harder than cycle-draining update calls, which they handled with inspect and an O(1) counter: an atomicity bug that let confiscate and refund both succeed on the same deposit, a sybil attack that could lock everyone out of the free lane, and the fact that a Discord bot token cannot safely live in a canister. All three are reported as fixed. The code is not public yet.

Who is affected and why it matters

Anyone who runs a Discord, a forum or a contact form that a human reads is the target here. The post cites vendor numbers: 53% of web traffic in 2025 was automated (Imperva), AI-driven bot requests blocked per day on Imperva's network rose from 2 million to 25 million, and the FBI tracked an "AI-related" descriptor for the first time in 2025 with 22,364 complaints and $893 million in losses. It also points to an October 2026 breach of i-ask, a Japanese inquiry-management SaaS, where up to 713,126 inquiry records may have leaked.

The author's conclusions are useful for anyone designing intake on ICP:

1. Internet Identity gives a stable pseudonymous principal to attach a verdict to, but it does not prove a person is behind it. A new anchor is free.
2. While applying is free, a rejection costs the attacker nothing and costs the operator cycles.
3. Judging by writing quality will stop working as models produce plausible histories and portfolios. What remains is cost per attempt.

The design choice that matters most for builders is how the admin roles are split. Review, invites and reversals use an Internet Identity admin roster. Withdrawals, prices and adding admins need the controller identity, which lives only in dfx. A stolen browser session can admit the wrong person but cannot move funds.

What to do now

The next build replaces the held deposit with an ICRC-2 allowance: the applicant approves the canister to take a set amount of ICP, and nothing moves unless the verdict is spam. The author chose this because holding funds would fall under Japan's payment-services regulation. The applicant can revoke the allowance before the verdict, so it deters spam but does not guarantee payment.

If you build a similar intake canister, this checklist follows the post and the ICRC-2 docs:

1. Remove the public invite from your site and serve invites only to approved principals, through an update call.
2. Reject cheap abuse before execution with an inspect check and an O(1) counter, as the author did.
3. Keep money actions (withdraw, set price, add admin) on the controller identity, not the browser admin roster.
4. Make the verdict and any confiscation one atomic state change, so refund and confiscate cannot both succeed.
5. Keep bot tokens out of the canister; the author found they cannot be stored there safely.
6. For the spam-only charge, have the frontend call icrc2_approve with the canister as spender, and set expires_at (nanoseconds since the Unix epoch) past your review window.
7. On a spam verdict only, call icrc2_transfer_from. Handle InsufficientAllowance, because the applicant may have revoked.

The ICP ledger docs show the transfer-from call in Motoko (mo:core, ICP ledger ryjl3-tyaaa-aaaaa-aaaba-cai, fee 10_000 e8s):

let result = await icpLedger.icrc2_transfer_from({
  spender_subaccount = null;
  from = { owner = from; subaccount = null };
  to = { owner = to; subaccount = null };
  amount = amount;
  fee = ?10_000;
  memo = null;
  created_at_time = ?now;
});
switch (result) {
  case (#Ok(blockIndex)) { blockIndex };
  case (#Err(#InsufficientAllowance({ allowance }))) {
    Runtime.trap("Insufficient allowance: " # Nat.toText(allowance))
  };
  case (#Err(_)) { Runtime.trap("TransferFrom failed") };
}

The docs mark this sample "Add access control in production". In an intake canister, only the spam-verdict path should reach it. To test allowances by hand, the docs point to the icp token approve and icp token allowance CLI commands.

The author compares the design to Collab.Land and Guild token gating; here nothing is held and collateral is taken only on a spam verdict.

Caveats

The results come from one unnamed community with one application in seven weeks, so they say little about rejection rates at scale. The traffic and loss figures are vendor and FBI numbers quoted in the post. The paid lane is disabled and the approve-based version is not built yet; the code has not been published or reviewed.