@goplausible/algorand-mcp 3.0.7

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

@@ -0,0 +1,112 @@
+---
+arc: 26
+title: URI scheme
+description: A specification for encoding Transactions in a URI format.
+author: Fabrice Benhamouda (@fabrice102), Ben Guidarelli (@barnjamin)
+status: Final
+type: Standards Track
+category: Interface
+sub-category: General
+created: 2022-04-21
+extended-by: 78, 79
+---
+
+## Abstract
+
+This URI specification represents a standardized way for applications and websites to send requests and information through deeplinks, QR codes, etc. It is heavily based on Bitcoin’s <a href="https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki">BIP-0021</a> and should be seen as derivative of it. The decision to base it on BIP-0021 was made to make it easy and compatible as possible for any other application.
+
+## Specification
+
+### General format
+
+Algorand 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 payment options.
+
+Elements of the query component may contain characters outside the valid range. These 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.
+
+### ABNF Grammar
+
+```
+algorandurn     = "algorand://" algorandaddress [ "?" algorandparams ]
+algorandaddress = *base32
+algorandparams  = algorandparam [ "&" algorandparams ]
+algorandparam   = [ amountparam / labelparam / noteparam / assetparam / otherparam ]
+amountparam     = "amount=" *digit
+labelparam      = "label=" *qchar
+assetparam      = "asset=" *digit
+noteparam       = (xnote | note)
+xnote           = "xnote=" *qchar
+note            = "note=" *qchar
+otherparam      = qchar *qchar [ "=" *qchar ]
+```
+
+Here, "qchar" corresponds to valid characters of an RFC 3986 URI query component, excluding the "=" and "&" characters, which this specification takes as separators.
+
+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.
+
+!!! Caveat
+    When it comes to generation of an address' QR,  many exchanges and wallets encodes the address w/o the scheme component (“algorand:”). This is not a URI so it is OK.
+
+### Query Keys
+
+- label: Label for that address (e.g. name of receiver)
+
+- address: Algorand address
+
+- xnote: A URL-encoded notes field value that must not be modifiable by the user when displayed to users.
+
+- note: A URL-encoded default notes field value that the the user interface may optionally make editable by the user.
+
+- amount: microAlgos or smallest unit of asset
+
+- asset: The asset id this request refers to (if Algos, simply omit this parameter)
+
+- (others): optional, for future extensions
+
+### Transfer amount/size
+
+!!! Note
+    This is DIFFERENT than Bitcoin’s BIP-0021
+
+If an amount is provided, it MUST be specified in basic unit of the asset. For example, if it’s Algos (Algorand native unit), the amount should be specified in microAlgos. All amounts MUST NOT contain commas nor a period (.) Strictly non negative integers.
+
+e.g. for 100 Algos, the amount needs to be 100000000, for 54.1354 Algos the amount needs to be 54135400.
+
+Algorand Clients should display the amount in whole Algos. Where needed, microAlgos can be used as well. In any case, the units shall be clear for the user.
+
+### Appendix
+
+This section contains several examples
+
+address -
+
+```
+algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4
+```
+
+address with label -
+
+```
+algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?label=Silvio
+```
+
+Request 150.5 Algos from an address
+
+```
+algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?amount=150500000
+```
+
+Request 150 units of Asset ID 45 from an address
+
+```
+algorand://TMTAD6N22HCS2LKH7677L2KFLT3PAQWY6M4JFQFXQS32ECBFC23F57RYX4?amount=150&asset=45
+```
+
+## Rationale
+
+## 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-0028.md

@@ -0,0 +1,176 @@
+---
+arc: 28
+title: Algorand Event Log Spec
+description: A methodology for structured logging by Algorand dapps.
+author: Dan Burton (@DanBurton)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/144
+status: Final
+type: Standards Track
+category: ARC
+sub-category: Application
+created: 2022-07-18
+requires: 4
+---
+
+# Algorand Event Log Spec
+
+## Abstract
+
+Algorand dapps can use the <a href="https://developer.algorand.org/docs/get-details/dapps/avm/teal/opcodes/#log">`log`</a>  primitive to attach information about an application call. This ARC proposes the concept of Events, which are merely a way in which data contained in these logs may be categorized and structured.
+
+In short: to emit an Event, a dapp calls `log` with ABI formatting of the log data, and a 4-byte prefix to indicate which Event it is.
+
+## Specification
+
+Each kind of Event emitted by a given dapp has a unique 4-byte identifier. This identifier is derived from its name and the structure of its contents, like so:
+
+### Event Signature
+
+An Event Signature is a utf8 string, comprised of: the name of the event, followed by an open paren, followed by the comma-separated names of the data types contained in the event (Types supported are the same as in [ARC-4](./arc-0004.md#types)), followed by a close paren. This follows naming conventions similar to ABI signatures, but does not include the return type.
+
+### Deriving the 4-byte prefix from the Event Signature
+
+To derive the 4-byte prefix from the Event Signature, perform the `sha512/256` hash algorithm on the signature, and select the first 4 bytes of the result.
+
+This is the same process that is used by the [ABI Method Selector ](./arc-0004.md#method-selector) as specified in ARC-4.
+
+### Argument Encoding
+
+The arguments to a tuple **MUST** be encoded as if they were a single [ARC-4](./arc-0004.md) tuple (opposed to concatenating the encoded values together). For example, an event signature `foo(string,string)` would contain the 4-byte prefix and a `(string,string)` encoded byteslice.
+
+### ARC-4 Extension
+
+#### Event
+
+An event is represented as follow:
+
+```typescript
+interface Event {
+  /** The name of the event */
+  name: string;
+  /** Optional, user-friendly description for the event */
+  desc?: string;
+  /** The arguments of the event, in order */
+  args: Array<{
+    /** The type of the argument */
+    type: string;
+    /** Optional, user-friendly name for the argument */
+    name?: string;
+    /** Optional, user-friendly description for the argument */
+    desc?: string;
+  }>;
+}
+```
+
+#### Method
+
+This ARC extends ARC-4 by adding an array events of type `Event[]` to the `Method` interface. Concretely, this give the following extended Method interface:
+
+```typescript
+interface Method {
+  /** The name of the method */
+  name: string;
+  /** Optional, user-friendly description for the method */
+  desc?: string;
+  /** The arguments of the method, in order */
+  args: Array<{
+    /** The type of the argument */
+    type: string;
+    /** Optional, user-friendly name for the argument */
+    name?: string;
+    /** Optional, user-friendly description for the argument */
+    desc?: string;
+  }>;
+  /** All of the events that the method use */
+  events: Event[];
+  /** Information about the method's return value */
+  returns: {
+    /** The type of the return value, or "void" to indicate no return value. */
+    type: string;
+    /** Optional, user-friendly description for the return value */
+    desc?: string;
+  };
+}
+```
+
+#### Contract
+> Even if events are already inside `Method`, the contract **MUST** provide an array of `Events` to improve readability.
+
+```typescript
+interface Contract {
+  /** A user-friendly name for the contract */
+  name: string;
+  /** Optional, user-friendly description for the interface */
+  desc?: string;
+  /**
+   * Optional object listing the contract instances across different networks
+   */
+  networks?: {
+    /**
+     * The key is the base64 genesis hash of the network, and the value contains
+     * information about the deployed contract in the network indicated by the
+     * key
+     */
+    [network: string]: {
+      /** The app ID of the deployed contract in this network */
+      appID: number;
+    }
+  }
+  /** All of the methods that the contract implements */
+  methods: Method[];
+  /** All of the events that the contract contains */
+  events: Event[];
+}
+```
+
+## Rationale
+
+Event logging allows a dapp to convey useful information about the things it is doing.  Well-designed Event logs allow observers to more easily interpret the history of interactions with the dapp. A structured approach to Event logging could also allow for indexers to more efficiently store and serve queryable data exposed by the dapp about its history.
+
+## Reference Implementation
+
+### Sample interpretation of Event log data
+
+An exchange dapp might emit a `Swapped` event with two `uint64` values representing quantities of currency swapped. The event signature would be: `Swapped(uint64,uint64)`.
+
+Suppose that dapp emits the following log data (seen here as base64 encoded): `HMvZJQAAAAAAAAAqAAAAAAAAAGQ=`.
+
+Suppose also that the dapp developers have declared that it follows this spec for Events, and have published the signature `Swapped(uint64,uint64)`.
+
+We can attempt to parse this log data to see if it is one of these events, as follows. (This example is written in JavaScript.)
+
+First, we can determine the expected 4-byte prefix by following the spec above:
+
+```js
+> { sha512_256 } = require('js-sha512')
+> sig = 'Swapped(uint64,uint64)'
+'Swapped(uint64,uint64)'
+> hash = sha512_256(sig)
+'1ccbd9254b9f2e1caf190c6530a8d435fc788b69954078ab937db9b5540d9567'
+> prefix = hash.slice(0,8) // 8 nibbles = 4 bytes
+'1ccbd925'
+```
+
+Next, we can inspect the data to see if it matches the expected format:
+4 bytes for the prefix, 8 bytes for the first uint64, and 8 bytes for the next.
+
+```js
+> b = Buffer.from('HMvZJQAAAAAAAAAqAAAAAAAAAGQ=', 'base64')
+<Buffer 1c cb d9 25 00 00 00 00 00 00 00 2a 00 00 00 00 00 00 00 64>
+> b.slice(0,4).toString('hex')
+'1ccbd925'
+> b.slice(4, 12)
+<Buffer 00 00 00 00 00 00 00 2a>
+> b.slice(12,20)
+<Buffer 00 00 00 00 00 00 00 64>
+```
+
+We see that the 4-byte prefix matches the signature for `Swapped(uint64,uint64)`, and that the rest of the data can be interpreted using the types declared for that signature. We interpret the above Event data to be: `Swapped(0x2a,0x64)`, meaning `Swapped(42,100)`.
+
+## Security Considerations
+
+As specify in ARC-4, methods which have a `return` value MUST NOT emit an event after they log their `return` value.
+
+## 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-0032.md

@@ -0,0 +1,286 @@
+---
+arc: 32
+title: Application Specification
+description: A specification for fully describing an Application, useful for Application clients.
+author: Benjamin Guidarelli (@barnjamin)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/150
+status: Final
+type: Standards Track
+category: ARC
+sub-category: Application
+created: 2022-12-01
+requires: 4, 21
+---
+
+## Abstract
+
+> [!NOTE]
+> This specification will be eventually deprecated by the <a href="https://github.com/algorandfoundation/ARCs/pull/258">`ARC-56`</a> specification.
+
+An Application is partially defined by it's [methods](./arc-0004.md) but further information about the Application should be available.  Other descriptive elements of an application may include it's State Schema, the original TEAL source programs, default method arguments, and custom data types.  This specification defines the descriptive elements of an Application that should be available to clients to provide useful information for an Application Client.
+
+## Motivation
+
+As more complex Applications are created and deployed, some consistent way to specify the details of the application and how to interact with it becomes more important.  A specification to allow a consistent and complete definition of an application will help developers attempting to integrate an application they've never worked with before.
+
+## 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/rfc822.txt">RFC 822</a>..
+
+### Definitions
+
+- [Application Specification](#application-specification): The object containing the elements describing the Application.
+- [Source Specification](#source-specification): The object containing a description of the TEAL source programs that are evaluated when this Application is called.
+- [Schema Specification](#schema-specification): The object containing a description of the schema required by the Application.
+- [Bare Call Specification](#bare-call-specification): The object containing a map of on completion actions to allowable calls for bare methods
+- [Hints Specification](#hints-specification): The object containing a map of method signatures to meta data about each method
+
+
+### Application Specification
+
+The Application Specification is composed of a number of elements that serve to fully describe the Application.
+
+```ts
+type AppSpec = {
+  // embedded contract fields, see ARC-0004 for more
+  contract: ARC4Contract;
+
+  // the original teal source, containing annotations, base64 encoded
+  source?: SourceSpec;
+  // the schema this application requires/provides
+  schema?: SchemaSpec;
+
+  // supplemental information for calling bare methods
+  bare_call_config?: CallConfigSpec;
+  // supplemental information for calling ARC-0004 ABI methods
+  hints: HintsSpec;
+  // storage requirements
+  state?: StateSpec;
+}
+```
+
+### Source Specification
+
+Contains the source TEAL files including comments and other annotations.
+
+```ts
+// Object containing the original TEAL source files
+type SourceSpec = {
+  // b64 encoded approval program
+  approval: string;
+  // b64 encoded clear state program
+  clear: string;
+}
+```
+
+### Schema Specification
+
+The schema of an application is critical to know prior to creation since it is immutable after create. It also helps clients of the application understand the data that is available to be queried from off chain. Individual fields can be referenced from the [default argument](#default-argument) to provide input data to a given ABI method.
+
+While some fields are possible to know ahead of time, others may be keyed dynamically. In both cases the data type being stored MUST be known and declared ahead of time.
+
+```ts
+// The complete schema for this application
+type SchemaSpec = {
+  local: Schema;
+  global: Schema;
+}
+
+// Schema fields may be declared explicitly or reserved
+type Schema = {
+  declared: Record<string, DeclaredSchemaValueSpec>;
+  reserved: Record<string, ReservedSchemaValueSpec>;
+}
+
+// Types supported for encoding/decoding
+enum AVMType { uint64, bytes }
+// string encoded datatype name defined in arc-4
+type ABIType = string;
+
+// Fields that have an explicit key
+type DeclaredSchemaValueSpec = {
+  type: AVMType | ABIType;
+  key: string;
+  descr: string;
+}
+
+// Fields that have an undetermined key
+type ReservedSchemaValueSpec = {
+  type: AVMType | ABIType;
+  descr: string;
+  max_keys: number;
+}
+
+```
+
+### Bare call specification
+
+Describes the supported OnComplete actions for bare calls on the contract.
+
+```ts
+// describes under what conditions an associated OnCompletion type can be used with a particular method
+// NEVER: Never handle the specified on completion type
+// CALL: Only handle the specified on completion type for application calls
+// CREATE: Only handle the specified on completion type for application create calls
+// ALL: Handle the specified on completion type for both create and normal application calls
+type CallConfig = 'NEVER' | 'CALL' | 'CREATE' | 'ALL'
+
+type CallConfigSpec = {
+    // lists the supported CallConfig for each on completion type, if not specified a CallConfig of NEVER is assumed
+    no_op?: CallConfig
+    opt_in?: CallConfig
+    close_out?: CallConfig
+    update_application?: CallConfig
+    delete_application?: CallConfig
+}
+```
+
+### Hints specification
+
+Contains supplemental information about [ARC-0004](./arc-0004.md) ABI methods, each record represents a single method in the [ARC-0004](./arc-0004.md) contract. The record key should be the corresponding ABI signature.
+
+NOTE: Ideally this information would be part of the [ARC-0004](./arc-0004.md) ABI specification.
+
+```ts
+type HintSpec = {
+  // indicates the method has no side-effects and can be call via dry-run/simulate
+  read_only?: bool;
+  // describes the structure of arguments, key represents the argument name
+  structs?: Record<string, StructSpec>;
+  // describes source of default values for arguments, key represents the argument name
+  default_arguments?: Record<string, DefaultArgumentSpec>;
+  // describes which OnCompletion types are supported
+  call_config: CallConfigSpec;
+}
+
+// key represents the method signature for an ABI method defined in 'contracts'
+type HintsSpec = Record<string, HintSpec>
+```
+
+#### Readonly Specification
+
+Indicates the method has no side-effects and can be called via dry-run/simulate
+
+NOTE: This property is made obsolete by [ARC-0022](./arc-0022.md) but is included as it is currently
+used by existing reference implementations such as Beaker
+
+#### Struct Specification
+
+Each defined type is specified as an array of `StructElement`s.
+
+The ABI encoding is exactly as if an ABI Tuple type defined the same element types in the same order.
+It is important to encode the struct elements as an array since it preserves the order of fields which is critical to encoding/decoding the data properly.
+
+```ts
+// Type aliases for readability
+type FieldName = string
+// string encoded datatype name defined in ARC-0004
+type ABIType = string
+
+// Each field in the struct contains a name and ABI type
+type StructElement = [FieldName, ABIType]
+// Type aliases for readability
+type ContractDefinedType = StructElement[]
+type ContractDefinedTypeName = string;
+
+// represents a input/output structure
+type StructSpec = {
+  name: ContractDefinedTypeName
+  elements: ContractDefinedType
+}
+```
+
+For example a `ContractDefinedType` that should provide an array of `StructElement`s
+
+Given the PyTeal:
+```py
+from pyteal import abi
+
+class Thing(abi.NamedTuple):
+  addr: abi.Field[abi.address]
+  balance: abi.Field[abi.Uint64]
+```
+the equivalent ABI type is `(address,uint64)` and an element in the TypeSpec is:
+
+```js
+{
+// ...
+"Thing":[["addr", "address"]["balance","uint64"]],
+// ...
+}
+```
+
+#### Default Argument
+
+Defines how default argument values can be obtained. The `source` field defines how a default value is obtained, the `data` field
+contains additional information based on the `source` value.
+
+Valid values for `source` are:
+* "constant" - `data` is the value to use
+* "global-state" - `data` is the global state key.
+* "local-state" - `data` is the local state key
+* "abi-method" - `data` is a reference to the ABI method to call. Method should be read only and return a value of the appropriate type
+
+Two scenarios where providing default arguments can be useful:
+
+1. Providing a default value for optional arguments
+
+2. Providing a value for required arguments such as foreign asset or application references without requiring the client to explicitly determine these values when calling the contract
+
+
+```ts
+// ARC-0004 ABI method definition
+type ABIMethod = {};
+
+type DefaultArgumentSpec = {
+  // Where to look for the default arg value
+  source: "constant" | "global-state" | "local-state" | "abi-method"
+  // extra data to include when looking up the value
+  data: string | bigint | number | ABIMethod
+}
+```
+
+### State Specifications
+
+Describes the total storage requirements for both global and local storage, this should include both declared and reserved described in SchemaSpec.
+
+NOTE: If the Schema specification contained additional information such that the size could be calculated, then this specification would not be required.
+
+```ts
+type StateSchema = {
+  // how many byte slices are required
+  num_byte_slices: number
+  // how many uints are required
+  num_uints: number
+}
+
+type StateSpec = {
+  // schema specification for global storage
+  global: StateSchema
+  // schema specification for local storage
+  local: StateSchema
+}
+```
+
+### Reference schema
+
+A full JSON schema for application.json can be found in [here](../assets/arc-0032/application.schema.json).
+
+## Rationale
+The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
+
+## Backwards Compatibility
+All ARCs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ARC must explain how the author proposes to deal with these incompatibilities. ARC submissions without a sufficient backwards compatibility treatise may be rejected outright.
+
+## Test Cases
+Test cases for an implementation are mandatory for ARCs that are affecting consensus changes.  If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/arc-####/`.
+
+## Reference Implementation
+
+`algokit-utils-py` and `algokit-utils-ts` both provide reference implementations for the specification structure and using the data in an `ApplicationClient`
+`Beaker` provides a reference implementation for creating an application.json from a smart contract.
+
+## Security Considerations
+All ARCs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. ARC submissions missing the "Security Considerations" section will be rejected. An ARC cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
+
+## 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-0033.md

@@ -0,0 +1,104 @@
+---
+arc: 33
+title: xGov Pilot - Becoming an xGov
+description: Explanation on how to become Expert Governors.
+author: Stéphane Barroso (@SudoWeezy), Adriana Belotti, Massimo Morini, Michel Treccani, John Woods, Shai Halevi
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/
+status: Deprecated
+type: Meta
+created: 2022-11-22
+---
+
+## Abstract
+This ARC proposes a standard for achieving xGov status in the Algorand governance process. xGov status grants the right to vote on [ARC-34](./arc-0034.md) proposals raised by the community, specifically spending a previously specified amount of Algo in a given Term on particular initiatives.
+
+
+## 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>.
+
+<table>
+<thead>
+  <tr>
+    <th colspan="2">Algorand xGovernor Summary</th>
+  </tr>
+</thead>
+<tbody>
+  <tr>
+    <td>Enrolment</td>
+    <td colspan="2">At the start of each governance period</td>
+  </tr>
+  <tr>
+    <td>How to <br>become eligible</td>
+    <td>Having completed participation in the previous governance period through official or approved decentralized finance governance.</td>
+  </tr>  <tr>
+    <td>Requisite</td>
+    <td colspan="2">Commit of governance reward for one year</td>
+  </tr>
+  <tr>
+    <td>Duration</td>
+    <td colspan="2">1 Year</td>
+  </tr>
+  <tr>
+    <td>Voting Power</td>
+    <td colspan="2">1 Algo committed = 1 Vote, as per REWARDS DEPOSIT</td>
+  </tr>
+  <tr>
+    <td>Duty</td>
+    <td colspan="2">Spend all available votes each time a voting period occurs. (In case there is no proposal that aligns with an xGov's preference, a mock proposal can be used as an alternative.)</td>
+  </tr>
+  <tr>
+    <td rowspan="1">Disqualification</td>
+    <td colspan="2">Forfeit rewards pledged</td>
+  </tr>
+</tbody>
+</table>
+
+### What is an xGov?
+xGovs, or Expert Governors, are a **self-selected** group of decentralized decision makers who demonstrate an enduring commitment to the Algorand community, possess a deep understanding of the blockchain’s inner workings and realities of the Algorand community, and whose interests are aligned with the good of the Algorand blockchain. These individuals have the ability to participate in the designation **and** approval of proposals, and play an instrumental role in shaping the future of the Algorand ecosystem.
+
+### Requirement to become an xGov
+To become an xGov, or Expert Governor, an account:
+- **MUST** first be deemed eligible by having fully participated in the previous governance period, either through official or approved decentralized finance governance.
+- At the start of each governance period, eligible participants will have the option to enrol in the xGov program
+- To gain voting power as an xGov, the eligible **governor rewards for the period of the enrolment** **MUST** be committed to the xGov Term Pool and locked for a period of 12 months.
+> Only the GP rewards are deposited to the xGov Term Pool. The principal algo committed remains in the gov wallet (or DeFi protocol) and can be used in subsequent Governance Periods.
+
+Rewards deposited to the xGov Term Pool will be call **REWARDS DEPOSIT**.
+
+### Voting Power
+Voting power in the xGov process is determined by the amount of Algo an eligible participant commits. Voting power is 1 Algo = 1 Vote, as per REWARDS DEPOSIT, and it renews at the start of every quarter - provided the xGov remain eligible.
+This ensures that the weight of each vote is directly proportional to the level of investment and commitment to the Algorand ecosystem.
+
+### Duty of an xGov
+As an xGov, you **MUST** actively participate in the governance process by using all available votes amongst proposals each time a voting period occurs. If you don't do it, you will be disqualified.
+> eg. For 100 Algo as per REWARDS DEPOSIT, 100 votes available, they can be spent like this:
+> - 50 on proposal A
+> - 20 on proposal B
+> - 30 on proposal C
+> - 0 on every other proposal
+
+> In case no proposal aligns with an xGov's preference, a mock proposal can be used as an alternative.
+
+### Disqualification
+As an xGov, it is important to understand the importance of your role in the governance process and the responsibilities that come with it. Failure to do so will result in disqualification. The consequences of disqualification are significant, as the xGov will lose the rewards that were committed when they entered the xGov process. It is important to take your role as an xGov seriously and fulfill your responsibilities to ensure the success of the governance process.
+
+> The rewards will remain in the xGov reward pools & will be distributed among remaining xGovs
+
+## Rationale
+This proposal provides a clear and simple method for participation in xGov process, while also providing incentives for long-term commitment to the network. Separate pools for xGov and Gov allow for a more diverse range of participation, with the xGov pool providing an additional incentive for longer-term commitment. The requirement to spend 100% of your vote on proposals will ensure that participants are actively engaged in the decision-making process.
+
+After weeks of engagement with the community, it has been decided:
+- That the xGov process will not utilize token or NFT.
+- There will be no minimum or maximum amount of Algo required to participate in the xGov process
+- In the future, the possibility of node operation being considered as a form of participation eligibility is being explored
+This approach aims to make the xGov process accessible and inclusive for all members of the community.
+
+We encourage the community to continue to provide input on this topic through the submission of questions and ideas in this ARC document.
+
+> **Important**:  The xGov program is still a work in progress, and changes are expected to happen over the next few years with community input and design consultation. Criteria to ENTER the program will only be applied forward, which means Term Pools already in place will not be affected by new any NEW ENTRY criteria. However, other ELIGIBILITY criteria could be added and be applied to all pools. For example, if the majority of the community deems necessary to have more than 1 voting session per quarter, this type of change could be applied to all Term pools, given ample notice and time for preparation.
+
+## Security Considerations
+No funds need to leave the user's wallet in order to become an xGov.
+
+## Copyright
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.