Here's my workflow:
I will create a NFT brand (by the way is a NFT brand just an ESDT?)
I want to perform an action for all the NFT under that brand.
So how do I get a list of all the NFT that has been created under my brand?
To go even further, how do I get it programmatically (using the rust SDK)? And how do I send egld to those addresses in the most effective way?
A nft brand is part of the esdt specification, but it is not the same as a fungible token, which are also commonly referred to as just ESDTs.
To get a list of all NFT you can use the following api. Use the token identifier (example: TEST-424242) you received upon creation of the brand to fill the collection parameter and you will receive all the nfts you created.
There is no easy way to retrieve the nft data inside a smart contract without knowing the address that holds the nft first.
See the function get_esdt_token_data.
So to achieve what you want you will probably have to create a register function inside your smart contract that takes the caller address and the nft the caller provided and store that mapping in the smart contracts storage. That way you can retrieve it later to send the egld to the owners.
To send the egld you would want to use direct function in the send api. Or the direct_egld, which unfortunately isn't documented, but it is basically the same as the direct function but without the need to specify a token identifier and nonce.
Related
Is it possible to view the actual data (schema data) that is stored by a smart contract? There is a "Counter" smart contract out there and I would like to see (perhaps on a block explorer) how and where this data is stored. I am looking to find the current state of the data (the counter) without calling "get_query" on the contract. Any advice is greatly appreciated.
Short answer no.
Building a contract, as a developer you choose what to send as a response, you can return events, attributes and data that can be read by explorers.
If the contract in question doesn't expose the counter data as an attribute, you have no way of getting this data without doing a query on that contract.
I'm trying to get all the information like from-address, to-address, amount, etc in my JS backend to confirm a transaction using it's hash. The transaction object returned from the getTransaction RPC call has a array for owner account PublicKey(from-address) but can't find a way to find the to-address. How can I find this?
You need to iterate over the CompiledInstructions (found on TransactionResponse.transaction.message.instructions) and decode them one by one.
Regular SOL transfers would be transfer instructions called on the system program. Web3.js has a helper for that purpose.
SPL Transfers would be transfer instructions called on the token program. I something similar for the initialcapoffering.com order form, this code might be helpful
It seems wNEAR is baked by wrap.near contract, but how does it work?
wrap.near holds w-near contract, which is FT [fungible token] implementation based on NEP-141 standard.
The idea is simple, you send native NEAR tokens and the contract keeps track of the balance of the sender account in its local storage, and there is a reverse operation which allows you to instruct the contract to send NEAR tokens back.
This FT always matches native NEAR token 1:1. "Wrapped" prefix in the name (wrapped NEAR or wNEAR) implies that it just turns native token into FT token. It was created to be compatible with Rainbow Bridge (Aurora) interfaces which allows to transfer FT across NEAR network <> Ethereum network (by locking the tokens in a contract on one network and unlocking the equivalent amount of tokens from a contract that is deployed on the other network).
So getting back to the technical implementation of w-near contract, you can find three core methods:
near_deposit expects NEAR native tokens attached to the function call, and those attached tokens will be deposited to wrap.near account, and in exchange the contract implementation will save a record in the storage that those tokens belong to the account that sent them
near_withdraw deducts the amount of tokens recorded for the account that called this function and sends a transfer of native NEAR tokens back to the caller
ft_transfer (it is implemented by near-sdk-rs helper) virtually transfers the wNEAR FT tokens by updating the records inside the contract storage. NOTE: there is no native transfer involved here, so the transaction will go from tokens sender to wrap.near contract, which will update the balances of the sender and receiver accordingly, and the receiver account will never receive a native NEAR call or NEAR tokens (until he/she calls near_withdraw)
Let's say I have a contract function that expects a certain amount of near to be send with a certain transaction, the function is called create_order, create_order takes a couple arguments.
I have my contract setup in the frontend under the name myContract.
I want to call myContract.create_order({...}) but the transaction fails because this method call doesn't have the right amount of NEAR tokens attached.
How do I assign a certain value of deposit to a transaction?
It's possible to use account.functionCall directly (without sugar for RPCs) to either attach amount or specify gas allowance for the call.
See Account#functionCall in nearlib.
Nearlib supports it using account.functionCall(..., amount). But it might not work, because of the design of the access keys with function calls. Default authorized access keys towards applications only allows function calls without attached token deposits (only prepaid gas). It's done this way to prevent apps from automatically using your balance without your explicit approval. Details on access keys are here: https://github.com/nearprotocol/NEPs/blob/master/text/0005-access-keys.md
The way to attach a deposit for the transaction should be done with the explicit approval from the wallet. The app should create a request for the wallet, redirect to the wallet for the approval (or through the popup). Once user approves the transaction, it's signed with full access key from the wallet directly and broadcasted. But I'm afraid we don't have this API on the wallet yet. Issue for this: https://github.com/nearprotocol/near-wallet/issues/56
AFAIK it is not supported at the moment. It will be available after this NEP https://github.com/nearprotocol/NEPs/pull/13 lands.
I am having a register form that user fill in, once the form fill in, the registration is postponed till the user recieve an email to check that his email is ok, then when he reply the email, the registration is fully proceed.
I would like also the process to be automatic, without the need for the user to entered any number ect, just the need for him to click on the email to confirm, and automatic on my side too.
I want the process to be available to some others task than the registration process as well if possible.
Do I need to do all way check/123456 with the 123456 generated or is there a better way to do, a component, nuget that can do the job ? you experiences return would be helpful
thanks
You appear to be on the right track.
I do a similar thing quite often. It isn't generic since I do not need it but you can change that quite easily.
Once a user registers I send an activation e-mail that contains a link that when clicked navigates to something such as http://domain/member/activate/id where the id is a GUID. That is all I need. I look up the member id and activate it. Chances of someone guessing a new member's id are rather slim and even if they do it is very far from a train smash.
From what I can tell you need something more generic and a bit more security. You could always create some key (like a new GUID) that you store along with the user and then the activation calls: http://domain/member/activate/id?key={the guid}. You could even encrypt the key. But that is up to you.
For something that can be re-used and is more generic you could create an activation component that contains a list of activation ids. But to then activate a specific type of entity (such as user registration or form validation) you would need to have a way to perform that on the back-end. For example, when you call http://domain/activation/activate/id internally is looks up the id and gets the type. The activation request is, of course, created when, e.g., your user registers. You would probably want to store some expiry/timeout since a user may never activate.
For each type you could have an activation mechanism on the relevant controller: member/activate/key or formvalidation/activate/key. So when you activation controller receives a request to activate it has a list of routes conigured per type and the navigates to the relevant route to perform the 'actual' activation.
Another option is to have an in-process component perform activation e.g.: an IActivator interface implemented by a MemberActivator or FormValdationActivator and then have an IActivatorProvider implementation that gives you the relevant provider based on a type (.NET Type or a string type you provider --- that's up to you).
You could even pass an ActivationRequestCommand along to a service bus endpoint if you are so inclined.
So you have many options. HTH
If you are a developer I suggest you at least try to start with the code... then ask again if you get stuck providing a sample of what you've done.
What you are looking to do is basically use a temporary url that posts to a page to complete the registration...