Merge branch 'main' into pr/315

.github/workflows/ci.yaml

@@ -13,7 +13,7 @@ jobs:
   save-pr:
     name: Save PR Number
     runs-on: ubuntu-latest
-    
+
     steps:
       - name: Save PR number
         env:
@@ -34,28 +34,28 @@ jobs:
   htmlproofer:
     name: HTMLProofer
     runs-on: ubuntu-latest
-    
+
     steps:
       - name: Checkout ARC Repository
         uses: actions/checkout@2541b1294d2704b0964813337f33b291d3f8596b
-      
+
       - name: Install OpenSSL
         run: sudo apt-get update && sudo apt-get install -y libcurl4-openssl-dev
-    
+
       - name: Install Ruby
         uses: ruby/setup-ruby@0a29871fe2b0200a17a4497bae54fe5df0d973aa
         with:
           ruby-version: 2.6.0
           bundler-cache: true
-        
+
       - name: Build Website
         run: |
           bundle exec jekyll doctor
           bundle exec jekyll build
-      
+
       - name: HTML Proofer
         run: bundle exec htmlproofer ./_site --check-html --check-opengraph --report-missing-names --log-level=:debug --assume-extension --empty-alt-ignore --timeframe=6w --disable-external
-      
+
       - name: DNS Validator
         run: bundle exec github-pages health-check
 

.github/workflows/dev-portal-content.yml

@@ -0,0 +1,67 @@
+name: Create Dev Portal Content
+
+on:
+  push:
+    branches:
+      - main # Trigger on changes to the main branch
+    paths:
+      - "ARCs/**" # Only run when files in the ARCs directory are changed
+
+jobs:
+  updateDevportal:
+    runs-on: ubuntu-latest
+
+    steps:
+      # Step 1: Checkout the repository
+      - name: Checkout code
+        uses: actions/checkout@v2
+
+      # Step 2: Set execute permission for the scripts and create the content directory if needed
+      - name: Make scripts executable
+        run: |
+          chmod +x _devportal/scripts/update-arcs.sh
+          chmod +x _devportal/scripts/update-guideline.sh
+          chmod +x _devportal/scripts/update-index.sh
+          mkdir -p _devportal/content
+
+      # Step 3: Set up Git identity
+      - name: Set up Git user
+        run: |
+          git config --global user.name 'github-actions'
+          git config --global user.email '[email protected]'
+
+      # Step 4: Run update-arcs.sh script
+      - name: Run update-arcs.sh
+        run: _devportal/scripts/update-arcs.sh
+
+      # Step 5: Run update-guideline.sh script
+      - name: Run update-guideline.sh
+        run: _devportal/scripts/update-guideline.sh
+
+      # Step 6: Run update-index.sh script
+      - name: Run update-index.sh
+        run: _devportal/scripts/update-index.sh
+
+      # Step 7: Force changes to be recognized by Git
+      - name: Touch modified files
+        run: |
+          find _devportal/content -type f -exec touch {} \;
+
+      # Step 8: Commit and force push changes to devportal
+      - name: Commit and force push changes to devportal
+        run: |
+          git add -A  # Ensure all changes are staged
+          git add -f _devportal/content/*
+          git commit -m "Auto-update ARC content and headers"
+          BRANCH_NAME="devportal"
+
+          # Check if the branch exists on the remote
+          if git ls-remote --exit-code --heads origin "$BRANCH_NAME"; then
+            echo "Branch $BRANCH_NAME exists on the remote. Force pushing updates."
+            git push origin main:"$BRANCH_NAME" --force  # Corrected force push from main to devportal
+          else
+            echo "Branch $BRANCH_NAME does not exist. Creating it and pushing."
+            git push origin main:"$BRANCH_NAME" --force  # Create the branch and force push
+          fi
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -1,4 +1,5 @@
 vendor
 
 .bundle
-_site/*
+_site/*
+_devportal/content/*.md

ARC-template.md

@@ -7,6 +7,7 @@ discussions-to: <URL>
 status: Draft
 type: <Standards Track, Meta, or Informational>
 category (*only required for Standards Track): <Interface, or ARC>
+subcategory: <General, Asa, Application, Explorer or Wallet>
 created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
 requires (*optional): <ARC number(s)>
 ---
@@ -15,7 +16,7 @@ This is the suggested template for new ARCs.
 
 Note that an ARC number will be assigned by an editor. When opening a pull request to submit your ARC, please use an abbreviated title in the filename, `arc-draft_title_abbrev.md`.
 
-The title should be 44 characters or less. It should not repeat the ARC number in title, irrespective of the category. 
+The title should be 44 characters or less. It should not repeat the ARC number in title, irrespective of the category.
 
 ## Abstract
 Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.

ARCs/arc-0000.md

@@ -1,11 +1,12 @@
 ---
 arc: 0
 title: ARC Purpose and Guidelines
-description: Guide explaning how to write a new ARC
+description: Guide explaining how to write a new ARC
 author: Ben Guidarelli (@barnjamin), Stéphane Barroso (@sudoweezy)
 discussions-to: https://github.com/algorandfoundation/ARCs/issues/9
 status: Living
 type: Meta
+sub-category: General
 created: 2021-10-28
 ---
 
@@ -17,14 +18,14 @@ ARC stands for Algorand Request for Comments. An ARC is a design document provid
 The ARC should provide a concise technical specification and a rationale for the feature.
 The ARC author is responsible for building consensus within the community and documenting dissenting opinions.
 
-We intend ARCs to be the primary mechanisms for proposing new features and collecting community technical input on an issue. 
+We intend ARCs to be the primary mechanisms for proposing new features and collecting community technical input on an issue.
 We maintain ARCs as text files in a versioned repository. Their revision history is the historical record of the feature proposal.
 
 ## Specification
 
 ### ARC Types
 
-There are three types of ARC:
+There are  three types of ARC:
 
 - A **Standards track ARC**: application-level standards and conventions, including contract standards such as NFT standards, Algorand ABI, URI schemes, library/package formats, and wallet formats.
 
@@ -235,7 +236,7 @@ This document was derived heavily from <a href="https://github.com/ethereum/eips
 
 ### Usage of related link
 
-Every link **SHOULD** be relative. 
+Every link **SHOULD** be relative.
 
 |OK|`[ARC-0](./arc-0000.md)`|
 |:-|-:|

ARCs/arc-0001.md

@@ -7,6 +7,7 @@ discussions-to: https://github.com/algorandfoundation/ARCs/issues/52
 status: Final
 type: Standards Track
 category: Interface
+sub-category: Wallet
 created: 2021-07-06
 ---
 
@@ -33,7 +34,7 @@ At a high-level the API allows to sign:
 * A valid group of transaction (aka atomic transfers).
 * (**OPTIONAL**) A list of groups of transactions.
 
-Signatures are requested by calling a function `signTxns(txns)` on a list `txns` of transactions. The dApp may also provide an optional parameter `opts`. 
+Signatures are requested by calling a function `signTxns(txns)` on a list `txns` of transactions. The dApp may also provide an optional parameter `opts`.
 
 Each transaction is represented by a `WalletTransaction` object. The only required field of a `WalletTransaction` is `txn`, a base64 encoding of the canonical msgpack encoding of the unsigned transaction. There are three main use cases:
 
@@ -167,7 +168,7 @@ export interface WalletTransaction {
    signers?: AlgorandAddress[];
 
    /**
-    * Optional base64 encoding of the canonical msgpack encoding of a 
+    * Optional base64 encoding of the canonical msgpack encoding of a
     * SignedTxn corresponding to txn, when signers=[]
     */
    stxn?: SignedTxnStr;
@@ -225,10 +226,10 @@ where:
 | Status Code | Name | Description |
 | ----------- | ---- | ----------- |
 | 4001 | User Rejected Request | The user rejected the request. |
-| 4100 | Unauthorized |  The requested operation and/or account has not been authorized by the user. | 
+| 4100 | Unauthorized |  The requested operation and/or account has not been authorized by the user. |
 | 4200 | Unsupported Operation | The wallet does not support the requested operation. |
 | 4201 | Too Many Transactions | The wallet does not support signing that many transactions at a time. |
-| 4202 | Unintialized Wallet | The wallet was not initialized properly beforehand. |
+| 4202 | Uninitialized Wallet | The wallet was not initialized properly beforehand. |
 | 4300 | Invalid Input | The input provided is invalid. |
 
 ### Wallet-specific extensions
@@ -245,7 +246,7 @@ Wallet-specific extensions **MUST** be designed such that a wallet not understan
 
 The call `signTxns(txns, opts)` **MUST** either throws an error or return an array `ret` of the same length of the `txns` array:
 
-1. If `txns[i].signers` is an empty array, the wallet **MUST NOT** sign the transaction `txns[i]`, and: 
+1. If `txns[i].signers` is an empty array, the wallet **MUST NOT** sign the transaction `txns[i]`, and:
   * if `txns[i].stxn` is not present, `ret[i]` **MUST** be set to `null`.
   * if `txns[i].stxn` is present and is a valid `SignedTxnStr` with the underlying transaction exactly matching `txns[i].txn`, `ret[i]` **MUST**  be set to `txns[i].stxn`. (See section on the semantic of `WalletTransaction` for the exact requirements on `txns[i].stxn`.)
   * otherwise, the wallet **MUST** throw a `4300` error.
@@ -280,7 +281,7 @@ Strong warning / warning / weak warning / informational messages are different l
   * If specified and if not a list of valid Algorand addresses, the wallet **MUST** reject.
   * If `signers` is an empty array, the transaction is for information purpose only and the wallet **SHALL NOT** sign it, even if it can (e.g., know the secret key of the sender address).
   * If `signers` is an array with more than 1 Algorand addresses:
-      * The wallet **MUST** reject if `msig` is not specified. 
+      * The wallet **MUST** reject if `msig` is not specified.
       * The wallet **MUST** reject if `signers` is not a subset of `msig.addrs`.
       * The wallet **MUST** try to return a `SignedTxn` with all the subsigs corresponding to `signers` signed. If it cannot, it **SHOULD** throw a `4001` error. Note that this is different than when `signers` is not provided, where the signing is only "best effort".
   * If `signers` is an array with a single Algorand address:
@@ -295,15 +296,15 @@ Strong warning / warning / weak warning / informational messages are different l
       * The wallet **MUST** reject if the field `txn` inside the `SignedTxn` object does not match exactly the `Transaction` object in `txn`.
       * The wallet **MAY NOT** check whether the other fields of the `SignedTxn` are valid. In particular, it **MAY** accept `stxn` even in the following cases: it contains an invalid signature `sig`, it contains both a signature `sig` and a logicsig `lsig`, it contains a logicsig `lsig` that always reject.
 * `message`:
-    * The wallet **MAY** decide to never print the message, to only print the first characters, or to make any changes to the messages that may be used to ensure a higher level of security. The wallet **MUST** be designed to ensure that the message cannot be easily used to trick the user to do an incorrect action. In particular, if displayed, the message must appear in an area that is easily and clearly identifiable as not trusted by the wallet. 
+    * The wallet **MAY** decide to never print the message, to only print the first characters, or to make any changes to the messages that may be used to ensure a higher level of security. The wallet **MUST** be designed to ensure that the message cannot be easily used to trick the user to do an incorrect action. In particular, if displayed, the message must appear in an area that is easily and clearly identifiable as not trusted by the wallet.
     * The wallet **MUST** prevent HTML/JS injection and must only display plaintext messages.
 * `groupMessage` obeys the same rules as `message`, except it is a message common to all the transactions of the group containing the current transaction. In addition, the wallet **MUST** reject if `groupMessage` is provided for a transaction that is not the first transaction of the group. Note that `txns` may contain multiple groups of transactions, one after the other (see the Group Validation section for details).
 
 ##### Particular Case without `signers`, nor `msig`, nor `senders`
 
-When neither `signers`, nor `msig`, nor `authAddr` are specified, the wallet **MAY** still sign the transaction using a multisig or a different authorized address than the sender address `txn.Sender`. It may also sign the transaction using a logicsig. 
+When neither `signers`, nor `msig`, nor `authAddr` are specified, the wallet **MAY** still sign the transaction using a multisig or a different authorized address than the sender address `txn.Sender`. It may also sign the transaction using a logicsig.
 
-However, in all these cases, the resulting `SignedTxn` **MUST** be such that it can be committed to the blockchain (assuming the transaction itself can be executed and that the account is not rekeyed in the meantime). 
+However, in all these cases, the resulting `SignedTxn` **MUST** be such that it can be committed to the blockchain (assuming the transaction itself can be executed and that the account is not rekeyed in the meantime).
 
 In particular, if a multisig is used, the numbers of subsigs provided must be at least equal to the multisig threshold. This is different from the case where `msig` is provided, where the wallet **MAY** provide fewer subsigs than the threshold.
 
@@ -332,7 +333,7 @@ The wallet should support the following two use cases:
 >An early draft of this ARC required that the size of a group of transactions must be greater than 1 but, since the Algorand protocol supports groups of size 1, this requirement had been changed so dApps don't have to have special cases for single transactions and can always send a group to the wallet.
 
 2. (**OPTIONAL**) `txns` is a concatenation of `txns` arrays of transactions of type 1:
-   * All transactions with the *same* non-zero group ID must be consecutive and must match their group ID. The wallet **MUST** reject if the above is not satisfied. 
+   * All transactions with the *same* non-zero group ID must be consecutive and must match their group ID. The wallet **MUST** reject if the above is not satisfied.
    * The wallet UI **MUST** be designed so that it is clear to the user when transactions are grouped (aka form an atomic transfers) and when they are not. It **SHOULD** provide very clear explanations that are understandable by beginner users, so that they cannot easily be tricked to sign what they believe is an atomic exchange while it is in actuality a one-sided payment.
 
 If `txns` does not match any of the formats above, the wallet **MUST** reject.
@@ -341,12 +342,12 @@ The wallet **MAY** choose to restrict the maximum size of the array `txns`. The
 
 An early draft of this API allowed to sign single transactions in a group without providing the other transactions in the group. For security reasons, this use case is now deprecated and **SHALL** not be allowed in new implementations. Existing implementations may continue allowing for single transactions to be signed if a very clear warning is displayed to the user. The warning **MUST** stress that signing the transaction may incur losses that are much higher than the amount of tokens indicated in the transaction. That is because potential future features of Algorand may later have such consequences (e.g., a signature of a transaction may actually authorize the full group under some circumstances).
 
-#### Transaction Validation 
+#### Transaction Validation
 
 ##### Inputs that Must Be Systematically Rejected
 
 * Transactions `WalletTransaction.txn` with fields that are not known by the wallet **MUST** be systematically rejected. In particular:
-    * Every field **MUST** be validated. 
+    * Every field **MUST** be validated.
     * Any extra field **MUST** systematically make the wallet reject.
     * This is to prevent any security issue in case of the introduction of new dangerous fields (such as `txn.RekeyTo` or `txn.CloseRemainderTo`).
 * Transactions of an unknown type (field `txn.Type`) **MUST** be rejected.
@@ -404,7 +405,7 @@ The last two items are expected to be defined in other documents.
 
 The requirements around group validation have been designed to prevent the following attack.
 
-The dApp pretends to buy 1 Algo for 10 USDC, but instead creates an atomic transfer with the user sending 1 Algo to the dApp and the dApp sending 0.01 USDC to the user. However, it sends to the wallet a 1 Algo and 10 USDC transactions. 
+The dApp pretends to buy 1 Algo for 10 USDC, but instead creates an atomic transfer with the user sending 1 Algo to the dApp and the dApp sending 0.01 USDC to the user. However, it sends to the wallet a 1 Algo and 10 USDC transactions.
 If the wallet does not verify that this is a valid group, it will make the user believe that they are signing for the correct atomic transfer.