Future Kaspa apps may make automatic decisions using information supplied by another app. A lending app might see a second program claim that someone owns valuable collateral. If it accepts that claim, it can release real money.
Reading the number correctly is not the same as knowing the claim came from the real, trusted token system. Software that accepts a convincing imitation can pay out against collateral that is not genuine.
A bank form can be filled out perfectly. Every box can sit in the right place, and the paper can look official. That still does not prove a bank issued it. The form's layout is only the data format. The issuing bank is the program that produced it. An authenticated record, showing who issued the form and how each later copy was authorised, is the trusted history.
On 3 September 2026, vertex, posting as KaspaScopio, told developers that public tests had already shown how a reader could be made to interpret carefully rearranged data incorrectly. He used a lending application reading token collateral as the example. A contributor, supertypo, had run the tests against the Kaspa script engine. Eight forged cases executed with the unmodified SilverScript compiler. (KaspaScopio)
Michael Sutton's first reply was brief. The proposed SilverScript guard had been closed, he said, because the behaviour is not an issue under the history assumptions required for any stored information being read. The full explanation still had to be written for the pull request and the SilverScript documentation. (Michael Sutton)
What the tests appeared to show
KaspaScopio presented the case as a SilverScript compiler issue, not a fault in Kaspa itself, and said he had found no evidence of exploited funds. The tests sat in a proposed SilverScript guard that was closed without merging, pending discussion. (SilverScript PR 234)
The tests showed a reader looking for information in expected places. Under the reported setup, data could be rearranged so that later reads landed on chosen values, while the overall size and the expected program pattern stayed the same. The full program itself does change with that rearrangement. Nobody showed that an attacker could keep the entire program identical.
In the lending example, the app could read an inflated amount from an attacker-created copy that used the genuine token pattern. Those eight cases were reported to execute under the unmodified compiler. That is the tests' own evidence, not an independently confirmed exploit in a live app.
The proposed guard would have made SilverScript reject those forgeries by checking that each piece of information was packaged as expected, in the expected place. It would have blocked the forgeries without explaining why a neighbouring record should be believed.
Why Sutton rejected that as the foundation
Sutton did not treat the closed guard as the missing safety layer. Under the history assumptions required for reading another program's information, he said, this is not the issue the proposed guard suggests.
A packaging check can stop a particular class of fake layout when software is looking at untrusted data. When one app is about to spend because another app reported a balance, packing is the wrong starting point. The reader has to know that the number came from the intended program, and from the line of records that program actually authorised.
The expected program and its authorised history
Later on 3 September Sutton published a detailed provenance explanation in Argent, a language being built on top of SilverScript. He first called it a fast document that he still needed to review. Later that day he said he would do a better job if he really wrote it, but that it was guided enough to be accurate, and a bit updated. (Michael Sutton) (Michael Sutton) (provenance note)
The expected program has to be the one the application chose, not a lookalike with the same layout. The record then has to belong to the authorised line from a trusted start.
A lasting application keeps an identity only when an already trusted step authorises the next one. A trusted start commits to the first records. Later records keep that identity only when the previous authorised step allows it. A later reader does not need to replay the whole history each time it looks. Kaspa already checked each later step when it was created.
Under those assumptions, the reader can take the numbers from their usual places, because earlier authorised writes already carried the format forward.
The argument does not cover an arbitrary identity, or a start that merely copied a compatible pattern. A trading application that binds a token to a known identity is making a policy choice. Unknown programs still need checks of the raw data itself. Authentication can prove that a selected record matches expected values. It cannot decide whether the application chose the right foreign agreement.
When one app spends on another app's number
Lending, exchanges, escrow and ordinary businesses run into this as soon as they let software spend without a person checking the file. A lender may release funds because a token program reported collateral. An exchange may settle because a pool reported a balance. An escrow may pay out because another program said the terms were met. A shop or payroll tool may move credit or access because a neighbouring app reached a state.
These are illustrations of the dependency, not claims of shipped products. In each case one program spends money, or time, on another program's record. The user sees an app that settled. The builder has already chosen which foreign program to believe, and which starting point counts as genuine.
Builders still need two kinds of read written down. Software looking at untrusted data has to check how each field is packaged. Software reading another application's information has to name the expected program and the authorised history from a trusted start, and keep that choice in the code that spends.
Sutton's note is not a final standard and does not override Draft KCC1, which still tells software reading untrusted data to check the packaging of every field. (KCC1) A later rule will need to keep those two jobs apart before the narrower approach becomes the specified way to read another app's information.
