Method

Why a basket travels as percentages, and never as an order list

Two people follow the same basket with different amounts of money. When it rebalances, what exactly does one send the other? Getting this wrong doesn't produce a small error — it produces somebody else's portfolio. This page is the reasoning, with the arithmetic worked out.

01The thing that is actually being shared

A basket can be written down two ways.

As share countsAs target weights
RELIANCE 40
TCS 27
HDFCBANK 58
NTPC 228
RELIANCE 30.0%
TCS 25.0%
HDFCBANK 25.0%
NTPC 20.0%
Only true for one person, at one amount of money, on one day. True for everyone, at any amount, on any day.

Share counts are a result. Weights are the instruction. The moment you send share counts you have sent an answer computed for your wallet, and the recipient has a different wallet.

So a sheet holds weights and reference prices. Your quantities are derived from it, locally, from your own capital. Nobody's share counts ever travel.

02Investing picks an amount. Rebalancing cannot.

These look like the same operation and they are not. They are duals — what is free in one is determined in the other.

First-time buyRebalance
You supplyan amountyour existing holdings
Comes outshare countsthe difference from target
Free to chooseamountnothing
first-time buy      qty    = round(amount × weight / price)

rebalance           value  = Σ (shares you hold × price)      ← not a choice
                    target = round(value × weight / price)
                    order  = target − shares you hold

This is why the workbench offers you multiples of the minimum when you buy in, and offers you no multiplier at all when you rebalance. There is nothing to multiply: your capital is already whatever your holding is worth.

"I bought 2× the minimum, my friend bought 1×. The rebalance is 2× of my holdings. How does his app know to use 1×?"

It never needs to know. He isn't given a multiple of anything — he's given weights, and he applies them to his own value. The multiplier is not transmitted because it is not a property of the basket. It's a property of a wallet, and each wallet supplies its own.

03What happens if you send the order list instead

Worth seeing, because it is the intuitive thing to do and it fails hard. Illustrative numbers: the sample four-stock basket, with a ₹12,554 floor, one holder at ₹4,00,000 (about 32× the floor) and one at ₹80,000 (about 6.4×). The manager moves RELIANCE 30% → 35% and TCS 25% → 20%.

The 32× holder's own orders

RELIANCE  +7      TCS  −5      HDFCBANK  ±0      NTPC  −2

Sent as weights — correct

The 6.4× holder's app sizes those weights to his ₹78,956 and produces RELIANCE +1, TCS −1, HDFCBANK ±0, NTPC −1. He ends up 1.39 percentage points from the manager's target.

Sent as that order list — broken

He holds 5 TCS. The instruction says sell 5. His entire TCS position is wiped out and RELIANCE inflates to 55.3% against a 35% target. He lands 20.26 percentage points off.

Sent asWorst deviation from target
Weights1.39 pp
Share-count orders20.26 pp

The failure is not proportional. A sell sized for a big holding doesn't shrink gracefully against a small one — it goes through zero, and a position vanishes.

04Whole shares are the real enemy

Exchanges won't sell you 0.4 of a share, so every basket is an approximation. The size of the approximation is set by the priciest stock relative to your capital, and it is why a basket has a floor at all. The workbench's minimum is the smallest amount its own rounding can fund:

qty     = round(amount × weight / price)             for every stock, as in 02
minimum = the smallest amount where every qty ≥ 1 and Σ (qty × price) ≤ amount

Below that, a stock gets no share at all or the orders cost more than you typed. Most tools quietly drop the stock and hand you a more concentrated portfolio than you asked for. This one refuses, and says which stock set the floor. On the sample basket the minimum is ₹12,554: 1 RELIANCE, 1 TCS, 2 HDFCBANK and 7 NTPC, costing ₹12,553.40.

The workbench searches for that amount rather than solving for it, because the closed forms were wrong. We shipped max(price / weight) at the start, the point where the binding stock reaches exactly one share, and it overstated the floor — ₹14,809 against ₹12,554 on the sample — and refused amounts that buy a perfectly complete basket. Every other stock rounds down from its fractional target at that point, so the cash you actually need is less. The gap grows with the number of holdings and the spread of their weights.

Rounding those other stocks down and adding up the bill gives a floor formula: round up ( Σ price × round down ( scale × weight / price ) ), with scale = max(price / weight). It reproduces a minimum investment amount smallcase publishes for one of its own baskets — ₹385, from a true cost of ₹384.7156 — to the rupee, and that is the regression test in selfTest(). It is not the amount the workbench refuses below: it rounds every stock down while the orders round to the nearest share, so on a real sheet it can name an amount the orders then overspend, or one well above what they need. On the sample basket it says ₹12,905, ₹351 more than the orders need.

The formula's last step rounds up, and that direction is not arbitrary: a minimum that rounded down would be short of its own basket. Publish ₹384 for a basket that costs ₹384.72 and someone who invests exactly the stated minimum cannot buy it — the same defect as overstating, just a rupee wide instead of ₹2,255. So the inner step rounds down (you cannot buy part of a share) and the outer step rounds up (you must cover the whole bill).

Honest caveat: smallcase documents the definition of its minimum but publishes no formula and no rounding rule. Rounding up is the only self-consistent reading, not a confirmed fact.

How coarse is a basket, exactly?

One share is the smallest move you can make, so the priciest stock's share of the total is the resolution of the whole basket:

resolution (pp per share) = highest price / total value × 100
Your holdingOne share of TCS moves the basketVerdict
₹29,12712.71 ppunusable as a shared sheet
₹1,48,7092.49 ppborderline
₹3,98,0550.93 ppfine to share

At ₹29,127 a position is literally 3, 2, 4, 17 shares. A five point change in target weight produced zero orders — the rounding was larger than the rebalance. Small holdings can't express fine instructions.

05Which means the biggest holder should publish

A sheet reconstructed from real holdings inherits that holder's rounding. Its weights are not the manager's exact intent — they're the closest thing expressible at that wallet size.

Publisher's holdingError baked into the sheet they share
2×2.47 pp
5×0.86 pp
32×0.20 pp
200×0.04 pp

Everyone who sizes that sheet inherits the publisher's error and then adds their own. So the rule is counter-intuitive but firm: whoever holds the most should be the one who shares the sheet. The workbench states a sheet's resolution when it builds one, and says plainly when it is too coarse to pass on.

Is there a fractional multiplier?

Not on the capital, because that would only restate the cash box. "Rebalance at 0.5×" means "withdraw half my value", and rupees are the better unit: you know you have ₹50,000 to add, not that you want 1.15× of your portfolio. It is also ambiguous — half of your current value, or half of the target?

There is a useful fraction, and it scales the orders rather than the capital:

order = round( (target_qty − held) × k )        k = 1.00, 0.75, 0.50, 0.25

Moving part of the way cuts turnover and defers realising gains, at the cost of staying deliberately off target. One exception is hard-coded: a stock the basket has dropped is always sold in full regardless of k. Part-exiting leaves a stub in your account forever, which is worse than either finishing or not starting.

Unsettled shares count as held

Buy in one session and, until it settles, the next session's holdings report quantity: 0, t1_quantity: 9. Read only the quantity column and a rebalance you just executed looks like it never happened, so the next run tells you to buy the whole position again. Both holdings parsers add T1 to the settled quantity.

06State, not events

A rebalance email is an event — "I bought these, I sold those." A sheet is state — "the basket is now this." Events only make sense against the exact state they were computed from, which is why forwarding one to a friend cannot work: his prior state is different.

So the flow is: you apply the event to your state, which yields new state, and the new state is what you pass on.

manager's rebalance email
   ↓ applied to your holdings
your updated sheet  (weights)
   ↓ sent to whoever follows you
their own orders, sized to their own money

What if someone forwards you the email anyway?

It is the obvious thing to do, so the workbench checks for it. A rebalance email's quantities were computed against one specific position, and there are two detectable signatures when it meets a different one:

Without those checks the result is not an error message — it is a plausible-looking basket with a stock missing. A SELL 5 sized for the ₹4,00,000 holding exactly cancels the ₹80,000 holder's entire position, so the stock silently disappears and the sheet claims one fewer holding than the manager published.

One thing the sheet cannot fix. A stock held through two different baskets appears once in your broker's holdings, as one merged quantity. Any per-basket drift calculated from that number is wrong for both baskets. The workbench flags it rather than pretending the number means something.

07What this buys you

sharecase · Open the workbench · Plain-English guide
Not investment advice. Verify every order in your broker before placing it.