The Wecap refer code looks like a static asset. It looks the same on the day you generate it, on the day you share it, and on the day the referee enters it. The behaviour is not static. The cap, the validity window and the eligibility check are recalculated at the start of every calendar month, and they reset at midnight IST on the first. A reader who treats the code as a coupon is reading last month's terms.
The cleanest habit is to read the in-app Refer & Earn screen on the morning of the first. Two numbers matter: the cap for the month and the validity window for chains started during the month. A third number, the per-referee KYC status, is the one most readers check too late. None of the three numbers appear on the App Store listing, on the operator's marketing emails, or on any editorial surface outside the screen.
What follows is the primer the desk uses to read those three numbers, month by month, with the rules that stay flat through a full season called out separately from the ones that move. Nothing in it requires anything more than the Refer & Earn screen, a calendar, and the patience to read the screen on the first rather than the fifteenth.
What the code is, and why a calendar sits behind it
The Wecap refer code is a signed string the operator issues once your account clears identity verification. It is bound to your verified PAN and to the device that signed up first. The string itself is constant: the same five-to-eight characters live in your profile until you close the account.
What sits behind the string is a calendar, not a coupon. The cap on monthly referrals resets at 00:00 IST on the first of every month. The validity window during which a new chain can be started is republished on the same screen on the same day. The referee status list is recomputed at the moment a new referee clears KYC. None of these move mid-month under normal operation; all of them can move at the boundary.
The reason this matters is that a reader who treats the code as a coupon discovers the calendar only when a chain expires mid-attribution. The reader who treats the calendar as the contract reads the screen on the first and plans the month's broadcast around whatever cap and window the operator has just published. Two readers, same code, very different payout records.
Strong evidence that the calendar is the binding factor would be a controlled test of the same chain run inside and outside a published window. The desk treats the absence of a screen read on the first as a sufficient explanation whenever a chain stalls past its window.
What changes at the monthly boundary
Three numbers move at the boundary. Each one is published on the in-app Refer & Earn screen on the morning of the first, and each one is the only authoritative value for the rest of the month.
The first number is the cap. The operator publishes a soft cap on the total reward a single referrer can earn in a calendar month. The cap can move up, down or stay flat at the boundary. A reader who shared the code to a fifty-person WhatsApp group on the day they crossed the cap produces fifty chains that never pay out for that month, and they do not carry forward. The screen publishes the new cap on the first; the chat can wait.
The second number is the validity window. The window is the number of days inside which a referee must complete KYC and enter a paid contest for the chain to pay out. The window can shorten, lengthen or stay flat. A window that shortened mid-month produces chains started under the old window but completed past the new boundary, and the rule for those chains is whichever window was published at the moment of share. The screen publishes the new window on the first; the share can wait.
The third number is the per-referee KYC status. The Refer & Earn screen carries a list of referees and a chip per referee, with one of four states: pending verification, KYC submitted, KYC approved, contest entered, and rewarded. The chips are recomputed at the moment a referee clears each gate. The chips do not expire; they sit in their last-known state until the referee acts again, or until the chain expires on the validity window.
A reader who plans the month around these three numbers reads the screen on the first, drafts the broadcast against the cap and the window, and times any bulk share for the morning rather than the evening. A reader who ignores the calendar ends up asking customer care why a chain did not credit.
What stays flat through a full season
Three rules do not move at the boundary. They sit underneath the calendar and apply to every chain in every month. The desk habit is to call them out explicitly, because the reader who assumes they have changed usually discovers the assumption only when a chain breaks.
The first flat rule is one account per PAN. The operator binds every referrer to the verified PAN at the moment of sign-up, and binds every referee to theirs at the moment of first referral sign-up. A reader who tries to share from a second account on the same PAN produces a chain that does not attribute, regardless of the cap or the window. The rule is enforced silently; no chip on the Refer & Earn screen announces it.
The second flat rule is one account per device. The operator binds the chain to the device used at sign-up, and reads the same device fingerprint at the moment the referee enters the code. A referee who installs the app on a different device from the one the code was sent to, or pastes the code into a different browser before entering the phone number, produces a chain that sits in neither account. The rule applies in every month; it does not change at the boundary.
The third flat rule is the in-app Refer & Earn screen as the single source of truth. The cap, the validity window, the per-referee chips, and the per-referee KYC state all live on that screen. The App Store listing carries a marketing summary, not a policy. The operator's emails carry promotional language, not a cap. The editorial site carries the explanation behind the policy. The screen is the contract. The other surfaces are commentary.
A reader who treats the flat rules as the foundation, and the monthly numbers as the operating conditions, reads the program the way the operator writes it. A reader who inverts the two and treats the marketing summary as the source reads the program the way the marketing department wishes the operator had written it.
A counterfactual across one cycle
Take two readers with the same code, same PAN, same device, same Permitted-state address. The first reader shares the code on day two of the month to a small group of friends, all of whom complete KYC and enter a paid contest within the validity window. Every chain pays out. The cap is not crossed. The cycle ends with the referrer sitting at the cap, no overflow, no stranded chains.
The second reader waits until day twenty to share. The cap is still in place from the first of the month, but the validity window for chains started on day twenty is shorter than it was on day two. Most chains finish inside the new window. One chain finishes past the window. The cap is not crossed, but the reader has lost one payout to the calendar, not to KYC, not to the referee, and not to the operator.
Now run the same two readers into a month where the cap drops at the boundary. The first reader, who shares on day two of the new month, fits inside the new cap and pays out in full. The second reader, who shared at the end of the old month, suddenly finds that the cap they planned against no longer applies. The screen on the first published a new number. They did not read it.
Strong evidence that the calendar is the binding factor would be a comparison across two readers who share the same code and the same referee pool but plan against different monthly reads of the screen. The desk treats the absence of a screen read on the first as a sufficient explanation whenever a chain stalls past the window. A reader who disagrees should look for evidence first in the screen, and only escalate to support if every read on the first has happened and the chain still does not form.
How the referee status chips move
The Refer & Earn screen carries five chip states per referee. Each one is a normal milestone. Each one is computed at the moment the referee acts. Reading the chips correctly is the difference between watching the chain move and waiting for a payout that is already locked.
The first chip is pending verification. It appears the moment a referee enters the code at sign-up. It stays put until the referee submits PAN, or until the chain expires on the validity window. A chip that sits in pending verification past seventy-two hours is almost always stalled on the referee's KYC step, not on a chain failure.
The second chip is KYC submitted. It appears the moment a referee submits PAN and Aadhaar. It stays put until the operator's verification completes, or until the chain expires on the validity window. A chip that sits in KYC submitted past seven days is worth a customer care ticket, with the referrer's user ID and the referee's phone number at the top of the message.
The third chip is KYC approved. It appears the moment the operator's verification completes. From this point, the chain can unlock the moment the referee enters a paid contest inside the validity window. The chip does not announce the unlock; the unlock happens at the next contest entry.
The fourth chip is contest entered. It appears the moment the referee enters any paid contest inside the validity window. From this point the reward is committed. The fifth chip, rewarded, appears at the moment the reward credits to the referrer's wallet. Most chains move from contest entered to rewarded within twenty-four hours.
Reading the chips in order, with the screen open, removes most of the friction that produces an "I signed up, where is my reward?" follow-up. The chain is moving. The chip is moving. The reader is reading.
How to read a quiet policy shift
Most operator policy shifts on the Wecap refer code happen at the monthly boundary without a press release. The cap moves. The validity window moves. The per-referee eligibility rules, on the rare month they move, do so on the same screen on the same day. A reader who treats the in-app Refer & Earn screen as the announcement catches every shift, because the screen is the only surface that publishes the new numbers.
The shift that surprises most readers is a cap that drops at the boundary. A referrer who shared to a fifty-person group at the end of the old month, and saw no issue, opens the new month to find a smaller cap. The chains they started in the old month stay paid under the old cap. The chains they start in the new month are capped at the new number. The screen on the first told them. They did not read it.
The shift that surprises fewer readers is a validity window that lengthens. A longer window produces more chains that pay out, not fewer. The reader who plans around the screen on the first picks up the longer window automatically. The reader who plans around last month's window discovers the new number at the moment of share.
The shift that almost no reader catches is a per-referee eligibility rule that moves. The operator occasionally adjusts the list of permitted states, or the rule for how a referee on a banned device list is treated, at the boundary. The change is published on the screen on the first. A reader who has not read the screen is surprised when a referee signs up and the chain does not form.
The desk habit is to assume that every number on the screen on the first is a number that has been republished, not a number that has been carried forward. The habit costs thirty seconds at the start of every month. It saves hours of customer care tickets later.
What to do on the morning of the first
The morning of the first is the cheapest moment in the cycle to read the screen, plan the broadcast, and write down the numbers. A reader who does the three things in the first ten minutes of the day has, in effect, written the operating manual for the rest of the month.
Open the in-app Refer & Earn screen. Note the cap. Note the validity window. Note the per-referee eligibility rules. Write the three numbers into a notes file, with the date at the top. The notes file is the operating manual for the month. It is also the audit trail when a chain does not pay out and the reader needs to ask whether the policy was the policy at the moment of share.
The second habit is to draft the broadcast against the cap and the window. A reader who knows the cap is fifteen referrals in the new month plans the broadcast to land at twelve or thirteen, leaving slack for a late referee who finishes KYC in the last week. A reader who knows the validity window is twenty-one days plans the broadcast to land in the first ten days of the month, leaving slack for a late referee who finishes the paid contest on day nineteen.
The third habit is to tell the referee, before they install, that the chain unlocks the moment they finish PAN and enter one paid contest inside the validity window. The cleanest phrasing is the one that names both gates. A referee who understands both gates asks better questions on day two. A referee who does not understand either gate asks the referrer to debug a chain the referrer cannot see.
Where this primer sits next to the desk checklist
This primer is the temporal companion to the desk verification checklist. The checklist covers the six checks before the first share: KYC, state eligibility, code reload, channel reachability, referee state, and the paid-contest gate. This primer covers the three numbers that move at the monthly boundary: the cap, the validity window, and the per-referee eligibility rules. Together, the two pieces describe the same program from two angles. The Refer Code page on the desk site carries the structural explainer that sits behind both.
The Refer Code page lists the program structure, the eligibility milestones, the common pitfalls, and the FAQ. It is written to be read alongside this primer. A reader who treats the screen as the contract, the checklist as the pre-share audit, and this primer as the monthly operating manual reads the program the way the operator writes it.
What changes when the calendar flips
Two things will move at the next monthly boundary: the cap and the validity window. The cap can move up, down, or stay flat. The validity window can shorten, lengthen, or stay flat. A reader who has done the morning-of-the-first read should re-do it on the morning of the first, every month, because the cap and the validity window are the two numbers most likely to have changed.
The single watch the desk keeps is the cap. A cap that drops at the boundary is the most common source of stranded chains, because the broadcast at the end of the old month cannot anticipate the new cap. A reader who plans around the morning-of-the-first read picks up the new cap on the first day of the new month and avoids the stranded chains altogether.
The implication is straightforward. The monthly cycle is a calendar, not a coupon. The flat rules live underneath the calendar. The monthly numbers live on top of it. The reader who treats the calendar as the contract reads the program the way the operator writes it; the reader who treats the marketing summary as the contract reads a different program, and discovers the difference at the moment of payout.