순수지분증명(PPOS)형식의 알고리즘 암호화폐

home link

reference material


275.47 KRW
Exchanges that listed the coin
To be released
Project introduction

알고랜드(Algorand)는 분산화, 확장성 및 보안성 모두를 제공하는 플랫폼으로 블록체인 트릴레마의 해결을 목표로 하고 있습니다. 알고랜드는 새롭게 부상하는 탈중앙화 경제 시스템에서 기존 비즈니스 진입자 및 새로운 프로젝트 신규 진입자 모두가 운영할 수 있는 기반을 제공합니다. 그리고 알고랜드의 혁신적인 무허가형 순수지분증명 프로토콜은 전 세계 사용자들을 위한 시스템 구축에 요구되는 규모, 개방형 참여, 트랜잭션 완결성을 지원합니다.

Executives and partners

Silvio Micali


Steve Kokinos





Algorand Standard Assets

A conceptual overview of Algorand Standard Assets for developers.IntroductionAn Algorand Standard Asset, ASA for short, is a layer 1 feature that allows users to represent any asset on the Algorand blockchain, in turn benefiting from the same level of security and ease of use as the native Algo. Detailed documentation about this feature is available on Algorand’s developer website here.In this post we will draw out some of the most important concepts for developers who plan to work with ASAs. We will list some of the many examples of real-world assets that users can represent with this feature on the Algorand blockchain. Then we will share an example scenario paired with an interactive task to get you started with this new feature on TestNet.ASA Important ConceptsASA Transaction Types and User FlowsThere are three new types of transactions on Algorand to support ASA-related functions, namely 1) AssetConfigTxn (‘acfg’), 2) AssetFreezeTxn (‘afrz’), and 3) AssetTransferTxn (‘axfer’). Those three types paired with different parameter specifications support seven primary user flows, namely: 1) Asset Creation, 2) Asset (re-)Configuration, 3) Asset Freezing, 4) Asset Destruction, 5) Asset Transfer, 6) Asset Revocation and 7) Asset Opt-In. Note that goal and the SDKs include wrappers for most of these user flows. See diagram below for the key differences between these user flows with respect to their underlying constructs.Diagram that shows primary ASA user flows with respect to their underlying transaction constructs.Asset Opt-InsTo receive a new type of asset, an account must opt-in, which is the equivalent of the account sending a 0-amount transfer of the desired asset from and to itself. This will create a holding in that user’s account for that new asset, which gives others who own that asset the ability to transfer it to this user.Minimum Balance RequirementEvery Algorand address that exists on the ledger, must have a minimum balance of 100,000 microAlgos. The addition of any new ASA holding increases that balance by 100,000 microAlgos. For example, if I opt-in to receive two different ASAs, my minimum balance will be 300,000 microAlgos (100,000 microAlgos x 2 ASAs + 100,000 microAlgos for the native Algo).Freeze AssetsUpon creation of an asset, you can specify a freeze address and a defaultfrozen state. If the defaultfrozen state is set to true the corresponding freeze address must issue unfreeze transactions, one per account, to allow trading of the asset to and from that account. This may be useful in situations that require holders of the asset to pass certain checks prior to ownership (e.g. KYC/AML). If the defaultfrozen state is set to false anyone would be allowed to trade the asset and the freeze address could issue freeze transactions to specific accounts to disallow trading of that asset. If you want to ensure to asset holders that the asset will never be frozen, set the defaultfrozen state to false and set the freeze address to null or an empty string in goal and the SDKs.Revoke AssetsThe clawback address, if specified, is able to revoke the asset from any account and place them in any other account that has previously opted-in. This may be useful in situations where a holder of the asset breaches some set of terms that you established for that asset. You could issue a freeze transaction to investigate, and if you determine that they can no longer own the asset, you could revoke the assets. Similar to freezing, if you would rather ensure to asset holders that you will never have the ability to revoke assets, set the clawback address to null.ASA Use CasesWith Algorand Standard Assets you can represent fungible and non-fungible assets and with varying degrees of control. Here is a small subset of what could be represented on layer 1 of the Algorand blockchain with ASAs:Loyalty Points— e.g. Airline points that can be traded in for seat upgrades, tickets, or merchandise.In-game points — e.g. Buy badges and other in-game assets.System/store credits — e.g. Provide credits to your customers that can be redeemed in-store.Supply Chain — e.g. Track food items, like bananas, through the supply chain to the consumer.Tickets Sales— e.g. Issue tickets of the same type and price for entry into an event, issue tickets to a basketball game where each ticket may have a different value.Cryptocurrencies — e.g. stable coins, fiat currency.Real Estate — e.g. Generate and issue shares of a building, represent ownership of a home.Certification — e.g. KYC-certified account, non-GMO certified account.Interactive TaskGet started with Algorand Standard Assets, by opting-in to receive an ASA we created on the Algorand TestNet called Algorand Developer Coins. See the full task on our forums here.ResourcesAlgorand Standard Asset (ASA)ASA SDK UsageAlgorand Standard Assets was originally published in Algorand on Medium, where people are continuing the conversation by highlighting and responding to this story.


19. 11. 27

SDKs are available for BetaNet

Last week we announced the release of our new BetaNet, which has new features we are working on. While this was very significant, most of the new features were only available with Algorand’s command-line tool, Goal. In the intervening time, our Engineering team has been working diligently to fully support all the new features with our SDKs, which are available in Go, Java, JavaScript, and Python. These SDKs are now in a state where they can be used and tested. Additionally, we now have Developer documentation on the new BetaNet features that will help you to understand the new features and to get you up and running with your preferred SDK!So what features are currently available in BetaNet?BetaNet contains three new main features to support many application types and workflows. These are Algorand Standard Assets (ASA), Atomic Transfers, and Algorand Smart Contracts Layer-1 (ASC1). These features are described below with links to appropriate documentation and SDK pages. Standard AssetsGenerally, Blockchains have native tokens or cryptocurrency that underpin the operation of the network. Ours is the Algo. These are native to the protocol and operate at high efficiency, extreme security, and significant throughput. Many blockchains allow other tokens or assets to be created and used on their networks but this generally requires additional code or for the asset to be moved to Layer-2. Additionally, these bolt-on tokens/assets generally do not have the throughput, efficiency or security of a true Layer-1 token or asset.Algorands’ new Standard Assets feature allows anyone to create a Layer-1 token or asset on the Algorand network. These newly created assets inherit all the same features, security, and performance of our primary token (the Algo). This includes things like near-instantaneous transaction finality (less than 5 seconds currently), fast block creation time and minuscule transaction fees.Algorand Standard Assets are also extremely configurable, allowing users to represent virtually any asset on the blockchain. This includes Fungible assets like loyalty points, new currencies, and stable coins. You can also create Non-Fungible assets like real estate, collectibles or in-game assets. Each asset can also be configured to support regulatory operation including freezing and revoking assets, which allows creating regulated assets like securities.If you want to learn more about developer support for creating assets see our Algorand Standard Asset Documentation, which walks through using our command-line tool, Goal, to create and manage assets. Additionally, we now have documentation on how to create and manage assets with any of our SDKs.Atomic TransfersTransactions are the primary unit of operation on a blockchain. When we buy or sell things online these generally involve at least two transactions. One party may send funds to purchase “something”, and once received the seller sends the “something”. On a blockchain, this typically involves at least two transactions. This presents a problem where there is no guarantee that after the buyer makes his or her purchase, the seller will execute the second transaction. To get around this many blockchains use smart contracts. This can be inefficient and error-prone.Algorand is now providing Atomic Transfers to solve this problem. As with all the features described in this post, atomic transfer functions on layer-1 as part of the protocol. Algorand’s Atomic Transfers allow many transactions to be grouped into one operation. If any of the transactions fail for any reason, none of the transactions are processed. This allows a group of transactions to be first grouped and then signed by all parties and submitted as one operation.Atomic Transfers can also be used in conjunction with any asset (ASA or Algo) represented on the Algorand chain. As with ASA’s these atomic transfers have all the advantages of being a layer-1 feature.If you want to learn more about developer support for atomic transfers see our Atomic Transfers documentation, which walks through using our command-line tool, Goal, to group and submit transactions in an atomic operation. Additionally, we now have documentation on how to perform atomic transfers with any of our SDKs.Algorand Smart Contracts Layer-1 (ASC1)Smart contracts, in general, were created to automatically process transactions when a given set of logic or encoded terms were completed. These were intended to function without third party oversight and with higher efficiency than non-blockchain methodologies. In general, they live up to their designed goals. That said, smart contracts provide many disadvantages in blockchains, most of which center around security issues and performance impacts.Algorand has taken a different approach by implementing a new language called Transaction Execution Approval Language (TEAL) and baked it into the protocol. This approach designated as Algorand Smart Contracts Layer-1 (ASC1) provides a layer-1 solution to smart contracts. These contracts automatically enforce custom rules and logic, typically around how assets (Algorand Standard Assets or Algos) can be transferred. These contracts provide layer-1 solutions for problems like crowdfunding algorithms, split transactions, periodic payments, collateralized debt, escrows and more.As with ASA’s these smart contracts function on layer-1 and enjoy all the same benefits of the standard Algorand token, including speed, low transaction fees, and security.In addition to providing the ability for custom ASC1 contracts to be written, Algorand is providing ASC1 templates and SDK wrapper support for common use case scenarios like limit orders, periodic payments and delegated key registration. More information on our Template sets will be available soon on our developer site.ASC1 contracts function in two basic flows; as a contract account or as a signature delegation. Contract accounts are created when a TEAL program is compiled. These are just standard Algorand accounts with the caveat that no asset (ASA or Algo) can leave this account without the logic within the contract evaluating to true during the transaction. Assets can be passed to the contract account as with any normal Algorand account. With signature delegation the ASC1 functions as a replacement for the signing key in a transaction. After the ASC1 is compiled it must be signed by the user delegating his or her authority. These can be used to give access to your account if the given logic evaluates to true during a transaction. For example, you may want to give your power company the ability to remove a limited amount of Algos from your account once a month.To get more information see the ASC1 documentation page. In our developer documentation, both types of ASC1 flows are represented in the examples. You can also look at a simple example of an ASC1 and how it is processed with an escrow account. If you are interested in the Goal commands that work with ASC1 see the ASC1 Tutorial. To get more reference information on the language, see the TEAL reference documentation.ConclusionWhile individually each of these three new features is quite exciting, what is even more powerful is the fact that they were all designed to work together. For example, stand assets can be grouped in atomic transfers. Algorand smart contracts can be used with both standard assets or atomic transfers. We believe this will offer flexibility to build some very complex applications. We are looking forward to seeing what the Algorand community builds!SDKs are available for BetaNet was originally published in Algorand on Medium, where people are continuing the conversation by highlighting and responding to this story.


19. 11. 15

First Release of BLS Library

BLS signatures, introduced by Boneh, Lynn, and Shacham in 2001, enable efficient compression of a group of signatures S_1, …, S_n into a compact signature S that can be used to authenticate the entire group. These signatures are known to improve bandwidth, storage, and verification speed (when all signatures are on the same message) in numerous applications. When applied to blockchains, multiple signatures of transactions in a block can be compressed into a single signature, creating smaller blocks. Smaller blocks result in lower storage, network, and compute requirements needed from the network participants.BLS signatures have been around for some time, but as we know from experience, the adoption of new cryptographic schemes takes time. To accelerate the adoption of BLS signatures, our cryptography team, together with colleagues from academia, put together an Internet Draft. We hope the standard will accelerate this technology and help independent teams write cross-compatible implementations.draft-irtf-cfrg-bls-signature-00 - draft-irtf-cfrg-bls-signature-00.txtThe standard has evolved significantly since our initial draft posted in February 2019. It has now been adopted by the Crypto Forum Research Group (CFRG), which focuses on cryptography standardization for the Internet Engineering Task Force (IETF). We will continue updating the standard based on received feedback and hope it will be finalized and published as an RFC soon.Today, we are excited to announce the first release of the reference implementation for the BLS signature! implementation is compatible with the latest version of the standard and includes test vectors for comparison. We thank NCC’s Cryptography Services group for auditing the code.It is exciting to see how the community is already planning to use BLS signatures, and we look forward to its real-world deployments.“At Cloudflare, BLS signatures allowed us to join forces with multiple randomness providers to bring users the League of Entropy, a quorum of decentralized randomness beacons. We are enthusiastic about the results derived from the BLS standardization effort for strengthening the security of this and other services Cloudflare provides.”, Armando Faz, Cryptographic Engineer at Cloudflare inc.“We are excited to see this progress towards BLS standardization. BLS signatures, being aggregatable, can be useful when resources like bandwidth and storage capacity are limited. Uniqueness and determinism of BLS can help improve security in blockchains and other fields. BLS standardization will enable broader real-world use of these innovations.”, Calibra ResearchWe thank Justin Drake (Ethereum) for inviting broader blockchain and cryptography communities to follow this standardization effort and everyone who provided valuable feedback.I would like to congratulate Riad Wahby and Zhenfei Zhang on this release. This is a significant step towards BLS adoption!First Release of BLS Library was originally published in Algorand on Medium, where people are continuing the conversation by highlighting and responding to this story.


19. 11. 15

Algorand BetaNet is now live

In an effort to give the developer community access to the newest features and to allow plenty of maturation time for these new features to be fully tested, Algorand is announcing the release of BetaNet! BetaNet is an additional network that is wholly different than our MainNet or TestNet networks.Algorand’s BetaNet will contain many new features that the development team is currently working on and that are slated to eventually be deployed to our TestNet and MainNet environments. The intent is for this network to be updated often and will help us to refine new features and provide functionality that developers need in order to build successful projects. TestNet will continue to mirror MainNet’s protocol version so that developers can count on it as a staging environment for their own applications before deploying to MainNet. new BetaNet also contains a faucet that is located here.The Algorand Developer Site contains new documentation addressed to BetaNet users. This documentation is available on the BetaNet side menu and will reflect new features as they stand currently. These documents will be updated regularly and when the features are uplifted into TestNet and MainNet, the documentation will move accordingly.BetaNet can be accessed by updating your binaries using the update script as described here. After you have new binaries the process is very similar to switching to either TestNet or MainNet by swapping the genesis config file. Additionally, the new binaries can be used to start a private network as well. This allows you to create a new private network using the BetaNet binaries without having to build from source. After you have tested the new features with a private network you can then try on the worldwide BetaNet, or if you prefer to just use BetaNet you can do that from the start. As a quick start to test out on a private network you can do the following:Stop and update node for BetaNet Binaries:# If you have not installed any node # download the installer into a directory like ~/inst# which is covered on every OS install page # ie in the Retrieve Installation Package section.# Update software with beta flag and specify betanet directory../ -i -c beta -p ~/node -d ~/node/betanetdata -n# Next switch the ~/node directory and update goalcd ~/node./ -i -c beta -p . -d betanetdata -n# If you have a node already installed# change to the directory containing your running nodecd ~/node# Stop the current node./goal node stop -d data# Update software with beta flag and specify betanet directory../ -i -c beta -p . -d betanetdata -n# Run the update script a second time to update goal./ -i -c beta -p . -d betanetdata -nYou now have the BetaNet binaries in your ~/node directory. Note that this approach will not work with our standard Ubuntu install as that is configured to automatically start and the binary files are located in the /usr/bin directory. The data directory for the Ubuntu install also uses /var/lib/algorand as the data directory. So if you are on a Ubuntu system you may want to use the install guide for other Linux distributions if you want to try out BetaNet.You will need to do some additional configuration if you want to start up BetaNet at this point. These steps are described in the getting started with BetaNet page.To start up a private network with the BetaNet binaries you will need to supply a network template similar to the template described here. Once you have created this template, you will need to supply the ConsensusProtocol parameter and set it to future as shown below.{ "Genesis": { "NetworkName": "", "ConsensusProtocol": "future", "Wallets": [ { "Name": "Wallet1", "Stake": 50, "Online": true }, { "Name": "Wallet2", "Stake": 50, "Online": true } ] }, "Nodes": [ { "Name": "Primary", "IsRelay": true, "Wallets": [ { "Name": "Wallet1", "ParticipationOnly": false } ] }, { "Name": "Node", "Wallets": [ { "Name": "Wallet2", "ParticipationOnly": false } ] } ]}You should be able to start the private network with the following command:# create the network in the test network./goal network create -n mynetworkwithbeta -t networktemplate.json -r test# start the network./goal network start -r test# check the status of the network./goal network status -r testThis will create a test directory with your nodes started.To stop the network run:# stop the network./goal network stop -r test# delete the network./goal network delete -r testMore information on private networks is available here.Our community forums also have a new category page for BetaNet discussions. This page will also have quick links to descriptions of all new features. As you test these new features out be sure to reach out to us on this new community page!Algorand BetaNet is now live was originally published in Algorand on Medium, where people are continuing the conversation by highlighting and responding to this story.


19. 11. 05

Transaction History

Preparing to be listed on cryptocurrency exchanges
Please leave a message of support for the team

go to leave a message

Security verification

There is security verification of the project
Why security verification is necessary?

Read more


* Written questions can not be edited.

* The questions will be answered directly by the token team.

Platform ERC20
Hard cap -
Audit -
Stage -
Location -
Market of major crypto coins *2020년 01월 21일 last update



10,045,634.60 KRW 0.44%



194,132.92 KRW 0.41%



271.16 KRW 0.43%

Bitcoin Cash


400,691.52 KRW 2.78%

Bitcoin SV


359,349.82 KRW 14.51%



1,158.54 KRW 0.21%



4,201.37 KRW 0.64%



54,759.09 KRW 0.54%

Binance Coin


20,122.05 KRW 0.30%



72.51 KRW 4.13%



50.92 KRW 4.11%



75,563.79 KRW 0.36%



19.26 KRW 0.09%



1,834.37 KRW 11.18%



130,248.10 KRW 7.54%

Ethereum Classic


10,240.46 KRW 4.17%



5,231.33 KRW 0.29%



12,948.42 KRW 0.37%

Huobi Token


3,681.81 KRW 0.92%



2,709.01 KRW 2.29%