Good questions, and I like the money-burning idea: it's honest about what it does.

Feature vector escaping: nodes never store the raw feature vector. The phone sends it over an encrypted link, and the node turns it into a protected (cancelable) template and keeps only that. A stolen template on its own is scrambled numbers. As detailed in the whitepaper, today the key that scrambles them is held by the full nodes (currently the project's own servers), so a compromised node could unscramble its templates back into feature vectors. Never a photo, but a feature vector could in principle be compared with the same model run on a photo of the same person. That is why rotating the key and splitting it across independent operators are next on the roadmap.

Surveillance-video spoofing: enrolment needs a flat palm close to the camera plus a live face check where the app asks for a random movement, which ordinary surveillance footage does not give you. Currently, that liveness check runs in the app, meaning a modified app could theoretically bypass it. Server-verifiable liveness is the next item on the roadmap. What the nodes do enforce already: a palm or face that matches someone enrolled is refused, so a person cannot open a second account with their own body.

Your scheme versus ours: yours makes abuse expensive, which works for spam. We went for one account per person regardless of money, because the same accounts vote on the network's rules, and with a price per account whoever can pay most gets the most votes.

(I'm one of the developers.)

Thanks, this is a useful critique.

On the keep-alive idea: SOV has something close to it. Every citizen appoints guardians, and if a key is lost or stolen, two guardians approving within 72 hours make the nodes re-key the account, so the old key can no longer spend. Your extra step, warning the people who dealt with the old key after the alert time, is a good idea and I'll take it to the roadmap discussion.

On spoofing: enrolment is a palm scan plus a live face check, both on your own phone, and the nodes refuse any palm or face that matches someone already enrolled. So a printed copy of an enrolled person's palm cannot open a second account. What you describe, a fabricated capture at enrolment, is the real attack, and the whitepaper says so plainly: liveness is checked in the app today, not by the nodes. Server-verifiable liveness is next on the roadmap (section 10).

Eye-movement video with a moving target is a good liveness idea, and your point about camera quality is exactly the trade-off: the live face check today runs on an ordinary phone front camera. Either way, no photo or video of your palm or face is ever stored or sent; the app turns each scan into a set of numbers and the nodes keep only protected templates.

Whitepaper: https://sov-network.github.io/whitepaper.html (I'm one of the developers.)