No Results
Article Image

Algorand Smart Contract Layer1 (ASC1) and Oracles


At the end of 2019, Algorand released in record time the Algorand Smart Contract Layer1 (ASC1), a new paradigm shift for smart contracts. Rand Labs has been researching this technology and we incorporated it in Algo Explorer and added ways to interact with it using My Algo Algorand Wallet .

The first part of this article goes through our understanding of ASC1. The second part addresses oracle data in ASC1 showing a way to insert signed data from the outside world with a small example.

General Logic

The ASC1 is a simple logical predicate that verifies or not. ASC1s can have jumps but cannot cycle nor make function calls. They can only access the transaction group data they belong to and some global parameters. The transaction size is limited to 1k making it the size limit of Algorand smart contracts. Algorand uses a stack-based notation where users put the parameters on the stack before executing the opcode. Users can make arithmetic operations, verify transactions, group transaction fields, make hash operations, verify Ed25519 signatures, and other related operations.

For a detailed list of what Algorand’s Transaction Execution Approval Language (TEAL) can do and its limitations refer to this TEAL manual.

ASC Creation

After a user writes an ASC1 and compiles it, the address where the smart contract lives is created, but neither the code nor the address are stored on the blockchain until a transaction interacts with the ASC1. For the rest of the users, the contract is just an address, indistinguishable from any other account address. Any change to the ASC1 code will modify the compilation of it and thus result in a different generated address. The only way to obtain the same address generated by an ASC1 is by compiling the same TEAL code.

We are witnessing a completely new concept compared to the rest of the public blockchains. While other networks store the smart contract in the blockchain before interacting with it, on Algorand, users can create an escrow ASC1, seed it with funds, and give the logic only to the beneficiary. In this case, the beneficiary will need to “publish” the smart contract to the blockchain with the correct parameters if he/she wants to cash in the funds in the escrow. Only after a successful transaction is broadcasted, the smart contract becomes public for the rest.

ASC1 Transactions

Considering that the ASC1 is just an account with funds and some logic attached, users looking to retrieve funds from it must generate a transaction specifying the origin address of the transaction, from, as the ASC1 address (the address generated from the compiled TEAL code). The transaction fields and the group it belongs to among the ASC1 arguments must make the ASC1 predicates evaluate true for the transaction to be valid and included in the blockchain. The transaction body contains the ASC1 code alongside the required arguments needed to verify the predicates.

Lease String

This transaction parameter is used to mutually exclude transactions. For instance, ASC1 can leverage the lease parameter to enable recurring payments. In this case, the ASC1 requires transactions to include a specific lease (like a lock code) to be valid. Once a transaction with the correct lease is approved by the ASC1, future transactions with the same lease code will not validate for the rest of the approved transaction validity period. This type of use case would enable an account to spend a certain amount of funds for a specific recurring period (i.e. every 600,000 blocks). Once spent using a transaction with the correct lease, no more transactions will be valid for the remainder of the period. You would have to wait for the next valid block period to start before sending a new valid transaction to spend the amount again. Refer to periodic-payment-escrow.teal.tmpl that implements this logic.


We have been looking into ways of inserting outside information into the blockchain using ASC1. There is an opcode called ed25519verify that can do the trick. The opcode ed25519verify receives 3 parameters: data, signature and public key. As it is right now, this opcode requires the inclusion of the TEAL program in data that is signed. Taking advantage of this opcode, an oracle can sign a result of the outside world (jointly with the TEAL code) while the ASC1 can verify that the signature comes from the oracle. We strongly recommend the Algorand team add a new opcode to insert oracle data without signing the TEAL code to allow third-party oracles to provide information for different ASC1s at the same time.

Example: Oracle Using ed25519verify

The following illustrates how to write an ASC1 with oracle input. This example is limited to interpret valid oracle outcomes while not addressing the consequences of the oracle not generating the correct signature or users not claiming the funds. If any of these situations happen in this specific example, the funds would get stuck forever. It is possible to address these situations by adding a round limit to claim the funds. After that round, any participating account can create a transaction splitting the funds. Refer to split.teal for an example using group transactions to split the funds.


// Parameters:
//  - TMPL_ADDRA: Address betting for Team A.
//  - TMPL_ADDRB: Address betting for Team B.
//  - TMPL_ADDR_ORACLE: Oracle Address.
//  - TMPL_FEE: maximum fee used by the limit order transaction.
txn TypeEnum
int 1 // Payment (either Algos-out in trade or Algos redeemed at timeout)
global GroupSize
int 1
// if arg 0 == 0 then send to TMPL_ADDRA
arg 0
byte base64 MA==
txn CloseRemainderTo
txn Receiver
// if arg 0 == 1 then send to TMPL_ADDRB
arg 0
byte base64 MQ==
txn CloseRemainderTo
txn Receiver
// global verifications
txn Fee
// verify oracle signature
arg 0
arg 1

You can see the code here.


In summary, the ASC1 can be expressed in this way:

tx type == Pay && GroupSize == 1 &&
((data == 0 && to == TMPL_ADDRA && close == TMPL_ADDRA) ||
(data == 1 && to == TMPL_ADDRB && close == TMPL_ADDRB)) &&
ed25519verify(data, signature, oracle TMPL_ADDR_ORACLE) &&
ok fee

The first and the last lines are general verifications. The interesting part of the ASC1 is that the algos go to TMPL_ADDRA if data is 0 or to TMPL_ADDRB if it is 1 and the data signature is verified with ed25519verify opcode.

Oracle Keys

A key file testkey.key is generated with algokey tool for the oracle:

$ ./algokey generate -f testkey.key | grep “Public key”


The following parameters are used for the template:


You can download the specialized version oracle.teal or the template oracle.TEAL.tmpl

Compiling the ASC1 gets the address:

$ ./goal clerk compile oracle.teal

You can check that there is nothing special about the address on Algo Explorer. It is just like any other account address.

Signing to Verify with ed25519verify

We suggested a change in the go-algorand code in this pull request, which was accepted as a feature in goal - the goal clerk tealsign command. You can read about this new feature in this article.

Case 1: ADDRA Wins

First, the ASC1 address is funded. Then, the signature of the data is created:
Data: Exactly 1 byte with a “0”
Code: oracle.teal

$ ./goal clerk tealsign --keyfile oracle.key --contract-addr JDYOTGQ6D2CLH4EBOJLUNV5TYJS3DZSJHNQV6ESEEHFF76I6OUI53JR7H4 --data-b64 MA==

Then, send a close transaction from the ASC1 account to ADDRA to transfer all funds. The following signature and message “0” (base64 is MA==) is used:

$ ./goal clerk send -a 0 --from-program oracle.teal -t BKJX2U52PKL27XS42VO4SJW5BBFBYDCN7NYAW6BUEKF7EBYX5XV5CKAPT4 -c BKJX2U52PKL27XS42VO4SJW5BBFBYDCN7NYAW6BUEKF7EBYX5XV5CKAPT4 --fee 1000 -d testnet --argb64 MA== --argb64 LjbN+UgzmYG6vWKQuOkJKk69DBrJFY7IM0yblgeiZl5OOtZPlAf/ujTVl4FTAA5oa0/1npNtNDHvhxmY4pb/BA==
Transaction XWZLK6YBQ4H6BZUSONDOE5A66B4MASVBGVTL6B4HNWMBYQ7GHTBA committed in round 4451591

Case 2: ADDRB Wins

The ASC1 is funded again and a signature of the data is created with ADDRB winning:
Data: Exactly 1 byte with a “1”
Code: oracle.teal

$ ./goal clerk tealsign --keyfile oracle.key --contract-addr JDYOTGQ6D2CLH4EBOJLUNV5TYJS3DZSJHNQV6ESEEHFF76I6OUI53JR7H4 --data-b64 MQ==

Then, send a close transaction from the ASC1 account to ADDRB to transfer all funds. The following signature and message “1” (base64 is MQ==) is used:

$ ./goal clerk send -a 0 --from-program oracle.teal -t 36WZVNA6YA77V2MGGLJBT2YQG3RQVX6UWJ3P6E7FWNAV4IGMK3ZVVNBLVQ -c 36WZVNA6YA77V2MGGLJBT2YQG3RQVX6UWJ3P6E7FWNAV4IGMK3ZVVNBLVQ --fee 1000 -d testnet --argb64 MQ== --argb64 DJ0FtmIaLCksr5WhPczcHIwn9ye4CGHFPn64z38ChorZ6r0Dvj6z1n2bV9gIMUe+UrN5lzNDYK7u3Cxh1SiQBg==
Transaction 2SKTS2SAQ2QTDV3PR45WV4NO6TQHT7S2BR73W6T3OJJHT7LVXKPQ still pending as of round 4451877
Transaction 2SKTS2SAQ2QTDV3PR45WV4NO6TQHT7S2BR73W6T3OJJHT7LVXKPQ committed in round 4451879

Leading with Technological Innovation

Here we see the first stages of Algorand’s vision of smart contracts. The new paradigm in smart contracts is extremely revolutionary. The ability to conceal everything about any ASC1 until it is used brings great possibilities. For instance, escrows will now be deployed with complete privacy and thus security as no one will know anything about it till the escrow is executed. Furthermore, this new design makes the use of smart contracts easier compared to the complexity of Turing complete smart contracts of other blockchains. With ASC1s uses cases such as recurring transactions, allowance, collateralized credit, escrows, bets, and much more, are all much simpler to create and magnitudes of times more secure.
We are excited to see what type of uses cases the Algorand community starts building leveraging this new revolutionary technology. As always, Algorand keeps leading the technological innovation in the DeFi space and setting the standard of this movement.

If you are looking to share ideas or collaborate with us, ping us at [email protected]

smart contracts




June 29, 2020