add a default wasm (or schema or spec) for SAC addresses to js-stellar-sdk for making specs from SAC | Stellar Developers | Page 1

hybrid pelican Feb 6, 2025, 10:44 PM

#

I was discussing this with @storm peak during the developers meeting. PR 960 on js-stellar-sdk added the ability to automatically build a contract client by crafting the spec from the wasm bytecode, but this depends on there being a wasm bytecode for the contract id.

SAC contracts are a host function, and i would propose we include the default interface wasm that we use in rust when making other contracts to make cross contract calls to SAC's. This is a wasm that just includes the function definitions and wasm specs. This is basically what i do now in my library new-soroban-fiddle on github, but it requires doing a global override of the method in the sdk. Anyways wasn't sure if i should put this here or #1082043094180036638 so i put it here.

The other way I have done it manually is to build a json schema for the SAC token interface

#

I made this thread so i remember to make an issue on the repo, and post the code example with the solution. If we can decide on the best way forward i can implement this rather easily.

storm peak Feb 7, 2025, 7:50 PM

#

Yeah this would be neat. Codifying the SAC Wasm spec into a ledger entry should be doable, I'd imagine. @slate plover thoughts?

slate plover Feb 7, 2025, 8:41 PM

#

I'm not sure I understand the problem

#

SAC spec does exist at least in Rust. not sure why do we need to do anything on the protocol side to also generate it on JS side

#

to be clear, SAC instances are not 'host functions'. SAC is a contract that has its own storage. you can wrap it into a Wasm contract today, but then you will need to make calls to the wrapper.

hybrid pelican Feb 8, 2025, 12:02 AM

#

SAC is not a contract exactly it's ah ost function.... by having a wasm blob for it , it allows dynamic generation of the spec without telling tthe thing making the call that this is a token contract

#

and yeah, i've already done that, i'm saying okay in the js-sdk if you wanted to make a client with no bindings, you can do it by using the contract id, it downloads the contract, extracts and parses the special section, to get all the func args and types, it then allows you to do contract.call or something to this effect. This doesn't work right now if the contract is a SAC contract because there's no wasm blob for it to download. I don't really think it would need to be made as a ledger entry though it could.

#

i was just thinking that we could make it so that in the sdk if it gets the error that it can't build the spec, bc it's a sac, then just don't throw that error, it can know the sac interface and signatures already

slate plover Feb 8, 2025, 12:04 AM

#

I still don't understand why would you need a wasm blob or what you would have in it. as far as I know specs are generated from code, not from wasm (I mean, someone could be generating them from wasm, but I'm not aware of that)

hybrid pelican Feb 8, 2025, 12:04 AM

#

that's one way to do it

#

that's all

#

for it's special section

#

you can make a rust contract that literally is just the function signatures of the token interface

slate plover Feb 8, 2025, 12:05 AM

#

or you can just encode spec directly? it's just XDR

hybrid pelican Feb 8, 2025, 12:05 AM

#

but an easier way would be why do that, you can just either hardcode the spec into the sdk

#

yes

#

that would require recognizing that it is a SAC address ahead of time

#

but i think that can happen or maybe not

slate plover Feb 8, 2025, 12:06 AM

#

I mean, in theory we could store the duplicate spec for every sac instanc

hybrid pelican Feb 8, 2025, 12:06 AM

#

anyways it's only a very minor annoyance that i already made a work around for in my code, but it's like it'd be cool if it just worked

#

seems we'd only need one

#

yeah

slate plover Feb 8, 2025, 12:06 AM

#

but I don't think it's worth it. if you're dealing with an on-chain address, just look if its executable is StellarAsset, and if so return the hardcoded spec

hybrid pelican Feb 8, 2025, 12:06 AM

#

i'm not sure it needs to be on chain in anyways though since as far as i know this is specific to a wierd use case, where i want to be able to make a webform for any contract dynamically lol

#

Don't think it's worth it to add as a ledger entry right, me either. i guess this is just an sdk feature

slate plover Feb 8, 2025, 12:08 AM

#

seems we'd only need one
yeah, my bad. I guess it could be a special ledger entry.it's still kind of weird as some additional logic is necessary to read that entry.

hybrid pelican Feb 8, 2025, 12:08 AM

#

yes even if i wanted to use the wasm blob, i think i'd rather just have it locally somehow encoded

#

we don't even need that tho in this case just the spec

#

i'm thinking why oh the way the spec generator works it needs the funcs from the special section

slate plover Feb 8, 2025, 12:09 AM

#

yeah, it could be probably refactored to also be able to just parse XDR

hybrid pelican Feb 8, 2025, 12:09 AM

#

yes

#

so yeah do you think it's worth making an issue out of this, or just... i can't imagine very many people have even ran into this because surely there must be another way to build a token transfer call using the sdk?

#

how do people normally do it

#

in rust there is the sep41 crate

#

could be, there is a token interface in the js-sdk that i overlooked not sure

#

i doubt people are generating bindings for it because they'd be confused how to do it

slate plover Feb 8, 2025, 12:12 AM

#

hybrid pelican so yeah do you think it's worth making an issue out of this, or just... i can't ...

do you mean js SDK?

#

I don't really know what do we do for JS SDK, but sure, please open an issue if something is missing

#add a default wasm (or schema or spec) for SAC addresses to js-stellar-sdk for making specs from SAC