OpenZeppelin related: So i have been implementing our contract to be proxiable/upgradable but just found out that even the view methods require a transaction apparently (if we want contract to be upgradeable/proxiable) which would kill our UI. Has anybody run into similar issue? We are implementing it via openzeppelin proxy/upgrade contracts of course
It will be for the UI because of constant user prompts for transaction even for for view methods.
You don’t need a transaction for view methods. Just perform a call.
As with most StarkNet contracts, interacting with a proxy contract requires an account abstraction. One notable difference with proxy contracts versus other contract implementations is that calling
@view methods also requires an account abstraction. As of now, direct calls to default entrypoints are only supported by StarkNet’s
syscalls from other contracts i.e. account contracts. The differences in getter methods written in Python, for example, are as follows:
standard ERC20 call
result = await erc20.totalSupply().call()
upgradeable ERC20 call
result = await signer.send_transaction(
account, PROXY.contract_address, ‘totalSupply’,
That’s very weird. I’ve just checked on my account’s contract which is behind a proxy and you can call methods directly with no problems. Here’s fetch that I used (copied from network’s tab).
}).then(r => r.json() ).then(console.log)
As you can see it is just a regular call with no signature. Turing view calls into transactions doesn’t make sense for me.
Yep confirming your response but the open zeppelin doc should clarified more I think, its a little confusing. I was able to call view methods without account abstraction and invoke transactions