Skip to content
Algorand Developer Portal Algorand Developer Portal Algorand Developer Portal
This new developer portal is under construction. For complete documentation, please refer to the old developer portal.

Inner Transactions

What is Inner Transaction?

When a smart contract is deployed to the Algorand blockchain, it is assigned a unique identifier called the App ID. Additionally, every smart contract has an associated unique Algorand account.

We call these accounts application accounts, and their unique identifier is a 58-character long public key known as the application address. The account allows the smart contract to function as an escrow account, which can hold and manage assets (ASA) and send transactions just like any other Algorand account.

The transactions sent by the smart contract (application) account are called Inner Transactions.

Inner Transaction Details

Since application accounts are Algorand accounts, just like any other account, they need Algos to cover transaction fees when sending inner transactions. To fund the application account, any other account in the Algorand network can send Algos to the specified account. For funds to leave the smart contract, the following conditions must be met:

  • The logic within the contract must submit an inner transaction.
  • The smart contract’s logic must return true.

A smart contract can issue up to 256 inner transactions with one application call. If any of these transactions fail, the smart contract call will also fail.

Inner transactions support all the same transaction types as a regular account can make.

  • Payment
  • Key Registration
  • Asset Configuration
  • Asset Freeze
  • Asset Transfer
  • Application Call
  • State Proof

You can also group multiple inner transactions and atomically execute them. Refer to the code example below for more details.

Inner transactions are evaluated during AVM execution, allowing changes to be visible within the contract. For example, if the balance opcode is used before and after submitting a pay transaction, the balance change would be visible to the executing contract.

Inner transactions also have access to the Sender field. It is not required to set this field as all inner transactions default the sender to the contract address. If another account is rekeyed to the smart contract address, setting the sender to the address that has been rekeyed allows the contract to spend from that account. The recipient of an inner transaction must be in the accounts array. Additionally, if the sender of an inner transaction is not the contract, the sender must also be in the accounts array.

Clear state programs do not support creating inner transactions. However, clear state programs can be called by an inner transaction.

Paying Inner Transaction Fees

By default, fees for Inner Transactions are paid by the application account (NOT the smart contract method caller) and are set automatically to the minimum transaction fee.

However, for many smart contracts (apps), this presents an attack vector in which the application account could be drained through repeated calls to send Inner Transactions that incur fee costs. The recommended pattern is to hard-code Inner Transaction fees to zero. This forces the app call sender to cover those fees through increased fees on the outer transaction through fee pooling. Fee pooling enables the application call to a smart contract method to cover the fees for inner transactions or any other transaction within an atomic transaction group.

To illustrate this concept, let’s examine a payment Inner Transaction example that utilizes fee pooling to force the app call sender to cover Inner Transaction fees:

Payment

1
    @abimethod()
2
    def payment(self) -> UInt64:
3
        result = itxn.Payment(amount=5000, receiver=Txn.sender, fee=0).submit()
4
        return result.amount
5


6
    """
7
    fee is set to 0 by default. Manually set here for demonstration purposes.
8
    The `Sender` for the above is implied to be Global.current_application_address().
9


10
    If a different sender is needed, it'd have to be an account that has been
11
    rekeyed to the application address.
12
    """

Asset(ASA) Create

Assets can be created by a smart contract. Use the following contract code to create an asset with an inner transaction.

1
    @abimethod
2
    def fungible_asset_create(self) -> UInt64:
3
        itxn_result = itxn.AssetConfig(
4
            total=100_000_000_000,
5
            decimals=2,
6
            unit_name="RP",
7
            asset_name="Royalty Points",
8
        ).submit()
9


10
        return itxn_result.created_asset.id
11


12
    @abimethod
13
    def non_fungible_asset_create(self) -> UInt64:
14
        """
15
        Following the ARC3 standard, the total supply must be 1 for a non-fungible asset.
16
        If you want to create fractional NFTs, `total` * `decimals` point must be 1.
17
        ex) total=100, decimals=2, 100 * 0.01 = 1
18
        """
19
        itxn_result = itxn.AssetConfig(
20
            total=100,
21
            decimals=2,
22
            unit_name="ML",
23
            asset_name="Mona Lisa",
24
            url="https://link_to_ipfs/Mona_Lisa",
25
            manager=Global.current_application_address,
26
            reserve=Global.current_application_address,
27
            freeze=Global.current_application_address,
28
            clawback=Global.current_application_address,
29
        ).submit()
30


31
        return itxn_result.created_asset.id

Asset(ASA) Opt In

If a smart contract wishes to transfer an asset it holds or needs to opt into an asset, this can be done with an asset transfer inner transaction. If the smart contract created the asset (ASA) via an inner transaction, it does not need to opt into the asset.

1
    @abimethod
2
    def asset_opt_in(self, asset: Asset) -> None:
3
        itxn.AssetTransfer(
4
            asset_receiver=Global.current_application_address,
5
            xfer_asset=asset,
6
            asset_amount=0,
7
            fee=0,
8
        ).submit()
9


10
    """
11
    A zero amount asset transfer to one's self is a special type of asset transfer
12
    that is used to opt-in to an asset.
13


14
    To send an asset transfer, the asset must be an available resource.
15
    Refer the Resource Availability section for more information.
16
    """

Asset(ASA) Transfer

If a smart contract is opted into the asset (ASA), it can transfer the asset with an asset transfer transaction.

1
    @abimethod
2
    def asset_transfer(self, asset: Asset, receiver: Account, amount: UInt64) -> None:
3
        itxn.AssetTransfer(
4
            asset_receiver=receiver,
5
            xfer_asset=asset,
6
            asset_amount=amount,
7
            fee=0,
8
        ).submit()
9


10
    """
11
    For a smart contract to transfer an asset, the app account must be opted into the asset
12
    and be holding non zero amount of assets.
13


14
    To send an asset transfer, the asset must be an available resource.
15
    Refer the Resource Availability section for more information.
16
    """

Asset(ASA) Freeze

A smart contract can freeze any asset, where the smart contract is set as the freeze address.

1
    @abimethod
2
    def asset_freeze(self, acct_to_be_frozen: Account, asset: Asset) -> None:
3
        itxn.AssetFreeze(
4
            freeze_account=acct_to_be_frozen,  # account to be frozen
5
            freeze_asset=asset,
6
            frozen=True,
7
            fee=0,
8
        ).submit()
9


10
    """
11
    To freeze an asset, the asset must be a freezable asset
12
    by having an account with freeze authority.
13
    """

Asset(ASA) Revoke

A smart contract can revoke or clawback any asset where the smart contract address is specified as the asset clawback address.

1
    @abimethod
2
    def asset_revoke(
3
        self, asset: Asset, account_to_be_revoked: Account, amount: UInt64
4
    ) -> None:
5
        itxn.AssetTransfer(
6
            asset_receiver=Global.current_application_address,
7
            xfer_asset=asset,
8
            asset_sender=account_to_be_revoked,  # AssetSender is only used in the case of clawback
9
            asset_amount=amount,
10
            fee=0,
11
        ).submit()
12


13
    """
14
    To revoke an asset, the asset must be a revocable asset
15
    by having an account with clawback authority.
16


17
    Sender is implied to be current_application_address
18
    """

Asset(ASA) Configuration

As with all assets, the mutable addresses can be changed using contract code similar to the code below. Note these these addresses cannot be changed once set to an empty value.

1
    @abimethod
2
    def asset_config(self, asset: Asset) -> None:
3
        itxn.AssetConfig(
4
            config_asset=asset,
5
            manager=Global.current_application_address,
6
            reserve=Global.current_application_address,
7
            freeze=Txn.sender,
8
            clawback=Txn.sender,
9
            fee=0,
10
        ).submit()
11


12
    """
13
    For a smart contract to transfer an asset, the app account must be opted into the asset
14
    and be holding non zero amount of assets.
15


16
    To send an asset transfer, the asset must be an available resource.
17
    Refer the Resource Availability section for more information.
18
    """

Asset (ASA) Delete

Assets managed by the contract can also be deleted. This can be done with the following contract code. Note that the entire supply of the asset must be returned to the contract account before deleting the asset.

1
    @abimethod
2
    def asset_delete(self, asset: Asset) -> None:
3
        itxn.AssetConfig(
4
            config_asset=asset,
5
            fee=0,
6
        ).submit()

Grouped Inner Transactions

A smart contract can make inner transactions consisting of multiple transactions grouped together atomically. The following example groups a payment transaction with a call to another smart contract.

1
    @abimethod
2
    def multi_inner_txns(self, app_id: Application) -> tuple[UInt64, arc4.String]:
3
        payment_params = itxn.Payment(amount=5000, receiver=Txn.sender, fee=0)
4


5
        app_call_params = itxn.ApplicationCall(
6
            app_id=app_id,
7
            app_args=(arc4.arc4_signature("hello(string)string"), arc4.String("World")),
8
            fee=0,
9
        )
10


11
        pay_txn, app_call_txn = itxn.submit_txns(payment_params, app_call_params)
12


13
        hello_world_result = arc4.String.from_log(app_call_txn.last_log)
14
        return pay_txn.amount, hello_world_result

Contract to Contract Calls

A smart contract can also call another smart contract method with inner transactions. However there are some limitations when making contract to contract calls.

  • An application may not call itself, even indirectly. This is referred to as re-entrancy and is explicitly forbidden.
  • An application may only call into other applications up to a stack depth of 8. In other words, if app calls (->) look like 1->2->3->4->5->6->7->8, App 8 may not call another application. This would violate the stack depth limit.
  • An application may issue up to 256 inner transactions to increase its budget (max budget of 179.2k even for a group size of 1), but the max call budget is shared for all applications in the group. This means you can’t have two app calls in the same group that both try to issue 256 inner app calls.
  • An application of AVM version 6 or above may not call contracts with a AVM version 3 or below. This limitation protects an older application from unexpected behavior introduced in newer AVM versions.

A smart contract can call other smart contracts using any of the OnComplete types. This allows a smart contract to create, opt in, close out, clear state, delete, or just call (NoOp) other smart contracts. To call an existing smart contract the following contract code can be used.

NoOp Application call

1
    @abimethod
2
    def noop_app_call(self, app_id: Application) -> tuple[arc4.String, String]:
3
        # invoke an ABI method
4
        call_txn = itxn.ApplicationCall(
5
            app_id=app_id,
6
            app_args=(arc4.arc4_signature("hello(string)string"), arc4.String("World")),
7
        ).submit()
8
        # extract result
9
        first_hello_world_result = arc4.String.from_log(call_txn.last_log)
10


11
        # OR, call it automatic ARC4 encoding, type validation and result handling
12
        second_hello_world_result, call_txn = arc4.abi_call(  # declare return type
13
            HelloWorld.hello,  # method signature to call
14
            "again",  # abi method arguments
15
            app_id=app_id,
16
        )
17


18
        return first_hello_world_result, second_hello_world_result

Deploy smart contract via inner transaction

1
    """
2
    HelloWorld class is a contract class defined in a different file.
3
    It is imported in the beginning of this file.
4


5
    from ..hello_world.contract import HelloWorld
6
    """
7


8
    @abimethod
9
    def deploy_app(self) -> UInt64:
10
        """
11
        This method uses the itxn.ApplicationCall to deploy the HelloWorld contract.
12
        """
13
        compiled_contract = compile_contract(HelloWorld)
14


15
        app_txn = itxn.ApplicationCall(
16
            approval_program=compiled_contract.approval_program,
17
            clear_state_program=compiled_contract.clear_state_program,
18
            fee=0,
19
        ).submit()
20
        app = app_txn.created_app
21


22
        return app.id
23


24
    @abimethod
25
    def arc4_deploy_app(self) -> UInt64:
26
        """
27
        This method uses the arc4.arc4_create to deploy the HelloWorld contract.
28
        """
29
        app_txn = arc4.arc4_create(HelloWorld)
30


31
        return app_txn.created_app.id