Archethic (UCO) Summer protocol improvements — Tech Update

We would like to share with you our latest updates in terms of achievements for this summer.

Recently, we shared a few improvements proposals to enhance Archethic’s protocol and Smart Contract layer.

Those improvements are listed and available on AEIP repository and are part of the community contribution

This summer, a few of those improvements were implemented and are now part of version 1.3 of the network.

Most of these changes target the Smart Contracts capability to be more user and developer friendly with some unique features.

We also made some improvements regarding transaction fees and token minting.

Those developments and improvements are part of our roadmap and required milestones in order to deliver a bidirectional decentralized bridge and DEX while being useful for the entire community and ecosystem.

Off-Chain data retrieval

We developed a disruptive feature, unique to Archethic to make smart contract even more powerful.

Smart contracts have now the capability to fetch data from external sources outside from the blockchain.

In this way, contracts can handle behaviors based on the value of external services while being secure thanks to the ARCH consensus. (atomic validation of all the nodes)

# Fetch from multiple sources responses = Http.fetch_many([ "https://weather-service.com/newyork", "https://another-weather-service.com/newyork" ]) # Do something with the returned data

This means contracts can make decisions based on external data while ensuring the security of the network

In a DeFi context, this feature powerfully simplifies communication between different blockchains and external sources, for example, decentralized application that relies on cryptocurrency prices from different sources. With this feature, a smart contract can now fetch these prices securely from external websites or APIs and use them to make lending decisions accordingly.

By extension, custom oracle can be designed on-chain and allows communities to build services — like a weather oracle or sports scores oracle — and use them in others contracts.

This flexibility opens up a world of possibilities for creating more sophisticated and dynamic DeFi applications.

Developer friendly oriented

We introduced the concept of Named Actions in the smart contract interpreter.

This helps developers easily create branches of actions based on a context, for example a specific method.

Before, to achieve this, the contract’s developer would have to develop by itself. Now it’s abstracted by the language itself.

actions triggered_by: transaction, on: vote(candidate) do # Do something to accept the vote of the given candidate end actions triggered_by: transaction, on: update do # Do something to upgrade the contract's code end actions triggered_by: transaction, on: close_vote do # Do something to terminate the vote end

Hence, dApp can target directly the right actions to trigger the right behavior.

We introduced another feature to help developers build dApps by supporting functions. They can be used when actions are triggered but can also be useful for frontend application to query some data from a contract (a concept of visibility is defined to be queried by external clients)

fun do_something() do # Do something helpful for the actions (used internally) end export fun end_date() do # Return the vote end date (used externally) end

Mint recipients & increase supply

Archethic natively supports the possibility to mint tokens (since AEIP2).
Once the transaction is validated, the number of tokens are associated and minted inside this chain to be spent later.

We now have the capability to send tokens simultaneously to a list of predefined recipients, saving one transaction cost and bring automation.

You can send these tokens to multiple people at once, saving time and money on transactions.

We also introduce the capability for a fungible token to extend its supply afterward by an explicit allowance.

Later, the chain’s owner can submit a new transaction to increase the supply of token without having to define again a token. (as an address defines the token’s identity, the token would change otherwise).

So you can increase the supply of these tokens later if needed, without creating a whole new token. This keeps the token’s identity the same.

Example of token with recipients and supporting extension of the supply:

{ "aeip": [2, 8, 18], "supply": 100000000, // Representing 1 token "type": "fungible", "name": "My token", "symbol": "MTK", "properties": {}, "recipients": [ { "to": "0f1fd....", "amount": 100000000 // Representing 1 token } ], "allow_mint": true }

Multi recipients transaction’s fee

Archethic supports batch/bulk transactions targeting multiple recipients, for example send UCO to multiple wallets at the same time.

This feature is native to the protocol without involving a smart contract or other off-chain system to manage it.

While this was possible, the transaction’s fee model was not appropriate to support and encourage people to use it.

So, we decided to make it more attractive; now, batch/bulk transactions are cheaper than before and enforce to use them instead of multiple transactions.

In short, sending one transaction to multiple recipients costs less than sending separate transactions to each person.

To follow-up with recent smart contract developments, the playground has been updated to support those new features.

It now has a friendlier interface to help developers try out new features. You can easily:

We would also like to thank all the contributors who have already given us feedback and reported issues to make the network even better.

Do you want to learn more about Archethic ?
Visit our website [Archethic.net], follow us on [X-Twitter], or join our community on [Telegram].