I have a predicate that in one case has no utxos or balances locked, and in the other case has a utxo locked at it, of a some already known asset id.
I would like the predicate to check whether it has this asset and validate on:
if has none of this asset id → pass.
if has any balance > 0 of this asset id → fail
I can see in Sway there a bunch of functions for inputs and output to the transaction specificlly, but cant seem to find anything that the predicate can check its own utxo’s, i.e., ones that are not within the immediate transaction as an input or output. We are also restricted to functions hat dont touch the contract that minted the asset_id.
What would be a good method to validate that the predicate has a zero balance of this asset?
Needs to pass case: (i.e., no utxos or balances of a particular asset)
There’s no way for a transaction to check that a UTXO doesn’t exist, it can only check that a coin does exist (because it’s included in a transaction).
Although this might seem like a limitation, it’s also what gives Fuel it’s power & performance.
If you need to check that an address has zero balance of an asset, you can use smart contracts instead of predicates.
Totally understand why Fuel was built in this way in terms of transaction introspection (inputs, outputs, witnesses etc)
I guess what im looking for is a validation mechanism whos outcome “for a predicate to check its own balance”, and when i say balance im really referring to utxos locked at its address of-course.
Unfortunately I cant use a smart contract in this part of the transaction/validation. The predicate in question (with encoded data) serves as an input to a transaction that calls a smart contract.
Right I see, with a predicate its strictly transaction data and encoded data (if any) dependent. So it makes sense that (as you mention above) the design of the predicate validation model would lead of cool things like performance. Not to mention what can be done with this like rapid swaps etc.
I’ll Have to re-think the transaction mechanism and see if i can come up with a different validation mechanic.