algorandlabs / smart-asa Goto Github PK

The return value of get_asset_config is currently a complex nested Tuple due to the limited length of the ABI.

To overcome such a limit consider replacing Tuple with ABI Type NamedTuple introduced with PyTeal PR #473. For instance:

class SmartASAConfig(abi.NamedTuple):
         total: abi.Field[abi.Uint64]
         decimals: abi.Field[abi.Uint64]
         default_frozen: abi.Field[abi.Bool]
         unit_name: abi.Field[abi.String]
         name: abi.Field[abi.String]
         url: abi.Field[abi.String]
         metadata_hash: abi.Field[abi.DynamicArray[abi.Byte]]
         manager_addr: abi.Field[abi.Address]
         reserve_addr: abi.Field[abi.Address]
         freeze_addr: abi.Field[abi.Address]
         clawback_addr: abi.Field[abi.Address]

Add an example to README showing how to use the Sandbox, connected to TestNet, to deploy and interact with a Smart ASA on a public network.

GitHub actions dependencies should be kept up to date with Dependabot daemon

The TEAL source code should include a constant that univocally identifies the implementation versioning.

In order to facilitate client-side discovering of Smart ASA interface, a reference to Smart ASA ABI could be provided, somehow, in the Application Crate transaction note-field.

With the introduction of PyTeal Assert comments, SourceMap and tools like Beaker Clients it is very convenient to split Assets to address single failure/error conditions in order to retrieve a more explicit and informative root cause of a failure.

Describe the solution you'd like
Currently the asserts on regular transfer preconditions looks like:

# Asset Regular Transfer Preconditions
Assert(
    Not(asset_frozen),
    Not(asset_sender_frozen),
    Not(asset_receiver_frozen),
    is_current_smart_asa_id,
),

Describe alternatives you've considered
A more informative and useful assertions would be:

# Asset Regular Transfer Preconditions
Assert(Not(asset_frozen), comment="Asset is global frozen"),
Assert(Not(asset_sender_frozen), comment="Asset sender is frozen"),
Assert(Not(asset_receiver_frozen), comment="Asset receiver is frozen"),
Assert(is_current_smart_asa_id, comment="Wrong Smart ASA ID"),

Align methods ABI JSON in README with the correct (and updated) one generated with PyTeal ABI router in smart_asa_abi.json

Currently the Smart ASA ABI JSON, automatically generated by PyTeal, does not include methods descriptions.

Would be very useful to improve the JSON ABI once this improvement is merged into PyTeal.

Example:

def asset_transfer(
    xfer_asset: abi.Asset,
    asset_amount: abi.Uint64,
    asset_sender: abi.Account,
    asset_receiver: abi.Account,
) -> Expr:
    """
    Smart ASA Transfer: regular, mint, burn, clawback.
    
    Args:
        xfer_asset: Smart ASA ID.
        asset_amount: Smart ASA amount.
        asset_sender: Account to transfer Smart ASA from.
        asset_receiver: Account to transfer Smart ASA to.
    """
    ...

Ensuring that the ABI JSON in the repository (resulting from PyTeal automated generation) and the Smart Contract PyTeal code are always aligned.

Describe the solution you'd like
Introduce a test or an automated job in GH actions CI.

Add ARC-22 readonly fields to methods in smart_asa_abi.json.

Is your feature request related to a problem? Please describe.
Currently Smart ASA failures during execution on AVM are not specifically identified by error codes and/or root causes. This makes the UX harder whenever an interaction with Smart ASAs fails due to any reason (e.g. the receiver is frozen, etc.).

Describe the solution you'd like
Once available as AVM feature, include error messages handling to the reference implementation.

How will platforms (explorer, wallets etc...) incorporate an ARC-20 seamlessly into a accounts's asset balances?
(Assumption: Most users wont be concerned with the distinction, so they'd likely just want to see an ARC-20 along with all their other ASA's.)

A platform would have to pull an account from algod/indexer and iterate through the app-local-states applying a brittle heuristic to the state to see if they can assume that local state represents an ARC-20.

I propose, why not just be explicit! Add an additional state field 'isArc20' = 1 (or w/e). This would make it trivial to identify ARC-20 assets in an account.

(Please tell me if this issue is better suited to the ARC-20 thread, just thought I'd start here)