DOCSEARCHbyAlgolia
Submit Docs

Archetype Language

website·Indexed 33 days ago

https://archetype-lang.org/

An elegant generic-purpose language for developing smart contracts on Tezos. The documentation covers language basics, including types, expressions, and state machines, as well as a comprehensive reference for instructions and declarations. It also provides guidance on using the Completium CLI, testing frameworks, and implementing TZIP norms such as TZIP-12 (FA 2), TZIP-16, TZIP-17, and TZIP-21.

Tokens
52.5K
Snippets
361
Records
482
Agent score
65%

What's inside Archetype

  1. Overview of the Poll DApp example

    The Poll DApp is a reference implementation where users can create and answer polls. Poll definitions (questions, images, and choices) are stored on IPFS, while the list of polls and user answers are managed by a smart contract. The application is built using the MUI UI widget library.

  2. Overview of TZIP-17 Permits implementation

    The Permits template implements the TZIP-17 norm for fee-less operations. It allows users to register permits (hashes of transaction data) that can be consumed to execute operations without the user paying the fee at the time of execution.

    Security Caveats:

    • Permit Guessing: Permits are stored as blake2b hashes of transaction data. If a hash is guessed (e.g., based on previous transactions), it can be consumed. Users should only register permits for transactions they are willing to see executed.
    • Replay Protection: The implementation uses a counter to protect against signature replay attacks. Each permit must include the current counter value in the signed hash.
    • Ordering: Because of the counter, permits must be sent to the contract in the exact order of the expected counter values; otherwise, they will be rejected.

  3. Overview of the Archetype test framework

    The Archetype test framework is used to ensure the correctness of smart contracts by verifying they behave as expected before deployment. It supports all Archetype language features as well as contracts written in Michelson. The framework is designed to support three primary testing strategies: unit tests for single features, integration tests for combined features and multi-contract interactions, and security tests to ensure resistance to hacking and threats.

  4. Overview of Completium CLI

    completium-cli is a command line interface used for account and endpoint management to interact with (originate, call, etc.) Archetype and Michelson smart contracts on the Tezos blockchain.
    completium-cli help

  5. Overview of FA 2 Token Standard Implementation

    The FA 2 implementation follows the TZIP-12 norm for tokens (NFT, Fungible, and Multi-asset). Key features include:

    • Ledger: Associates tokens with owners.
    • Operator: Defines addresses authorized to transfer tokens on behalf of owners.
    • Transfer: Entrypoint for moving tokens based on allowance rules.
    • Update Operators: Management of operator permissions.
    • Balance Of: TZIP-4 compliant view for balance information.

    Additional capabilities include TZIP-17 permit mechanisms for fee-less transfers, Rarible-compliant royalties for NFTs, and a global operator mechanism (operator_for_all) to manage all tokens of a specific owner.

  6. Overview of Archetype Dapp packages

    The Archetype Dapp ecosystem relies on three primary packages:

    • @completium/archetype-ts-types: Provides TypeScript types used by contract binding.
    • @completium/dapp-ts: Provides generic functions used by contract binding.
    • @completium/event-listener: Provides a client-side event indexer.

  7. Overview of Archetype smart contract design features

    Archetype offers several high-level features to improve the development and verification of Tezos smart contracts:

    • Explicit Execution Conditions: Readable checks to determine if a contract should execute.
    • State Machine Design: Ability to design contracts as state machines with guard conditions on transitions.
    • Rich Storage API: Specialized tools for accessing and manipulating collections of assets.

  8. Overview of the Archetype testing framework

    Smart contracts written in Archetype or Michelson are tested using a framework where tests are written in TypeScript and executed via Node.js. This setup leverages the npm/yarn ecosystem and provides strong typing to validate code at compilation time and within IDEs (e.g., VSCode, IntelliJ).

  9. Overview of the Archetype language

    Archetype is a generic-purpose language designed for developing smart contracts on the Tezos blockchain. It supports all Michelson features while providing high-level abstractions to make contract source code more precise, concise, and maintainable.

  10. Understand divergent instructions and failure behavior

    A divergent instruction is an instruction that causes an entrypoint to fail. When a failure occurs, all modifications to storage and operations executed by the entrypoint up to that point are cancelled, ensuring the contract state remains unchanged. However, the operation fee for an injected operation is still spent and not refunded. It is recommended to simulate (dry run) the entrypoint before injection to avoid unnecessary fee loss.

  11. Implement a whitelisting mechanism using the A 2 template

    The A 2 template implements the TZIP-15 norm for whitelisting mechanisms. It manages transfer authorizations between users based on list associations: a user A can transfer assets to user B if the list containing user A is associated with the list containing user B. This template also adheres to the TZIP-16 norm.
    # Repository for the A 2 template
https://github.com/completium/archetype-a2

  12. Implement a multi-signature contract using the MultiSig template

    The MultiSig contract is a generic-purpose multi-signature implementation following the TZIP-16 norm. It allows the execution of operations (such as transfers or contract entrypoints) only after they have been approved by a required number of designated managers. The workflow consists of three distinct phases:

    1. Propose: A manager submits a list of operations to be executed.
    2. Approve: Other managers review and approve the proposal.
    3. Execute: Once the required threshold of approvals is met, the operations can be executed by any user.