Hi, everyone
I'd like to know the way how to call get function of deployed contract in my contract

How can I call counter() in my contract?

You can write a TypeScript file to fetch on-chain data. For example, you can refer to this GitHub repository:
https://github.com/getgems-io/nft-contracts/tree/main/packages/contracts
https://github.com/toncenter/examples.

Please note that it is not reliable to call a get_method from Contract B in your Contract A for an asynchronous blockchain. The best approach is to use message receive to ask Contract B to return its status.

1. First, name the method get_counter() rather than counter() to obey convention:
2. Make a wrapper interface called Counter.ts in Typescript. and add the following method.
async getCounter(provider: ContractProvider) {
const result = await provider.get('get_counter', []);
return result.stack.readNumber();
}

Notice that the method_id modifier allows you to call the getter function from Typescript code using the following method and passing the Func getter method name as string key prameter:
await provider.get('get_counter', []);
return result.stack.readNumber();
Explained very well in https://ton-community.github.io/tutorials/02-contract/ . Go to step 9.

In your case if the get methods name is counter() then the typescript caller would be

async getCounter(provider: ContractProvider) {
const { stack } = await provider.get("counter", []);
return stack.readBigNumber();
}

And then you would call this interface getCouter method as follows in your Typescript code:

import { getHttpEndpoint } from "@orbs-network/ton-access";
import { TonClient, Address } from "ton";
import Counter from "./counter"; // this is the interface class we just implemented

async function main() {
// initialize ton rpc client on testnet
const endpoint = await getHttpEndpoint({ network: "testnet" });
const client = new TonClient({ endpoint });

// open Counter instance by address
const counterAddress = Address.parse("EQBYLTm4nsvoqJRvs_L-IGNKwWs5RKe19HBK_lFadf19FUfb"); // replace with your address from step 8
const counter = new Counter(counterAddress);
const counterContract = client.open(counter);

// call the getter on chain
const counterValue = await counterContract.getCounter();
console.log("value:", counterValue.toString());
}

main();

Hey guys, I am working on two related TEPs as an extension to TEP-74 and TEP-62. TEPs are about Lockable Fungible Tokens Standard and Lockable NFT Standard. It is revolutionary in a sense that it relies on the asynchronous system of TVM where each Jetton wallet is a distinct contract. We have atomicity within a wallet and not among wallets. This allowed us to introduce a class of transactions with a robust scheme that do not need consensus despite changing state. It increases speed, security, while decreasing costs incredibly for some DAPP use cases that involve staking.
Please kindly check the early draft out at https://web3-4.gitbook.io/daoton/lockable-token-standard
I am working on the TEP at the moment and would be happy to get feedback.

1. It is unclear do we really need a standard for this? Isn't it just internal implementation details of jetton-DAO system.
2. Indeed, to forbid double voting you need to be able to lock jettons from transfers. But also you need to prevent voting from the same wallet twice somehow. It is unclear how you do that.
3. Nikita Kuznetsov from OpenMask well thought out this concept of DAO, I made my own half-baked implementation here, not ready for production but can be used as proof-of-concept.

Thanks for your time and feedback. Pls find my answers below. I also made some updates to the proposal text to make things more clear.
1. It is unclear do we really need a standard for this? Isn't it just internal implementation details of jetton-DAO system.
- Because this scheme does not fit the DAO case only. It fits any staking based scheme which fits the constraints. Token issuer tightening/staking similar to what FED is doing right now is a great example, or other governance forms like we see in web3 gaming. But the most important part is that this scheme does not need consensus. Therefore, it is much cheaper (almost free), faster, and more secure. It is the ONLY scheme/standard in web3 that does NOT need consensus to achieve the same result in such use cases. Let me explain how fundamental it is with one more evidence: It adds the lock() function to fungible token standards, to the list of transfer, mint, burn. Adding something to such a short and fundamental list sounds fundamental. And it adds fundamental functionality. It removes the need to approve a third party contract to transfer money on owners behalf. On the other hand, it is not applicable to all DeFi schemes but to those with the same constraints. Please read here for another use case which is financial: https://web3-4.gitbook.io/daoton/buidl/lockable-tokens-standard/financial-use-case
2. Indeed, to forbid double voting you need to be able to lock jettons from transfers. But also you need to prevent voting from the same wallet twice somehow. It is unclear how you do that.
- Thanks for this question to remind me that i need to put some text there. The proposal contract's vote function saves who voted right after commiting the vote; or it can check the app_id field of the voting jetton-wallet's lock state. I explained it at the app_id for exclusivity use case. A consumer app is responsible for its own bookkeeping since it knows its own logic. Some apps may be happy with double voting in return for some actions for example. The backend just provides data, the consumer app decides and implements logic and bookkeeping.
3. Nikita Kuznetsov from OpenMask well thought out this concept of DAO, I made my own half-baked implementation here (https://github.com/EmelyanenkoK/jetton_dao), not ready for production but can be used as proof-of-concept.
- Thanks will check them out. By the way I updated proposal text after getting your questions to make things more clear. You may read it at: https://web3-4.gitbook.io/daoton/buidl/lockable-tokens-standard/introduction