i'm quite struggling understanding how we can deposit and withdraw funds from smart contract on NEAR blockchain.
I'm currently using near-sdk-as with AssemblyScript. According to documentation I do have the
ContractPromiseBatch.create(recipient).transfert(amount)
But how can we lock funds into the smart contract and withdraw it from allowed accounts ?
When you call your method with --amount <some amount here> you have deposited these amounts to your contract balance. For example:
near call $CONTRACT add '{"url":"http://EXAPMLE.com", "title":"hello world"}' --accountId $AUTHOR --amount 3 //this is 3 NEARS you deposit to contract balance
When you want to send an amount from your contract balance to another person's balance you can use the contractPromiseBatch API as follows:
const toAnotherPerson = ContractPromiseBatch.create("anotherPerson.testnet");
toAnotherPerson.transfer(<some amount here>);
Related
I have two stake accounts in the Testnet validator none of them showing any rewards is something wrong with the configuration
Wallet: https://explorer.solana.com/address/EjGaPZ59sycMm46VpbukVY9PnwSdPYCfeQnbRLaZaD7m?cluster=testnet
Identity : https://explorer.solana.com/address/GfudXfSxpvSBvkyNG7K1CdFhntZw3ASvBeCiTSRV5nzr?cluster=testnet
Vote: https://explorer.solana.com/address/7R5of8HZreWPjURAMupJuik7vx5SAGUghpwU648bWYnt?cluster=testnet
Stake : https://explorer.solana.com/address/4EZRbSFYUQeuNCtY3Tv5tqprpTk9Ak7CZPzPsXKm1qLD?cluster=testnet
Stake2 : https://explorer.solana.com/address/967KrU4RrL2jrFtgyCKDBtyXrh3YC1SYh21PZvA6YJgE?cluster=testnet
When I check my vote account the rewards are there for the epoch
https://explorer.solana.com/address/7R5of8HZreWPjURAMupJuik7vx5SAGUghpwU648bWYnt?cluster=testnet
On the contrary, the stake account has not generated any rewards and they are in the Active (Delegated)
The vote account has a commission of 100%, so all of the rewards go to the vote account, with nothing going to the stakers. If you lower the commission, then your stake accounts will start to receiver rewards.
Setup the Testnet Validator funded with some SOL in Testnet (Not real )
Here is the link for the Explorer
https://explorer.solana.com/address/GfudXfSxpvSBvkyNG7K1CdFhntZw3ASvBeCiTSRV5nzr?cluster=testnet
Stake Account Identity :EjGaPZ59sycMm46VpbukVY9PnwSdPYCfeQnbRLaZaD7m
Vote Account Identoty: 7R5of8HZreWPjURAMupJuik7vx5SAGUghpwU648bWYnt
Validator Identity:GfudXfSxpvSBvkyNG7K1CdFhntZw3ASvBeCiTSRV5nzr
The blocks are getting produced well in the Testnet Enviroment for the validator identity GfudXfSxpvSBvkyNG7K1CdFhntZw3ASvBeCiTSRV5nzr,
How to know the Validator earning where to check it ?
The validator's earnings are stored in the validator's vote account, so check on the SOL balance in 7R5of8HZreWPjURAMupJuik7vx5SAGUghpwU648bWYnt. The voting commissions are paid out every epoch, so you'll have to wait until the next epoch to see rewards in the vote account and stake account.
When i try to use execute_sale transactio falis and it throws this error
"Timed out awaiting confirmation on transaction"
https://solscan.io/tx/3ZxL5ATkhXWM995RKaMqRuNHfDjANCg5fPjxuq2oSbsU8p7tKsia2w7Apk2cBopinhGviXGQckC8rGTJC7C8Wchw?cluster=devnet
I input
Auction house address
2.buyerPrice
3.token mint address
4.token size
5.buyer_pub_key
6.seller_pub_key
7.my private key
The "index out of bounds" happens when execute_sale function cannot find a matching buy and sell order to execute the sale.
To make sure that execute_sale works, you need the following:
A sell order on against a mint X with price P (make sure your treasury fee account is funded)
A buy order against mint X (make sure you have enough funds in the wallet as the funds go into an escrow)
Sell and buy order prices must be the same
Sell and buy orders have to have been made against the same auctionhouse instance
when you call execute_sale, the price specified must match the buy and the sell order price.
when the above conditions are met, execute_sale will work. If execute_sale is unable to find a matching sell/buy order pair, then you will receive the not-so-helpful index out of bounds error.
We're building a marketplace in NEAR. We have two smart contracts for token and marketplace. Same as NEAR example.
In our platform, we have successfully implemented below features:
Token mint (used contract method: nft_mint)
Token listing for sale in marketplace (used contract methods: storage_deposit nft_approve)
Token purchase (used contract method: offer)
Everything is working fine.
Now, we want to charge the transaction fee (2.5%) on each sales for our marketplace.
--
I did one mint and buy test with Paras Marketplace to observe the royalty and transaction fee distribution. Here is the test details:
With seller.near account, I minted an NFT in Paras Marketplace. And added 3% royalty. And listed it #1 Ⓝ for sale.
With buyer.near account, bought it with another account.
NFT Details:
Name : My Non-fungible token #1
Listed Price : 1 Ⓝ
Royalty : 3%
Sale Breakdown:
Receive (Seller) : 0.95 Ⓝ
Royalty (Creator) : 0.03 Ⓝ
Fee (Paras) : 0.02 Ⓝ
Before purchase - Account Balance
buyer.near : 50.03995 Ⓝ
seller.near : 4.896 Ⓝ
After purchase (1st sale after minted) - Account Balance
buyer.near : 49.03388 Ⓝ | Difference : -1.00607 Ⓝ
seller.near : 5.82587 Ⓝ | Difference : +0.92987 Ⓝ
# NFT Create Transaction
This is nft_create_series transaction. Where Paras is sending "transaction_fee": "200" to charge 2% service fee on each sale:
# NFT Buy Transaction
This is buy transaction. Where Paras charged 2% service fee:
Question:
We want to charge 2.5% service fee on each sales.
We want to implement "transaction_fee": "250" object in our marketplace contract.
How to do the same with our marketplace?
There are several ways that you can go about doing this. The two that I would recommend are the following (I saw you were following along with the zero to hero tutorial):
Option A (simplest) - store your account in the perpetual royalties object for the token when it is minted.
This is the easiest to implement as you don't need to change anything in your contracts and you simply need to alter what is passed into the royalties object on mint.
This requires that you have control over the NFT contract.
This allows you to receive royalties on whatever marketplace the token is sold on since the royalties are stored on the token level in the NFT contract.
This allows you to specify which account should receive the royalties instead of forcing the marketplace contract to store the funds.
Option B - before calling nft_transfer_payout in your marketplace contract, subtract 2.5% from the price object. This will result in your marketplace contract keeping the 2.5% and paying out the remaining 97.5% to the respective accounts.
With this approach, since many accounts are paying for storage, your contract has funds that aren't all withdraw-able by you. You should keep a tally on how much $NEAR you've received so that you can withdraw that amount and not accidentally withdraw too many funds that may have "belonged" to someone else via storage deposits.
During the implementation of recurring payments using Braintree I encountered a problem.
In documentation I can read: “Without proration enabled, any changes made to a customer’s subscription mid-cycle will go into effect at the beginning of the next cycle.” (https://articles.braintreepayments.com/guides/recurring-billing/recurring-advanced-settings#proration)
But if I edit the subscription to a lower dollar amount in the middle of a billing cycle (without proration on downgrades enabled) e.g. from $100 to $80 and then I edit the subscription to a higher dollar amount (with proration on upgrades enabled) e.g. to $90, the gateway will immediately charge me some amount.
In this situation, I would expect that gateway will not generate any transaction, because downgrade should be effective at the beginning of the next cycle and new subscription price ($90) is lower than initial subscription price (100$).
How can I then reach scenario when transaction on proration upgrade will be generated only if new subscription price is higher than maximum subscription price at the current billing cycle?
I'm a developer at Braintree.
If you kept proration on for both price decreases and increases, in the example you give you would see a credit applied to the subscription balance for the decrease, and then a charge applied against the balance for the increase. If the charge exceeds the subscription balance credit, then your customer would be charged.
A subscription will not be charged in the middle of a billing cycle unless you choose to prorate charges. You could create the scenario you want with logic similar to below. Code snippets are in Ruby since you didn't specify what client library you were using.
First look up the subscription you want to update and find the start date of the current billing period:
subscription = Braintree::Subscription.find("subscription_id")
billing_period_start_date = Date.parse(subscription.billing_period_start_date) # convert String to Date
Then iterate over the status_history events of the subscription, and update the billing_period_max_price if the history event took place after the beginning of this billing cycle and the billing_period_max_price is greater than the previous one:
billing_period_max_price = 0.0
subscription.status_history.each do |history_event|
event_date = Date.parse(history_event.timestamp.strftime('%Y/%m/%d')) # convert Time to Date
event_price = history_event.price.to_f
if event_date >= billing_period_start_date && billing_period_max_price < event_price
billing_period_max_price = event_price
end
end
Finally, if the billing_period_max_price is less than what you want to change the subscription price to, prorate the charges:
Subscription.update(
"subscription_id",
:price => "yourHigherPrice",
:options => { :prorate_charges => true }
)
If you have additional questions, feel free to reach out to Braintree support.