DEV Community: Prashant Chaudhari

Seven checks: verifying an AWS Nitro attestation in the browser

Prashant Chaudhari — Wed, 04 Nov 2026 07:32:37 +0000

My server says an enclave scored this borrower. The verify page checks that claim itself, against AWS's signature and Solana, without trusting my server. Seven checks, and where the obvious code would have been wrong.

I'm building TEE Income Oracle. It reads a borrower's bank statement inside a sealed-off part of an AWS server, works out a credit tier (A, B or C), signs it, and writes it to Solana devnet. A lending pool reads the tier there before it lends.

That sealed-off part is an AWS Nitro enclave: an isolated machine that nobody, including me as the operator, can log into or look inside while it runs. That's the point of using one. The bank statement goes in; only the tier comes out.

But a lender has no reason to take my word that the tier came from an enclave, or that the enclave runs the code I published. So the enclave can produce proof, called an attestation document. AWS's hardware signs it, and it says two things: which code booted, and which signing key the enclave created for itself. If the document checks out, a tier signed with that key came from that code.

The proof only helps if someone other than me checks it. So I wrote a verifier, a TypeScript library that also runs in the browser, on the app's verify page. You give it a borrower's wallet, it reads Solana directly, and it runs seven checks on that borrower's tier. It doesn't take my server's word for anything.

This post is for developers who have heard of enclaves or "verifiable compute" and want to see what checking one actually involves. You don't need to know AWS Nitro, or any cryptography beyond "a signature proves who signed some bytes". I'll explain the rest as it comes up.

What this post covers:

What's inside an attestation document, and how a tier on Solana leads back to one.
The seven checks, in plain words.
Four places where the obvious code would have been wrong: checking a re-packed copy instead of the signed bytes, rejecting a genuine AWS signature, failing every document a few hours after it was made, and a code fingerprint that changes when you edit a comment.
A gap in the verdict that had nothing to do with cryptography.
Why the browser checks a copy of the document, and why that's still safe.
What a pass doesn't prove, and a checklist if you verify attestations yourself.

What's inside the document

The document is a small binary file. Inside is a set of named fields, stored in CBOR, a compact binary format that does for binary data what JSON does for text. AWS signs that data and wraps it, with the signature, in a standard envelope called COSE_Sign1 (AWS describes the format here). Four fields matter for this post:

Field	What it means
`pcrs`	Fingerprints of what booted. Each PCR (platform configuration register) is a hash of one part of the software
`certificate`, `cabundle`	The certificate whose key signed the document, and the chain of certificates that links it back to AWS
`timestamp`	When the document was made
`public_key`	A key the enclave generated when it started. My enclave signs tiers with it

My enclave runs on Marlin Oyster, a service that rents out Nitro enclaves. Oyster boots its own fixed base system, then starts my app from a docker-compose.yml file. PCR0, PCR1 and PCR2 fingerprint the base system. PCR16 fingerprints my compose file. Hashed together, those four give an image id: one value that names one exact build of the enclave.

On Solana, a registry keeps one entry per enclave build: its image id, its signing key, a hash of its attestation document, and whether it has been retired. So from a borrower's wallet, the verifier can follow a chain back to AWS's hardware:

the wallet's tier on Solana,
the registry entry for the build that signed it,
that build's attestation document,
AWS's signature on that document.

The seven checks

#	Check	What it asks
1	Signed by AWS Nitro hardware	Is the signature valid, and does its certificate chain end at AWS's root?
2	Marlin's published base image, not debug mode	Do PCR0–2 match Marlin's published values? (Debug mode zeroes them.)
3	Runs our published code	Does PCR16 match the compose file at the release tag?
4	Image id matches the registry	Do the four PCRs give the image id the registry recorded?
5	Enclave key = on-chain attester	Is the document's key the one the registry says signs tiers?
6	Same document the registry recorded	Does this document's hash match the one stored on Solana?
7	Entry is active	Is the registry entry still active, and for the same type of proof as the tier?

The verifier runs all seven even after one fails, so a bad document shows everything wrong with it at once.

AWS's root certificate, where every chain must end, is built into the verifier. It's never downloaded, because a verifier that downloads its root trusts whoever answers the download. A test checks the built-in copy against the fingerprint AWS publishes.

1. Check the bytes that were signed, not a re-packed copy

A signature covers exact bytes. Two files can hold the same data and still differ byte for byte, and then the signature fits only one of them.

That's the trap here. CBOR can store a set of fields in two ways: with the number of fields written at the start, or with an "end" marker after the last one. Nitro uses the second way. A CBOR library reads it fine, but when it packs the data back up, it uses the first. I tried it on one of my archived documents: its signed data, 4,478 bytes, became 4,477, and AWS's signature no longer matched.

So the verifier decodes the data only to read its fields. It checks the signature over the bytes exactly as they arrived.

The same rule applies to the certificates. A certificate's signature covers one section of the certificate, and the verifier checks that section exactly as it appears in the file, never a version it decoded and packed again.

My tests nearly missed this. AWS's real certificates use DER, the strict standard encoding for certificates, so re-packing gives back the same bytes and both approaches pass. My AI code reviewer asked for a test that tells them apart. It takes a real certificate and writes one length field the long way round: the same certificate, but different bytes, and not the bytes AWS signed. A verifier that re-packs turns it back into the signed bytes and accepts it. One that checks the bytes as received rejects it, as it should.

So re-packing fails in both directions: it rejects genuine documents, as the CBOR example shows, and it accepts bytes nobody signed.

2. A genuine AWS signature my library rejected

The signature scheme here, ECDSA, has a quirk: every valid signature has a twin. From one valid signature, anyone can compute a second, different one that's also valid. Blockchains such as Bitcoin and Ethereum accept only one of the two, called the "low-S" form, so a transaction can't be given a second id. Standard ECDSA has no such rule. The library I use, noble-curves, applies it by default anyway.

AWS has no reason to follow a blockchain rule, and a standard signer produces the other twin about half the time. One of my three archived documents has it, so with noble's default settings, a genuine AWS signature failed. With lowS: false, it passes. I checked both on the real document. The verifier uses the same setting for the certificate signatures in the chain.

// sigStructure wraps the payload bytes exactly as they arrived.
const valid = p384.verify(
  cose.signature,
  sha384(sigStructure(cose)),
  publicKeyPoint,
  { lowS: false, prehash: false },
);

Turning that rule off is safe here. The rule matters where a signature works as an id, like a transaction id. Here, the registry stores the hash of the whole document, signature included, so a copy carrying the twin signature fails check 6.

3. Check the certificates as of the document's date, not today's

Certificates expire. AWS's guide says to check that today's date falls inside every certificate's validity period. That's right when you've just asked a running enclave to prove itself.

My verifier checks archived documents, and the certificate that signs each one is valid for only about three hours. When I checked against today's date, all three archived documents failed. The oldest is from 2026-10-08, and some certificates in its chain had already expired. Checked against today, every verification would fail a few hours after the document was made.

So the verifier checks the certificates as of the document's own timestamp:

const leaf = verifyChain({
  leaf: document.certificate,
  cabundle: document.cabundle,
  pinnedRoot: AWS_NITRO_ROOT_DER,
  atMs: document.timestampMs,
});

That gives something up: the check no longer shows the document is recent. So that has to come from Solana instead. The document's hash was stored in the registry when the build was registered, right after a live check of the running enclave, and check 6 compares against it. The entry must also still be active (check 7). When the enclave restarts, it creates a new key and gets a new entry. By default, my rotation script then retires the old entry, and tiers it signed stop passing.

I've made one exception. The devnet enclave stopped around 2026-10-22, and I believe the old machine and its key are gone, so I kept its entry active for the demo. That's an accepted risk, not a proof, and I plan to retire the entry once its last tiers are past their 30-day limit.

4. A code fingerprint that changes when you edit a comment

Check 3 is what ties the running enclave to code anyone can read. Oyster computes PCR16 from the full text of the compose file it started from (the recipe is a few lines of hashing). Every byte counts, including comments and the newline at the end. Fix a typo in a comment, and the fingerprint no longer matches the running enclave.

Two things follow. The compose file names my app's container image by its digest, a hash of the image itself, so the text points at exact code rather than a tag that can be moved. And the verifier reads the compose file from the build's release tag, not from the main branch, because main keeps changing. The deployment record stores the tag for exactly this reason.

5. Seven passes weren't the verdict

My first version printed PASS when all seven checks passed. My AI code reviewer found the gap, and it had nothing to do with cryptography.

The seven checks prove that the registry entry is genuine. They don't prove that the tier went through it. Other accounts can write records that look like tiers. What makes a tier trustworthy is who wrote it. The oracle program checks the enclave's signature before it writes a tier, and it always writes from one fixed address that only the program controls. A tier written from any other address never went through that check, however genuine the registry entry it points to.

The first version even showed "UNEXPECTED signer" on screen, and still printed PASS. Now the writer is part of the verdict:

export function verdictOf(
  checks: Check[],
  attestation: Pick<AttestationFacts, "signerOk">,
): Verdict {
  const allChecksPass = checks.every((check) => check.status === "pass");
  return attestation.signerOk && allChecksPass ? "PASS" : "FAIL";
}

The same review gave me a rule I now follow everywhere: never trust a value you can work out yourself. The verifier computes the program's fixed address from the program's id instead of reading it from a config file, and it checks that the program ids in the deployment file match the ones built into the app.

6. Why the browser checks a copy

The enclave serves its attestation over plain HTTP. A page loaded over HTTPS can't fetch from plain HTTP: browsers block it as "mixed content".

So the verify page ships the archived documents as part of the site, loaded only when needed. That sounds like "trust my copy", but it isn't. AWS signed the document, and its hash is stored on Solana. A changed copy fails check 6. It doesn't matter who delivers the bytes.

I also dropped a planned option to fetch the document live from the enclave. Oyster's attestation server signs a fresh document for every request, so a live document never has the same hash as the archived one on Solana. A live document can confirm the key and the image id, but it can't replace the archive.

What a PASS doesn't prove

That the code is correct. A pass proves which code ran, not that the code is right. Nothing has been audited yet.
That registration was honest. An admin key registers each build after checking its document off chain. Every registration is public, but someone holding a stolen admin key could register a key whose document would still pass. Beyond the demo, that should be a multisig, and later Solana itself should check the document.
That a lender should accept the tier today. A pass says where the tier came from. Whether it has expired, and whether it meets a pool's rules, are separate checks.
That the bank data was real. The demo bank is a sandbox: it speaks the real protocol, with demo keys.
That the RPC node told the truth. The page reads Solana through the public devnet endpoint and takes its answers as given.
That a retired machine's key is really gone. One build's entry stays active although its machine stopped (see section 3). If that key had leaked, tiers signed with it would still pass.

If you verify attestations yourself

Check the signature over the bytes you received. Decode only to read fields; never re-pack before verifying. Write a test with an unusual but valid encoding, because real data won't catch the mistake.
Expect signatures in the "high-S" form if your ECDSA library rejects them by default, on the certificates as well as on the document.
Decide which date you check certificates against. Today, for a live attestation. The document's own date, for an archived one, and then show it's still current some other way.
Build the root certificate into your code. Don't download it.
Read measured files from the release tag. A fingerprint of a text file changes with every byte.
Check who wrote the claim, not just what it points to. Seven green checks on the wrong writer is still a fail.

The verifier is about 1,600 lines of TypeScript. It doesn't use the browser's built-in crypto API, so the same code runs in Node and in the browser: verifier/. The verify page runs it in your browser.

Originally published on prashantchaudhari.dev.

The browser doesn't trust the server: a Solana frontend that checks its own backend

Prashant Chaudhari — Sat, 31 Oct 2026 11:00:00 +0000

My server can tell the web page that a borrower got credit tier A. The page doesn't show it until Solana agrees.

That sounds like paranoia about my own code, so here's the context. I'm building TEE Income Oracle. A borrower's bank statement is scored inside a secure enclave, the enclave signs a credit tier, and the tier is written to Solana, where a lending pool reads it before it lends. Between the browser and all of that sits a server I wrote, the gateway. It talks to the enclave, streams progress to the page, and pays transaction fees so a demo wallet needs no SOL.

The whole product claims that a lender doesn't have to trust me. If the page repeats whatever my gateway says, that claim stops at the page. So the page treats the gateway as a messenger: it can carry bytes, but it never becomes the source of anything the page calls verified.

This post is for frontend developers building on Solana. You know transactions, signatures and RPC calls; you don't need to know anything about enclaves. It walks through five places the page checks its own backend, each as the shortcut, what can go wrong with it, and what the page does instead. The page still trusts two things, the RPC node it reads from and the code I serve it, and I'll come back to both at the end. Every link points to release v0.5.5.

1. Sign your own copy

Before scoring starts, the borrower signs a short text that ties the session to their wallet. It's a plain message signature, the kind a wallet's signMessage produces, not a transaction:

tee-income-oracle: bind session
session: <session id>
wallet: <borrower's address>
policy: <policy hash>
expires: <unix seconds>

The policy hash identifies the scoring rules the enclave will apply; each pool says which policy it accepts.

The shortcut: the gateway sends this text, the page passes it to the wallet, and the wallet signs it.

What can go wrong: the gateway now holds the pen. Whatever it puts in that text gets signed: a different wallet, an expiry next year, a policy no pool lends under. In the demo the wallet lives in the browser tab and signs without a prompt, so nobody reads the text first.

What the page does: it writes the text itself and compares it with the gateway's copy. It signs only when the two are identical. The comparison is the defense. The enclave wrote that text from the wallet and policy my gateway asked for, and it checks the signature against that text, so its copy is only as honest as the gateway's request. The wallet line comes from the page alone. The other values come from the gateway, so the page can only hold them to rules: the session id must match the session the page will submit under, the policy must be one a listed pool lends under, and the expiry must fall within the next ten minutes (plus a minute for clock skew). A gateway can still choose the session and the policy within those rules. It can't get a signature for anything else. (intent.ts)

This isn't a quirk of my setup. @solana/kit, Solana's JavaScript library (formerly released as web3.js 2.0), makes the same argument from the other side in its documentation for signing off-chain messages: a valid signature from a wallet proves little until you've also confirmed it covers the message you meant to have signed.

2. Check that the signature you got back is yours

To borrow, the page builds a transaction and the borrower signs it. The gateway's relayer pays the fee, so it signs too, sends the transaction, and returns its signature. The page polls that signature until it's confirmed.

The shortcut: take the returned signature, wait for "confirmed", show "borrowed".

What can go wrong: every confirmed transaction has a signature. A buggy or hostile relayer could hand back one from an earlier borrow, or from someone else's, and the page would celebrate a loan that never happened. Reading the loan account afterwards helps, but on public RPC that read can come from a node that's behind.

What the page does: on Solana, a transaction's id is its first signature, and the first signature belongs to the fee payer, signed over the transaction's message bytes. The fee payer here is the relayer. So the page checks that the returned id is a valid relayer signature over the exact bytes it built. With Kit, that's a decode and a verify:

async function isOurTransaction(
  wire: Uint8Array,
  returnedId: string,
  relayerKey: CryptoKey,
): Promise<boolean> {
  const { messageBytes } = getTransactionDecoder().decode(wire);
  const signature = getBase58Encoder().encode(returnedId);
  if (!isSignatureBytes(signature)) return false;
  return verifySignature(relayerKey, signature, messageBytes);
}

Solana's guide to partial signing gives a similar rule to whoever assembles a transaction from several signers: before you submit, make sure each signature you collected is over the message you froze. The page applies it from the other end, after submission, to the one id that comes back. A signature over any other message fails, so the id is tied to these exact message bytes. (The excerpt is condensed from isOurTransaction in use-loan.ts.)

That still isn't complete replay protection. Ed25519 signatures are deterministic: the same key signing the same bytes always gives the same signature, so two identical transactions have the same id. The chain is safe either way: validators drop a transaction they've already processed, so nothing executes twice. The risk is to what the page believes, and it takes four steps:

The borrower borrows, and it confirms.
The borrower repays. The page refuses to borrow while a loan is open, so a repay has to come first.
Within about a minute, while the blockhash is still valid, the borrower borrows the same amount again, and the RPC node hands back the same blockhash. Blockhashes change every slot, so this takes a node that is lagging or lying, but it's the node the page asks.
The bytes are identical, so the id is too. Validators drop the second transaction as already processed, yet its id shows as confirmed because the first borrow confirmed. The relayer doesn't have to lie for this. The page reads the loan account after confirmation, but that read has no lower bound on freshness, so a node still showing the first loan lets it through.

3. Show what the chain says, not what the server says

When scoring finishes, the gateway streams the result: the tier, and the payload it says the oracle wrote to Solana. The payload is the signed part of the on-chain record, including the tier, the policy, the statement dates and the enclave build that scored it.

The shortcut: show the tier straight away, and read the chain for extra details. My first version did this. My AI code reviewer described it as the gateway's word with a seal on it.

What can go wrong: the page looks verified while showing an unverified value. My first fix had a subtler hole. It matched the chain record to the gateway's report by timestamp, then kept displaying the gateway's tier. A gateway could relay a real tier C record and report tier A with the same timestamp. The timestamps match, and the page says A.

What the page does: it shows "reading your tier back from Solana…" until the payload on chain matches the reported payload, field by field. It then displays that payload and the record's expiry, both as read from Solana. If a payload at least as new as the report differs in any field, the page shows an error. That doesn't prove the gateway lied, because the oracle lets a newer record replace an older one, but the chain no longer confirms the report, so the page fails closed. (borrow-view.ts)

The same mistake hid in a smaller place. A "registered on Solana" chip was fed by a gateway endpoint. Now only a read of the on-chain registry can say "registered". The gateway still moves the page from one step to the next, and it supplies the link to its transaction. It never supplies a value the page shows as fact.

4. A "valid" badge is a promise about the program

The loan page shows a badge for the borrower's tier against a pool: valid, stale, expired, policy mismatch and so on.

The shortcut: check the rules that seem important. My first version did that, and the same reviewer found four of the pool's checks missing. The badge could say "valid" about a credential the program would reject.

What the page does: it runs every credential check the pool program runs, in the program's order:

the record was written by the oracle,
it hasn't expired,
the pool lends to this tier at all,
it was scored under the pool's policy,
it's fresh enough (how old the record is, how old the bank statement is, and how many days it covers),
the enclave build that scored it is approved by the pool and not revoked.

The order matters because the badge names the first check that fails, and that should match what the program would say about the same credential. (credential.ts, borrow.rs)

Even then, "valid" makes a narrow promise: the credential passes this pool's checks at the state and time the page read. A borrow can still fail for reasons outside the credential: the amount is over the tier's limit, there's already a loan in this pool, the vault is short, a token account is frozen, or the state changes before the transaction runs. The funders' loan book, a page that lists every open loan, runs the same function for every borrower, so "fresh" there makes the same narrow promise.

Choosing which checks to run is a product decision too. Repay first sat behind the same "is your tier valid?" gate as Borrow, which locked a borrower with a stale tier out of repaying, and repaying needs no tier at all. Repay now has no tier check in front of it.

5. The RPC node is a server too

Reading "from the chain" really means reading from an RPC node, which is someone else's server. Two things went wrong there.

A node one step behind. Public devnet RPC is load-balanced, so the read right after a confirmation can land on a node that hasn't caught up. The tests didn't catch this; a manual run on the live site did. After a repay, the page read the pool and saw the loan was gone. Then the data layer fetched again, hit a lagging node, and the closed loan came back on screen.

The fix has two parts. The read-back retries a few times, and it reads the pool, its vault and the loan in one call, so all three come from the same node. Then the read that proved the change goes straight into the cache of TanStack Query, the page's data layer, and any fetch already in flight is cancelled, so it can't overwrite it:

await queryClient.cancelQueries({ queryKey: poolKey });
queryClient.setQueryData(poolKey, provingRead);

That fixes the race I saw, and no more. A later refetch, say when the tab regains focus, can still hit a lagging node. Solana's RPC has a parameter for the general case, minContextSlot. Account reads such as getMultipleAccounts return the slot they were evaluated at in context.slot. Keep the highest slot you've accepted, pass it as minContextSlot on later reads with the same commitment level, and a node that hasn't reached that slot returns an error (code -32016, "Minimum context slot has not been reached") instead of older data. The page doesn't do this yet.

A reply that's one short. The funders' loan book asks for up to 100 accounts per call and matches each reply to its request by position. Nothing checked the reply's length. The RPC spec says a node returns one entry per address, with null for an account that doesn't exist, but the page took that on trust. A node, or a proxy in front of one, that returned 99 accounts for 100 addresses would shift every row after the gap, and show one borrower with the next borrower's "fresh" badge. Now a reply of the wrong length is an error (rpc.ts). So is a duplicated loan row, which would inflate every total, and so is a record that doesn't name the borrower it was fetched for. One bad row fails the whole book (use-book.ts), because a partial book presented as the book is worse than an error.

Where the trust actually stops

None of this makes the page trustless:

It reads one RPC node. It checks what's cheap to check: reply lengths, account sizes and types, which wallet a record belongs to, and signatures over bytes it built. A node that invented consistent data could still fool it.
"Confirmed" also comes from that node. The signature check proves the id belongs to the bytes the page built; the node still reports whether they landed.
I serve the page. A different build could skip every check. That's why the source is public at release tags, and why the receipt checks also run from a command line.

What the checks do buy: my gateway is no longer the only authority for a tier, a loan or a registration. The page checks each of those claims against what an RPC node returns, and most gateway bugs now show up as an error on screen instead of a wrong number. The limits above still apply: a stale read, or a reused identical transaction, can get past these checks.

A checklist for your own frontend

Rebuild anything the user signs from data you already hold, and sign your copy.
Treat a signature from an API as a claim. If you built the transaction, verify the signature over its bytes. It ties the id to those bytes; it doesn't stop an identical transaction being reused.
Show values from a chain read, not from the API that triggered the write. Compare every field of the reported payload, display the chain's values, and fail closed when the payloads differ. Read anything outside the payload, such as expiry, straight from the chain.
Make a status badge mirror the program's checks, in the program's order, and say what it doesn't cover.
After a write, keep the read that proved it. For later reads, carry the highest slot you've accepted forward as minContextSlot.
Check reply lengths whenever you match results to requests by position.

To try this on your own app, pick one value your UI shows as confirmed, and trace where it comes from. If the answer is "the API told us", that's the first check to add.

Money without floats: parsing rupees as integer paise

Prashant Chaudhari — Sun, 25 Oct 2026 14:33:34 +0000

Why 96 of 100 paise endings repeat in binary, how that can flip a signed credit tier, and how I parse bank amounts from text into integer paise.

I'm building TEE Income Oracle, a service that reads a borrower's bank statement inside a secure enclave and signs a credit tier: A, B, C or reject. A lending pool reads that tier on chain. The score has two implementations: the enclave scorer in Rust, and a second scorer, written separately in TypeScript, that produces the expected tier for a set of test statements. The Rust tests fail unless the two agree.

So I need the same statement to produce the same tier, every time, in two languages. This post follows one amount through that pipeline: from the bank's text, to exact paise, to arithmetic that both scorers do the same way.

A tier that depends on the order of addition

One rule for tier A is about FOIR: monthly loan repayments (EMIs) as a share of monthly income. My policy measures it in whole basis points, rounded down, and tier A allows at most 4,000 (40.00%).

Take a ₹50,000 income and three EMIs that add up to ₹20,005.00. That's 40.01%, or 4,001 basis points, so this borrower is not tier A. Here's the check with floats:

const income = 50000;
const emis = [5000.0, 12345.06, 2659.94]; // ₹20,005.00: 40.01%, not tier A

const bps = total => Math.floor((total * 10000) / income);

const forward = emis[0] + emis[1] + emis[2]; // 20004.999999999996
const backward = emis[2] + emis[1] + emis[0]; // 20005

bps(forward); // 4000 → tier A
bps(backward); // 4001 → not tier A

Same amounts, same rule, two tiers. Nothing here is a bug in the usual sense: both orders are reasonable, and two programs written separately can easily pick different ones. With floats, they don't have to be wrong to disagree. And in my system the tier gets signed, so a wrong one is a signed claim about a real person.

With integer paise, the order can't matter:

const emisPaise = [500000n, 1234506n, 265994n];
const total = emisPaise[0] + emisPaise[1] + emisPaise[2]; // 2000500n

(total * 10000n) / 5000000n; // 4001n in any order → not tier A

Why floats can't hold most rupee amounts

A float stores numbers in binary, and binary can only write some fractions exactly. Decimal has the same problem with 1/3: you can't write it, only 0.3333… forever. Binary can write halves, quarters and eighths, but not tenths or hundredths. So 0.05 gets stored as the nearest value binary can hold:

(0.05).toFixed(30); // "0.050000000000000002775557561563"

I checked all 100 possible paise endings with a script: 96 of them can't be stored exactly. Only .00, .25, .50 and .75 can, and only if the whole amount fits the format's precision.

That's a statement about endings, not about real transactions, which don't spread evenly across them. For amounts with any of those 96 endings, a binary float holds an approximation. Each error is tiny. Across hundreds of transactions, rounding errors can accumulate, and as the example above shows, a tiny error is enough when it lands on a boundary.

Where the amounts come from

The statement arrives in the format India's Account Aggregator network uses. ReBIT defines it as an XML schema, and the DEPOSIT schema types Transaction.amount as xs:float. Balances and limits are xs:string, with no pattern.

ReBIT doesn't say why, and it isn't specific to this field: the whole schema family types numbers this way.¹ I read it as "this is a number", not as a choice of binary format. Strictly, xs:float means a 32-bit float, and taken literally a 32-bit float can't hold ₹1,23,456.78 (it becomes 123456.78125).

The schema describes XML, but the data my service accepts is JSON. Finvu's sample fetch response, from the Account Aggregator I target, shows the mapping: attributes become keys, amount arrives as a JSON number (6036), and balances arrive as JSON strings ("322644.09"). So my parser sees two forms:

JSON numbers, such as 85000, 1234.050 or 1.2E7.
Numeric strings, such as "112340.50". Here the schema allows any text, so XML-style spellings like "+5" and ".5" can appear too. They aren't valid JSON numbers, only valid inside strings.

1.2E7 is a real possibility, not a curiosity. Java's Double.toString writes values of 10⁷ and above in scientific notation, so a producer that uses it sends ₹1.2 crore as 1.2E7. My first parser accepted only plain decimals with at most two places, and it would have rejected that spelling.

Integer paise, parsed from the text

The money type in the oracle is a count of paise:

/// Money in integer paise (₹1 = 100 paise). The only money type in
/// `tio-core`.
pub struct Paise(i64);

₹1,234.05 is 123405. Integer sums are exact as long as every intermediate result stays in range, so the Rust scorer adds with checked arithmetic and does ratio maths in i128. The TypeScript scorer uses bigint with the same bounds.

The amount has to become an integer without ever becoming a float. If a JSON library turns 1234.05 into a float first, the error is in before my code sees the value. So the parser reads the raw text of each JSON value and never converts through a float. That avoids adding error at this step. It can't recover precision a producer already lost upstream.

The rule: within the supported grammar and range, accept any spelling that is exactly a whole number of paise, and reject everything else. Never round. Rounding would hide bad bank data inside a signed result.

The idea is simple: read the amount as text, move the decimal point two places to the right, and insist that what's left is a whole number.

Input	Result
`1234.05`	1,23,405 paise
`1234.050`	1,23,405 paise: a trailing zero changes nothing
`1.2E7`	1,20,00,00,000 paise (₹1.2 crore)
`1234.567`	rejected: the last digit would be a fraction of a paisa

The code works with digit counts rather than moving a character around, so scientific notation goes through the same path as a plain decimal. It also turns away anything too big to be a real amount, such as a hostile 1e999999999, before doing any arithmetic. The full parser is about 220 lines with comments: tio-core/src/money.rs.

Rounding that both scorers agree on

Integers remove accidental rounding, not all rounding. A scorer still divides: FOIR is a ratio, and two other features need a median and a square root. So each of those steps rounds down, the spec says so, and both scorers do exactly that. Every amount involved is zero or positive, so "round down" means the same thing in Rust and in JavaScript's bigint.

Rounding down is a policy choice, and it has a visible effect: ₹20,000.01 against ₹50,000 is 40.00002%, which rounds down to 4,000 basis points and still counts as tier A. I'm fine with that band in an eligibility rule, because it's written down and both scorers apply it. If you need "at most 40%" exactly, skip the division and compare products: obligations × 5 ≤ income × 2.

Other ways to do it

Integer paise isn't the only sound design. Exact decimal types, such as Java's BigDecimal, also avoid binary rounding.

I chose integers for my own constraints: two languages that must agree to the paisa, arithmetic that is mostly sums and comparisons plus a few specified ratios, and an output that gets signed. Payment APIs work the same way: Stripe takes 1099 to charge 10.99 USD, and Razorpay takes amounts as integers in the smallest currency sub-unit.

If you handle money in JavaScript or TypeScript

Keep amounts as integers in the smallest unit, and check intermediate results too, not just amounts. Number.MAX_SAFE_INTEGER is about ₹90 lakh crore in paise, but a paise amount times 10,000 leaves the safe range above about ₹900 crore. Use bigint when products can get that big.
Don't multiply a float by 100 and hope. 19.99 * 100 is 1998.9999999999998. Parse the string.
Get the raw text if an API sends JSON numbers. Newer runtimes pass the original text to the JSON.parse reviver (I checked Node 24):

  JSON.parse('{"amount": 1234.05}', (key, value, context) =>
    key === "amount" && typeof value === "number" ? context.source : value
  ); // { amount: "1234.05" }

The typeof check matters if the field can also arrive as a string. For a JSON string, context.source is the original text including its quotes ('"1234.05"'), while value is already the string you want.

Don't round money with toFixed. (1.005).toFixed(2) returns "1.00", because the stored value is slightly below 1.005.
Write the rounding rules down, and use the same ones in every implementation.
Read the spec, not just the sample. The sample I started from had plain decimals. The schema allows much more.

Integer paise keeps the money exact. Specified rounding rules make the remaining calculations reproducible across both implementations. Together, the same statement gives the same signed tier in Rust and in TypeScript.

If you have a money parser, try it with 1234.05, 1234.050, 1.2E7 and 1234.567. The first two should give the same value, the third should keep its full value (₹1.2 crore), and the last should fail rather than round.

Originally published on prashantchaudhari.dev.

Across the 23 FI type schemas in the Account Aggregator standards repo, the numeric declarations use xs:float and integer types, including xs:integer and xs:positiveInteger. None uses xs:decimal. The deposit schema has typed amounts this way since the earliest version in that repo (April 2021), and version 2.0.0 keeps it. ↩

Struggles of finding jobs for dropouts

Prashant Chaudhari — Sun, 07 Jun 2020 04:09:50 +0000

All the self taught developers and dropouts out there. What are your experiences with finding the job ? Do you tell the recruiter beforehand that you don't have a relevant degree or after the process is over ? I am from India and here it is difficult to get a job for dropouts very few companies allow it. Specially if anyone is from India and in similar situation, please share your experiences. So I want to hear your opinions and thoughts.