I uploaded and created a new smart contract. I sent 1000 units to this smart contract.
However when the contract is deployed the transferable is not equal to 1000.
And when I execute any function it also deducts the transferable.
Is there any way to prevent this. I want to deduct user token instead of the smart contract token. In Ethereum, the user token is deducted.
I want to deduct user token instead of the smart contract token. In Ethereum, the user token is deducted.
I think there is a misunderstanding here, you probably understood the deducted tokens as gas. But gas is deducted from the instantiating account (what you referred to as "user token"), same as in Ethereum.
The amount that is deducted from the contract here is state rent ‒ i.e. the contract has to regularly pay for the amount of state and code storage it uses. This is a concept which is currently used by the contracts pallet to reduce state bloat. I won't link to the documentation here though, since a new paradigm will be introduced soon, making it obsolete.
Related
Given I want to let someone without a NEAR account call a specific function in a smart contract, and to do so I create a function access key for my own account with permissions limited to that specific contract and function.
Will I then risk anything else than the allowance (0.25N) granted to that function access key?
Is it a bad idea to even share that access key publicly, let's say if I want to include that access key in a link?
I could of course also create an implicit account and then a function access key from that, but is it really necessary from a security point of view?
What you're describing is the basis for what's known as a linkdrop. You can learn more about how those work here.
To answer your question, it depends on what that function call access key can do. If it can call a method withdraw that can withdraw $NEAR from your contract account with no limits, then it's probably not a good idea to share it publicly.
If you're confident that the key cannot be used in a malicious way to steal assets or do things that are unwanted, then there is no risk in sharing it publicly.
I would also stress that the 0.25 $NEAR allowance is NOT saying "this key can be used to withdraw up to 0.25 $NEAR on my account". That allowance is for transactions fees ONLY (Gas). 0.25 $NEAR equates to roughly 2.5 PetaGas (2500 TGas) which is a lot of computation power and can be used to call a method many times. What happens in that method, however, has nothing to do with the allowance.
You can spend 0.01 $NEAR worth of allowance (100 TGas) and call a method which withdraws 1000 $NEAR from the contract account. The allowance is ONLY for computation.
TLDR: it depends on what the key can do and allowance != net outbound NEAR from a contract account.
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)
I have already prepared the Candy Machines for minting an NFT collection in the Solana network, and I am testing the Mint process using its Devnet.
Even if you can find a lot of tutorials about how to prepare the candy machines, there are some questions that I am still not able to find the right answer and I think that could be useful for other users.
Does the Mint need to be one by one? If a user would like to buy, for example 50 NFTs, does it require approving 50 transactions and pay 50 times the fees (using Phantom or any other wallet)?
I assume that yes, because every minted NFT is a new contract. Am I right?
I am successfully doing a Mint in the Devnet using my Phantom wallet in order to determine the fees. For a single NFT, the transaction fee reflected in the wallet is 0.012SOL = 2.16$ at this time. It seems really expensive based on what a transaction in Solana should cost. How are these fees calculated? Is this the normal fee price that a user pay for minting 1 NFT?
To answer both your questions:
The mint does not need to be one by one (from a mint site I am assuming is what you mean). You can string multiple transactions together like what this repo has achieved: https://github.com/maxwellfortney/next-candy-machine
Note: this repo is for cmv1 which is no longer supported but can be simply adjusted to work with cmv2 as the transactions themseleves should be similar.
Yes, that is a normal fee for minting. Transactions (transfering tokens or sol) themselves on solana are extremely cheap but storing data is not as cheap. To store data (such as is required by an NFT as they need a URI for the metadata) some "rent" costs are involved, as defined in the solana docs https://docs.solana.com/implemented-proposals/rent. Basically you have to pay for the NFT to store this data and exist which is the minting fees you are witnessing, a tiny fraction of the price you pay is for transferring the NFT to your wallet.
Mints are usually done one by one, but someone could hand code a transaction to do multiple, especially with Candy Machine V1.
The rent collected depends on the amount of bytes stored for each NFT. You can check how much it will cost with solana -um rent <bytes>. You can find more information here
I recently update the candy machine to v2, and it has some interesting features as minting more than one NFT or handle a whitelist of wallets:
https://docs.metaplex.com/candy-machine-v2/getting-started
for your second question, you can maybe think to use an external service that handles the transaction fees.
In this way you'll be able to let you customer get the NFT without paying any fee.
If you are interested in implementing a similar external solution, I guess that this APIs Service is for you: cowsigner.com
You can also solve your first point, because when you create a transaction, you'll be able to add as many instructions as you want to it.
For anything else, just drop a simple comment below :)
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 currently in the process of planning & developing an integrated application using Stripe in addition to some other technologies (a combination of backbone & laravel). As a result I am using Stripejs in combination with the PHP stripe library.
I use stripejs to send Stripe their account info (for savings accounts I send country, routing and account numbers via stripes js lib, I then save off the created token in the response to the backend). I am attempting to transfer money to various recipients following charging accounts (so I have money in my stripe account) but I am a bit confused over exactly what approach to take.
My main questions are as follows.
If I am positive of the identities of the individual’s using the application, is verification required (5 – 10 people max will be using)?
If it is required what is the best approach to verifying the user using the current technique I am using (create a token, save off on the backend)?
From my experience with Stripe, you don't need to 'verify identities' each time you use a token, so long as a customer has been set up for recurring use. So as long as your application is properly secured so that only the 5-10 people can use it, and can only process payments for their own accounts, you are good to go. In other words, you obviously want to do your own user verification to make sure only valid people can use the application, but you don't need to do it as far as Stripe is concerned.
That said, if you are in essence transferring money between people, you might want to go the extra distance and make sure that the user has the correct card number or bank account number each time. In which case I would use something like:
Get user data using tokens stored in DB.
$cu = Stripe_Customer::retrieve("cus_4pn93XXXXXXXXXXX");
$card = $cu->cards->retrieve("card_14g7ZU4rLTyXXXXXXXXXXX");
If Stripe's returned data matches user-submitted data, you know you have the correct user. In particular, if the last 4 digits of the card and the expiry date match the last 4 returned by Stripe and the Stripe returned expiry date, you can be reasonably sure (albeit not certain) that the person actually possesses the card in question.