@goplausible/algorand-mcp 3.0.7

package/dist/resources/knowledge/taxonomy/arcs:specs:arc-0078.md

@@ -0,0 +1,220 @@
+---
+arc: 78
+title: URI scheme, keyreg Transactions extension
+description: A specification for encoding Key Registration Transactions in a URI format.
+author: Tasos Bitsios (@tasosbit)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/314
+status: Final
+type: Standards Track
+category: Interface
+sub-category: General
+created: 2024-10-02
+extends: 26
+---
+
+## Abstract
+
+This URI specification represents an extension to the base Algorand URI encoding standard ([ARC-26](./arc-0026.md)) that specifies encoding of key registration transactions through deeplinks, QR codes, etc.
+
+## Specification
+
+### General format
+
+As in [ARC-26](./arc-0026.md), URIs follow the general format for URIs as set forth in <a href="https://www.rfc-editor.org/rfc/rfc3986">RFC 3986</a>. The path component consists of an Algorand address, and the query component provides additional transaction parameters.
+
+Elements of the query component may contain characters outside the valid range. These are encoded differently depending on their expected character set. The text components (note, xnote) must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence must be percent-encoded as described in RFC 3986. The binary components (votekey, selkey, etc.) must be encoded with base64url as specified in <a href="https://www.rfc-editor.org/rfc/rfc4648.html#section-5">RFC 4648 section 5</a>.
+
+### Scope
+
+This ARC explicitly supports the two major subtypes of key registration transactions:
+
+- Online keyreg transcation
+  - Declares intent to participate in consensus and configures required keys
+- Offline keyreg transaction
+  - Declares intent to stop participating in consensus
+
+The following variants of keyreg transactions are not defined:
+
+- Non-participating keyreg transcation
+  - This transaction subtype is considered deprecated
+- Heartbeat keyreg transaction
+  - This transaction subtype will be included in the future block incentives protocol. The protocol specifies that this transaction type must be submitted by a node in response to a programmatic "liveness challenge". It is not meant to be signed or submitted by an end user.
+
+### ABNF Grammar
+
+```
+algorandurn     = "algorand://" algorandaddress [ "?" keyregparams ]
+algorandaddress = *base32
+keyregparams    = keyregparam [ "&" keyregparams ]
+keyregparam     = [ typeparam / votekeyparam / selkeyparam / sprfkeyparam / votefstparam / votelstparam / votekdparam / noteparam / feeparam / otherparam ]
+typeparam       = "type=keyreg"
+votekeyparam    = "votekey=" *qbase64url
+selkeyparam     = "selkey=" *qbase64url
+sprfkeyparam    = "sprfkey=" *qbase64url
+votefstparam    = "votefst=" *qdigit
+votelstparam    = "votelst=" *qdigit
+votekdparam     = "votekdkey=" *qdigit
+noteparam       = (xnote | note)
+xnote           = "xnote=" *qchar
+note            = "note=" *qchar
+fee             = "fee=" *qdigit
+otherparam      = qchar *qchar [ "=" *qchar ]
+```
+
+- "qbase64url" corresponds to valid characters of "base64url" encoding, as defined in <a href="https://www.rfc-editor.org/rfc/rfc4648.html#section-5">RFC 4648 section 5</a>
+- "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this specification takes as separators.
+
+As in the base [ARC-26](./arc-0026.md) standard, the scheme component ("algorand:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys.
+
+### Query Keys
+
+- address: Algorand address of transaction sender. Required.
+
+- type: fixed to "keyreg". Used to disambiguate the transaction type from the base [ARC-26](./arc-0026.md) standard and other possible extensions. Required.
+
+- votekeyparam: The vote key parameter to use in the transaction. Encoded with <a href="https://www.rfc-editor.org/rfc/rfc4648.html#section-5">base64url</a> encoding. Required for keyreg online transactions.
+
+- selkeyparam: The selection key parameter to use in the transaction. Encoded with <a href="https://www.rfc-editor.org/rfc/rfc4648.html#section-5">base64url</a> encoding. Required for keyreg online transactions.
+
+- sprfkeyparam: The state proof key parameter to use in the transaction. Encoded with <a href="https://www.rfc-editor.org/rfc/rfc4648.html#section-5">base64url</a> encoding. Required for keyreg online transactions.
+
+- votefstparam: The first round on which the voting keys will valid. Required for keyreg online transactions.
+
+- votelstparam: The last round on which the voting keys will be valid. Required for keyreg online transactions.
+
+- votekdparam: The key dilution key parameter to use. Required for keyreg online transactions.
+
+- xnote: As in [ARC-26](./arc-0026.md). A URL-encoded notes field value that must not be modifiable by the user when displayed to users. Optional.
+
+- note: As in [ARC-26](./arc-0026.md). A URL-encoded default notes field value that the the user interface may optionally make editable by the user. Optional.
+
+- fee: Optional. A static fee to set for the transaction in microAlgos. Useful to signal intent to receive participation incentives (e.g. with a 2,000,000 microAlgo transaction fee.) Optional.
+
+- (others): optional, for future extensions
+
+### Appendix
+
+This section contains encoding examples. The raw transaction object is presented along with the resulting [ARC-78](./arc-0078.md) URI encoding.
+
+#### Encoding keyreg online transactioon with minimum fee
+
+The following raw keyreg transaction:
+
+```
+{
+  "txn": {
+    "fee": 1000,
+    "fv": 1345,
+    "gh:b64": "kUt08LxeVAAGHnh4JoAoAMM9ql/hBwSoiFtlnKNeOxA=",
+    "lv": 2345,
+    "selkey:b64": "+lfw+Y04lTnllJfncgMjXuAePe8i8YyVeoR9c1Xi78c=",
+    "snd:b64": "+gJAXOr2rkSCdPQ5DEBDLjn+iIptzLxB3oSMJdWMVyQ=",
+    "sprfkey:b64": "3NoXc2sEWlvQZ7XIrwVJjgjM30ndhvwGgcqwKugk1u5W/iy/JITXrykuy0hUvAxbVv0njOgBPtGFsFif3yLJpg==",
+    "type": "keyreg",
+    "votefst": 1300,
+    "votekd": 100,
+    "votekey:b64": "UU8zLMrFVfZPnzbnL6ThAArXFsznV3TvFVAun2ONcEI=",
+    "votelst": 11300
+  }
+}
+```
+
+Will result in this ARC-78 encoded URI:
+
+```
+algorand://7IBEAXHK62XEJATU6Q4QYQCDFY475CEKNXGLYQO6QSGCLVMMK4SLVTYLMY?
+type=keyreg
+&selkey=-lfw-Y04lTnllJfncgMjXuAePe8i8YyVeoR9c1Xi78c
+&sprfkey=3NoXc2sEWlvQZ7XIrwVJjgjM30ndhvwGgcqwKugk1u5W_iy_JITXrykuy0hUvAxbVv0njOgBPtGFsFif3yLJpg
+&votefst=1300
+&votekd=100
+&votekey=UU8zLMrFVfZPnzbnL6ThAArXFsznV3TvFVAun2ONcEI
+&votelst=11300
+```
+
+Note: newlines added for readability.
+
+Note the difference between base64 encoding in the raw object and base64url encoding in the URI parameters. For example, the selection key parameter `selkey` that begins with `+lfw+` in the raw object is encoded in base64url to `-lfw-`.
+
+Note: Here, the fee is omitted from the URI (due to being set to the minimum 1,000 microAlgos.) When the fee is omitted, it is left up to the application or wallet to decide. This is for demonstrative purposes - the ARC-78 standard does not require this behavior.
+
+#### Encoding keyreg offline transactioon
+
+The following raw keyreg transaction:
+
+```
+{
+  "txn": {
+    "fee": 1000,
+    "fv": 1776240,
+    "gh:b64": "kUt08LxeVAAGHnh4JoAoAMM9ql/hBwSoiFtlnKNeOxA=",
+    "lv": 1777240,
+    "snd:b64": "+gJAXOr2rkSCdPQ5DEBDLjn+iIptzLxB3oSMJdWMVyQ=",
+    "type": "keyreg"
+  }
+}
+```
+
+Will result in this ARC-78 encoded URI:
+
+```
+algorand://7IBEAXHK62XEJATU6Q4QYQCDFY475CEKNXGLYQO6QSGCLVMMK4SLVTYLMY?type=keyreg
+```
+
+This offline keyreg transaction encoding is the smallest compatible ARC-78 representation.
+
+
+#### Encoding keyreg online transactioon with custom fee and note
+
+The following raw keyreg transaction:
+
+```
+{
+  "txn": {
+    "fee": 2000000,
+    "fv": 1345,
+    "gh:b64": "kUt08LxeVAAGHnh4JoAoAMM9ql/hBwSoiFtlnKNeOxA=",
+    "lv": 2345,
+    "note:b64": "Q29uc2Vuc3VzIHBhcnRpY2lwYXRpb24gZnR3",
+    "selkey:b64": "+lfw+Y04lTnllJfncgMjXuAePe8i8YyVeoR9c1Xi78c=",
+    "snd:b64": "+gJAXOr2rkSCdPQ5DEBDLjn+iIptzLxB3oSMJdWMVyQ=",
+    "sprfkey:b64": "3NoXc2sEWlvQZ7XIrwVJjgjM30ndhvwGgcqwKugk1u5W/iy/JITXrykuy0hUvAxbVv0njOgBPtGFsFif3yLJpg==",
+    "type": "keyreg",
+    "votefst": 1300,
+    "votekd": 100,
+    "votekey:b64": "UU8zLMrFVfZPnzbnL6ThAArXFsznV3TvFVAun2ONcEI=",
+    "votelst": 11300
+  }
+}
+```
+
+Will result in this ARC-78 encoded URI:
+
+```
+algorand://7IBEAXHK62XEJATU6Q4QYQCDFY475CEKNXGLYQO6QSGCLVMMK4SLVTYLMY?
+type=keyreg
+&selkey=-lfw-Y04lTnllJfncgMjXuAePe8i8YyVeoR9c1Xi78c
+&sprfkey=3NoXc2sEWlvQZ7XIrwVJjgjM30ndhvwGgcqwKugk1u5W_iy_JITXrykuy0hUvAxbVv0njOgBPtGFsFif3yLJpg
+&votefst=1300
+&votekd=100
+&votekey=UU8zLMrFVfZPnzbnL6ThAArXFsznV3TvFVAun2ONcEI
+&votelst=11300
+&fee=2000000
+&note=Consensus%2Bparticipation%2Bftw
+```
+
+Note: newlines added for readability.
+
+## Rationale
+
+The present aims to provide a standardized way to encode key registration transactions in order to enhance the user experience of signing key registration transactions in general, and in particular in the use case of an Algorand node runner that does not have their spending keys resident on their node (as is best practice.)
+
+The parameter names were chosen to match the corresponding names in encoded key registration transactions.
+
+## Security Considerations
+
+None.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.

package/dist/resources/knowledge/taxonomy/arcs:specs:arc-0079.md

@@ -0,0 +1,109 @@
+---
+arc: 79
+title: URI scheme, App NoOp call extension
+description: A specification for encoding NoOp Application call Transactions in a URI format.
+author: MG (@emg110)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/319
+status: Final
+type: Standards Track
+category: Interface
+sub-category: General
+created: 2024-09-11
+extends: 26
+---
+
+## Abstract
+NoOp calls are Generic application calls to execute the Algorand smart contract ApprovalPrograms.
+
+This URI specification proposes an extension to the base Algorand URI encoding standard ([ARC-26](./arc-0026.md)) that specifies encoding of application NoOp transactions into <a href="https://www.rfc-editor.org/rfc/rfc3986">RFC 3986</a> standard URIs.
+
+## Specification
+
+### General format
+
+As in [ARC-26](./arc-0026.md), URIs follow the general format for URIs as set forth in <a href="https://www.rfc-editor.org/rfc/rfc3986">RFC 3986</a>. The path component consists of an Algorand address, and the query component provides additional transaction parameters.
+
+Elements of the query component may contain characters outside the valid range. These are encoded differently depending on their expected character set. The text components (note, xnote) must first be encoded according to UTF-8, and then each octet of the corresponding UTF-8 sequence **MUST** be percent-encoded as described in RFC 3986. The binary components (args, refs, etc.) **MUST** be encoded with base64url as specified in <a href="https://www.rfc-editor.org/rfc/rfc4648.html#section-5">RFC 4648 section 5</a>.
+
+### ABNF Grammar
+
+```
+algorandurn     = "algorand://" algorandaddress [ "?" noopparams ]
+algorandaddress = *base32
+noopparams      = noopparam [ "&" noopparams ]
+noopparam       = [ typeparam / appparam /  methodparam / argparam / boxparam / assetarrayparam / accountarrayparam / apparrayparam / feeparam / otherparam ]
+typeparam       = "type=appl"
+appparam        = "app=" *digit
+methodparam     = "method=" *qchar
+boxparam        = "box=" *qbase64url
+argparam        = "arg=" (*qchar | *digit)
+feeparam        = "fee=" *digit
+accountparam    = "account=" *base32
+assetparam      = "asset=" *digit
+otherparam      = qchar *qchar [ "=" *qchar ]
+```
+
+- "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this specification takes as separators.
+- "qbase64url" corresponds to valid characters of "base64url" encoding, as defined in <a href="https://www.rfc-editor.org/rfc/rfc4648.html#section-5">RFC 4648 section 5</a>
+- All params from the base [ARC-26](./arc-0026.md) standard, are supported and usable if fit the NoOp application call context (e.g. note)
+- As in the base [ARC-26](./arc-0026.md) standard, the scheme component ("algorand:") is case-insensitive, and implementations **MUST** accept any combination of uppercase and lowercase letters. The rest of the URI is case-sensitive, including the query parameter keys.
+
+### Query Keys
+
+- address: Algorand address of transaction sender
+
+- type: fixed to "appl". Used to disambiguate the transaction type from the base [ARC-26](./arc-0026.md) standard and other possible extensions
+
+- app: The first reference is set to specify the called application (Algorand Smart Contract) ID and is mandatory. Additional references are optional and will be used in the Application NoOp call's foreign applications array.
+
+- method: Specify the full method expression (e.g "example_method(uint64,uint64)void").
+
+- arg: specify args used for calling NoOp method, to be encoded within URI.
+
+- box: Box references to be used in Application NoOp method call box array.
+
+- asset: Asset reference to be used in Application NoOp method call foreign assets array.
+
+- account: Account or nfd address to be used in Application NoOp method call foreign accounts array.
+
+- fee: Optional. An optional static fee to set for the transaction in microAlgos.
+
+- (others): optional, for future extensions
+
+Note 1: If the fee is omitted , it means that Minimum Fee is preferred to be used for transaction.
+
+### Template URI vs actionable URI
+
+If the URI is constructed so that other dApps, wallets or protocols could use it with their runtime Algorand entities of interest, then :
+
+- The placeholder account/app address in URI **MUST** be ZeroAddress ("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY5HFKQ"). Since ZeroAddress cannot initiate any action this approach is considered non-vulnerable and secure.
+
+
+### Example
+
+Call claim(uint64,uint64)byte[] method on contract 11111111 paying a fee of 10000 micro ALGO from an specific address
+
+```
+algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?type=appl&app=11111111&method=claim(uint64,uint64)byte[]&arg=20000&arg=474567&asset=45&fee=10000
+```
+
+Call the same claim(uint64,uint64)byte[] method on contract 11111111 paying a default 1000 micro algo fee
+
+```
+algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?type=appl&app=11111111&method=claim(uint64,uint64)byte[]&arg=20000&arg=474567&asset=45&app=22222222&app=33333333
+```
+
+
+
+## Rationale
+
+Algorand application NoOp method calls cover the majority of application transactions in Algorand and have a wide range of use-cases.
+For use-cases where the runtime knows exactly what the called application needs in terms of arguments and transaction arrays and there are no direct interactions, this extension will be required since ARC-26 standard does not currently support application calls.
+
+## Security Considerations
+
+None.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.

package/dist/resources/knowledge/taxonomy/arcs:specs:arc-0200.md

@@ -0,0 +1,232 @@
+---
+arc: 200
+title: Algorand Smart Contract Token Specification
+description: Base specification for tokens implemented as smart contracts
+author: Nicholas Shellabarger (@temptemp3)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/223
+status: Living
+type: Standards Track
+category: Interface
+sub-category: Application
+created: 2023-07-03
+requires: 3, 4, 22, 28
+---
+
+# Algorand Smart Contract Token Specification
+
+## Abstract
+
+This ARC (Algorand Request for Comments) specifies an interface for tokens to be implemented on Algorand as smart contracts. The interface defines a minimal interface required for tokens to be held and transferred, with the potential for further augmentation through additional standard interfaces and custom methods.
+
+## Motivation
+
+Currently, most tokens in the Algorand ecosystem are represented by ASAs (Algorand Standard Assets). However, to provide rich extra functionality, it can be desirable to implement tokens as smart contracts instead. To foster an interoperable token ecosystem, it is necessary that the core interfaces for tokens be standardized.
+
+## Specification
+
+The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL NOT**", "**SHOULD**", "**SHOULD NOT**", "**RECOMMENDED**", "**MAY**", and "**OPTIONAL**" in this document are to be interpreted as described in <a href="https://www.ietf.org/rfc/rfc2119.txt">RFC-2119</a>.
+
+### Core Token specification
+
+A smart contract token that is compliant with this standard MUST implement the following interface:
+
+```json
+{
+  "name": "ARC-200",
+  "desc": "Smart Contract Token Base Interface",
+  "methods": [
+    {
+      "name": "arc200_name",
+      "desc": "Returns the name of the token",
+      "readonly": true,
+      "args": [],
+      "returns": { "type": "byte[32]", "desc": "The name of the token" }
+    },
+    {
+      "name": "arc200_symbol",
+      "desc": "Returns the symbol of the token",
+      "readonly": true,
+      "args": [],
+      "returns": { "type": "byte[8]", "desc": "The symbol of the token" }
+    },
+    {
+      "name": "arc200_decimals",
+      "desc": "Returns the decimals of the token",
+      "readonly": true,
+      "args": [],
+      "returns": { "type": "uint8", "desc": "The decimals of the token" }
+    },
+    {
+      "name": "arc200_totalSupply",
+      "desc": "Returns the total supply of the token",
+      "readonly": true,
+      "args": [],
+      "returns": { "type": "uint256", "desc": "The total supply of the token" }
+    },
+    {
+      "name": "arc200_balanceOf",
+      "desc": "Returns the current balance of the owner of the token",
+      "readonly": true,
+      "args": [
+        {
+          "type": "address",
+          "name": "owner",
+          "desc": "The address of the owner of the token"
+        }
+      ],
+      "returns": {
+        "type": "uint256",
+        "desc": "The current balance of the holder of the token"
+      }
+    },
+    {
+      "name": "arc200_transfer",
+      "desc": "Transfers tokens",
+      "readonly": false,
+      "args": [
+        {
+          "type": "address",
+          "name": "to",
+          "desc": "The destination of the transfer"
+        },
+        {
+          "type": "uint256",
+          "name": "value",
+          "desc": "Amount of tokens to transfer"
+        }
+      ],
+      "returns": { "type": "bool", "desc": "Success" }
+    },
+    {
+      "name": "arc200_transferFrom",
+      "desc": "Transfers tokens from source to destination as approved spender",
+      "readonly": false,
+      "args": [
+        {
+          "type": "address",
+          "name": "from",
+          "desc": "The source  of the transfer"
+        },
+        {
+          "type": "address",
+          "name": "to",
+          "desc": "The destination of the transfer"
+        },
+        {
+          "type": "uint256",
+          "name": "value",
+          "desc": "Amount of tokens to transfer"
+        }
+      ],
+      "returns": { "type": "bool", "desc": "Success" }
+    },
+    {
+      "name": "arc200_approve",
+      "desc": "Approve spender for a token",
+      "readonly": false,
+      "args": [
+        { "type": "address", "name": "spender" },
+        { "type": "uint256", "name": "value" }
+      ],
+      "returns": { "type": "bool", "desc": "Success" }
+    },
+    {
+      "name": "arc200_allowance",
+      "desc": "Returns the current allowance of the spender of the tokens of the owner",
+      "readonly": true,
+      "args": [
+        { "type": "address", "name": "owner" },
+        { "type": "address", "name": "spender" }
+      ],
+      "returns": { "type": "uint256", "desc": "The remaining allowance" }
+    }
+  ],
+  "events": [
+    {
+      "name": "arc200_Transfer",
+      "desc": "Transfer of tokens",
+      "args": [
+        {
+          "type": "address",
+          "name": "from",
+          "desc": "The source of transfer of tokens"
+        },
+        {
+          "type": "address",
+          "name": "to",
+          "desc": "The destination of transfer of tokens"
+        },
+        {
+          "type": "uint256",
+          "name": "value",
+          "desc": "The amount of tokens transferred"
+        }
+      ]
+    },
+    {
+      "name": "arc200_Approval",
+      "desc": "Approval of tokens",
+      "args": [
+        {
+          "type": "address",
+          "name": "owner",
+          "desc": "The owner of the tokens"
+        },
+        {
+          "type": "address",
+          "name": "spender",
+          "desc": "The approved spender of tokens"
+        },
+        {
+          "type": "uint256",
+          "name": "value",
+          "desc": "The amount of tokens approve"
+        }
+      ]
+    }
+  ]
+}
+```
+
+Ownership of a token by a zero address indicates that a token is out of circulation indefinitely, or otherwise burned or destroyed.
+
+The methods `arc200_transfer` and `arc200_transferFrom` method MUST error when the balance of `from` is insufficient. In the case of the `arc200_transfer` method, from is implied as the `owner` of the token.
+The `arc200_transferFrom` method MUST error unless called by an `spender` approved by an `owner`.
+The methods `arc200_transfer` and `arc200_transferFrom` MUST emit a `Transfer` event.
+A `arc200_Transfer` event SHOULD be emitted, with `from` being the zero address, when a token is minted.
+A `arc200_Transfer` event SHOULD be emitted, with `to` being the zero address, when a token is destroyed.
+
+The `arc200_Approval` event MUST be emitted when an `arc200_approve` or `arc200_transferFrom` method is called successfully.
+
+A value of zero for the `arc200_approve` method and the `arc200_Approval` event indicates no approval.
+The `arc200_transferFrom` method and the `arc200_Approval` event indicates the approval value after it is decremented.
+
+The contract MUST allow multiple operators per owner.
+
+All methods in this standard that are marked as `readonly` MUST be read-only as defined by [ARC-22](./arc-0022.md).
+
+## Rationale
+
+This specification is based on <a href="https://eips.ethereum.org/EIPS/eip-20">ERC-20</a>.
+
+### Core Specification
+
+The core specification identical to ERC-20.
+
+## Backwards Compatibility
+
+This standard introduces a new kind of token that is incompatible with tokens defined as ASAs.
+Applications that want to index, manage, or view tokens on Algorand will need to handle these new smart tokens as well as the already popular ASA implementation of tokens will need to add code to handle both, and existing smart contracts that handle ASA-based tokens will not work with these new smart contract tokens.
+
+While this is a severe backward incompatibility, smart contract tokens are necessary to provide richer and more diverse functionality for tokens.
+
+## Security Considerations
+
+The fact that anybody can create a new implementation of a smart contract tokens standard opens the door for many of those implementations to contain security bugs.
+Additionally, malicious token implementations could contain hidden anti-features unexpected by users.
+As with other smart contract domains, it is difficult for users to verify or understand the security properties of smart contract tokens.
+This is a tradeoff compared with ASA tokens, which share a smaller set of security properties that are easier to validate to gain the possibility of adding novel features.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.