-
Notifications
You must be signed in to change notification settings - Fork 24
Treasury
Every DAO contains its own treasury, which contain tokens needed to operate. Since every action related to transactions in NEAR blockchain and every every proposal takes some amount of tokens and gas
Basically there are three types of funds which can contain the Treasury of your DAO:
- NEAR tokens. Tokens of the NEAR cryptocurrency ranked top 40 coins at this moment.
- Fungible tokens. DAO members can create fungible tokens and fill the treasury using it. For more info please refer to appropriate 3rd party articles.
- Non-Fungible tokens. NFTs are digital assets representing real-world assets like music, videos, art, property, game, etc. Using NFTs, we can trade real worlds assets through smart-contract, cryptocurrency and blockchain technology.
Filling the DAOs treasury work the same way as it is done with any other cryptocurrency. You have to have appropriate amount of tokens stored in your NEAR wallet and send this amount of tokens to DAOs wallet.
NEAR’s token economy is built around the NEAR token (aka $NEAR), a unit of value on the platform that enables token holders to use applications on NEAR, participate in network governance, and earn token rewards by staking to the network.
The NEAR token (aka $NEAR) is a utility token that powers the NEAR Protocol blockchain and all applications that use it. NEAR Protocol is a fully operational, open-source blockchain designed from the ground up to give builders the best tools to create scalable applications that real people can actually use.
As described in the NEAR Protocol's Economics, $NEAR uses a block-rewards-with-burn model that, at high rates of usage, means token supply will be reduced over time.
A standard interface for fungible tokens that allows for a normal transfer as well as a transfer and method call in a single transaction. The storage standard addresses the needs (and security) of storage staking. The fungible token metadata standard provides the fields needed for ergonomics across dApps and marketplaces.
NEAR Protocol uses an asynchronous, sharded runtime. This means the following:
- Storage for different contracts and accounts can be located on the different shards.
- Two contracts can be executed at the same time in different shards.
While this increases the transaction throughput linearly with the number of shards, it also creates some challenges for cross-contract development. For example, if one contract wants to query some information from the state of another contract (e.g. current balance), by the time the first contract receives the balance the real balance can change. In such an async system, a contract can't rely on the state of another contract and assume it's not going to change.
Instead the contract can rely on temporary partial lock of the state with a callback to act or unlock, but it requires careful engineering to avoid deadlocks. In this standard we're trying to avoid enforcing locks. A typical approach to this problem is to include an escrow system with allowances. This approach was initially developed for NEP-21 which is similar to the Ethereum ERC-20 standard. There are a few issues with using an escrow as the only avenue to pay for a service with a fungible token. This frequently requires more than one transaction for common scenarios where fungible tokens are given as payment with the expectation that a method will subsequently be called.
For example, an oracle contract might be paid in fungible tokens. A client contract that wishes to use the oracle must either increase the escrow allowance before each request to the oracle contract, or allocate a large allowance that covers multiple calls. Both have drawbacks and ultimately it would be ideal to be able to send fungible tokens and call a method in a single transaction. This concern is addressed in the ft_transfer_call method. The power of this comes from the receiver contract working in concert with the fungible token contract in a secure way. That is, if the receiver contract abides by the standard, a single transaction may transfer and call a method.
An interface for a fungible token's metadata. The goal is to keep the metadata future-proof as well as lightweight. This will be important to dApps needing additional information about an FT's properties, and broadly compatible with other tokens standards such that the NEAR Rainbow Bridge can move tokens between chains.
Custom fungible tokens play a major role in decentralized applications today. FTs can contain custom properties to differentiate themselves from other tokens or contracts in the ecosystem. In NEAR, many common properties can be stored right on-chain. Other properties are best stored off-chain or in a decentralized storage platform, in order to save on storage costs and allow rapid community experimentation.
As blockchain technology advances, it becomes increasingly important to provide backwards compatibility and a concept of a spec. This standard encompasses all of these concerns.
Prior art: * EIP-1046 * OpenZeppelin's ERC-721 Metadata standard also helped, although it's for non-fungible tokens.
A fungible token smart contract allows for discoverable properties. Some properties can be determined by other contracts on-chain, or return in view method calls. Others can only be determined by an oracle system to be used on-chain, or by a frontend with the ability to access a linked reference file.
A standard interface for non-fungible tokens (NFTs). That is, tokens which each have a unique ID.
In the three years since ERC-721 was ratified by the Ethereum community, Non-Fungible Tokens have proven themselves as an incredible new opportunity across a wide array of disciplines: collectibles, art, gaming, finance, virtual reality, real estate, and more.
This standard builds off the lessons learned in this early experimentation, and pushes the possibilities further by harnessing unique attributes of the NEAR blockchain:
- an asynchronous, sharded runtime, meaning that two contracts can be executed at the same time in different shards; a storage staking model that separates gas fees from the storage demands of the network, enabling greater on-chain storage (see Metadata extension) and ultra-low transaction fees.
Given these attributes, this NFT standard can accomplish with one user interaction things for which other blockchains need two or three. Most noteworthy is nft_transfer_call, by which a user can essentially attach a token to a call to a separate contract. An example scenario:
-
An Exquisite Corpse contract allows three drawings to be submitted, one for each section of a final composition, to be minted as its own NFT and sold on a marketplace, splitting royalties amongst the original artists.
-
Alice draws the top third and submits it, Bob the middle third, and Carol follows up with the bottom third. Since they each use nft_transfer_call to both transfer their NFT to the Exquisite Corpse contract as well as call a submit method on it, the call from Carol can automatically kick off minting a composite NFT from the three submissions, as well as listing this composite NFT in a marketplace.
-
When Dan attempts to also call nft_transfer_call to submit an unneeded top third of the drawing, the Exquisite Corpse contract can throw an error, and the transfer will be rolled back so that Bob maintains ownership of his NFT.
An interface for a non-fungible token's metadata. The goal is to keep the metadata future-proof as well as lightweight. This will be important to dApps needing additional information about an NFT's properties, and broadly compatible with other token standards such that the NEAR Rainbow Bridge can move tokens between chains.
The primary value of non-fungible tokens comes from their metadata. While the core standard provides the minimum interface that can be considered a non-fungible token, most artists, developers, and dApps will want to associate more data with each NFT, and will want a predictable way to interact with any NFT's metadata. NEAR's unique storage staking approach makes it feasible to store more data on-chain than other blockchains. This standard leverages this strength for common metadata attributes, and provides a standard way to link to additional offchain data to support rapid community experimentation.
This standard also provides a spec version. This makes it easy for consumers of NFTs, such as marketplaces, to know if they support all the features of a given token.
Prior art:
- NEAR's Fungible Token Metadata Standard
- Discussion about NEAR's complete NFT standard: #171