partner-chain-gov

deposit_to_reserve

Deposit Additional Tokens to Existing Reserve ============================================= Adds more reward tokens to an operational reserve system for future distribution. This enables ongoing funding of validator rewards and token distribution mechanisms. Transaction Flow: 1. References multiple script versions for validation and authorization 2. Mints governance token to prove authorization for reserve operations 3. Consumes existing reserve UTxO containing current token balance 4. Creates updated reserve UTxO with additional deposited tokens 5. Returns governance token and change to the payment address Security Requirements: - Must have valid governance authorization for reserve modifications - Reserve auth token must be present in the existing reserve UTxO - Deposit amount must be available in the source input - Governance token minting proves authorization for this operation Economic Impact: - Increases total token pool available for validator rewards - Extends the operational lifetime of the reserve system - Enables flexible reserve funding based on Partner Chain needs - Maintains reserve settings while increasing token balance Parameters: - deposit_amount: Amount of reward tokens to add to the reserve - existing_reserve_utxo: Reference to the current reserve UTxO Post-Conditions: - Reserve contains additional tokens available for distribution - Reserve configuration and vesting parameters remain unchanged - Enhanced funding supports extended validator reward operations

release_from_reserve

Release Tokens from Reserve According to Vesting Schedule ======================================================== Releases reward tokens from the reserve to illiquid circulation supply based on mathematical vesting function validation. This implements controlled token distribution. Transaction Flow: 1. References multiple validator scripts for comprehensive validation 2. Consumes both reserve UTxO and ICS (Illiquid Circulation Supply) UTxO 3. Mints V-function tokens equal to cumulative transfers for mathematical validation 4. Creates updated reserve UTxO with reduced token balance 5. Creates updated ICS UTxO with transferred tokens and ReserveTransfer datum 6. Uses validity interval for temporal validation of release timing Security Requirements: - Reserve auth token must authorize the token release operation - ICS authority token must control the receiving illiquid supply system - V-function validation must prove the release follows vesting mathematics - Validity interval ensures time-based release constraints are respected Vesting Mechanism: - V-function tokens validate cumulative total against mathematical curve - Release amount must comply with predefined vesting schedule - Temporal validation ensures releases happen at appropriate intervals - Mathematical proof prevents premature or excessive token releases Economic Controls: - Implements controlled token inflation through vesting - Prevents arbitrary token releases outside vesting parameters - Maintains economic security through mathematical validation - Supports sustainable validator reward distribution Parameters: - release_amount: Amount of tokens to release from reserve - existing_reserve_utxo: Current reserve UTxO containing tokens - existing_ics_utxo: Current ICS UTxO to receive tokens - v_function_reference_utxo: UTxO containing vesting function script - v_function_policy_hash: Policy hash for V-function token validation - cumulative_total_transfer: Total amount transferred including this release - latest_slot: Current slot for validity start interval validation Post-Conditions: - Tokens are released to illiquid circulation supply according to vesting - Reserve balance is reduced by the exact release amount - Mathematical proof validates compliance with vesting function - Release timing is validated against blockchain slot constraints

update_d_parameter

Update Existing D-Parameter Values ================================= Modifies the existing D-parameter configuration to change candidate limits. This enables governance to dynamically adjust validator candidate constraints. Transaction Flow: 1. References governance UTxO for authorization validation (read-only) 2. Consumes the existing D-parameter UTxO containing current limits 3. Creates new D-parameter UTxO with updated candidate limit values 4. Preserves the D-parameter token (no token burning or minting required) 5. Returns change to the payment address Security Requirements: - Must have valid governance authorization for parameter modifications - Existing D-parameter UTxO must be properly identified and consumed - New parameter values must be within acceptable operational ranges - Atomic update ensures no intermediate invalid parameter states System Impact: - Immediately affects candidate registration limits across the Partner Chain - May require existing candidates to be reviewed against new limits - Governance decision reflected in updated on-chain parameter storage Parameters: - num_permissioned_candidates: New maximum for pre-approved candidates - num_registered_candidates: New maximum for stake pool registered candidates - existing_utxo: Reference to the current D-parameter UTxO to update Post-Conditions: - D-parameter system operates with the new candidate limits - Previous parameter values are permanently replaced - All future candidate operations respect the updated limits

update_key_value

Update Existing Key-Value Pair in Governed Map ============================================= Modifies an existing entry in the governed map with new value data. Ensures atomic updates while maintaining governance oversight and token consistency. Transaction Flow: 1. References governance UTxO for authorization validation 2. Consumes the existing UTxO containing the current key-value pair 3. Creates new UTxO with the same key but updated value 4. Preserves exactly one governed map token for the entry 5. Handles token consolidation if multiple UTxOs exist for the same key Security Requirements: - Must have valid governance authorization - Existing UTxO must contain the specified key - Token count must remain consistent (no inflation) - Atomic update ensures no intermediate invalid states Parameters: - key: The existing key to update - new_value: The new value to associate with the key - existing_utxo: Reference to current UTxO containing the key-value pair Post-Conditions: - Key now maps to the new value - Previous value is permanently replaced - Map token count remains unchanged

insert_permissioned_candidates

Insert Initial Permissioned Candidates List ========================================== Establishes the first permissioned candidates list for the Partner Chain. This creates governance-approved validators that don't require stake pool ownership. Transaction Flow: 1. References governance UTxO for authorization validation (read-only) 2. Mints a permissioned candidates token to authenticate the candidate list 3. Creates permissioned candidates UTxO containing the approved validator list 4. Stores candidate data including consensus keys for each validator 5. Returns change to the payment address Security Requirements: - Must have valid governance authorization for candidate list creation - Permissioned candidates token provides unique identification for the list - All candidate data must be properly formatted for consensus participation - Governance oversight ensures only approved validators are included Candidate Management: - Pre-approved validators bypass stake pool ownership requirements - Each candidate includes multiple consensus keys (Aura, Grandpa, sidechain) - Governance has full control over permissioned candidate selection - List can be updated through subsequent governance transactions System Integration: - Permissioned candidates participate alongside registered candidates - Subject to D-parameter limits for total candidate count - Enables hybrid validator selection (governance + stake-based) Parameters: - candidates: List of pre-approved validator candidates with consensus keys Post-Conditions: - Permissioned candidates are eligible for validator selection - Governance maintains control over the approved candidate list - System supports both permissioned and registered validation models

insert_d_parameter

Insert D-Parameter Values for Candidate Limits ============================================= Establishes the initial D-parameter configuration that controls the maximum number of permissioned and registered candidates allowed in the Partner Chain system. Transaction Flow: 1. References governance UTxO for authorization validation (read-only) 2. Mints a D-parameter token to authenticate and identify the parameter entry 3. Mints additional multi-signature policy token for governance operations 4. Creates D-parameter UTxO containing the candidate limit configuration 5. Returns change including the minted multi-sig token to payment address Security Requirements: - Must have valid governance authorization for parameter creation - D-parameter token provides unique identification for the parameter set - Multi-signature token enables future governance operations - Parameter values must be within acceptable ranges for system operation System Impact: - Defines maximum validator candidate limits for the Partner Chain - Establishes governance control over candidate registration processes - Enables future updates to candidate limits through governance decisions Parameters: - num_permissioned_candidates: Maximum number of pre-approved candidates allowed - num_registered_candidates: Maximum number of stake pool registered candidates allowed Post-Conditions: - D-parameter system is operational with defined candidate limits - Governance can modify these parameters through update transactions - Candidate registration processes respect these defined limits

update_permissioned_candidates

Update Existing Permissioned Candidates List =========================================== Modifies the existing permissioned candidates list with new validator selections. This enables governance to dynamically manage pre-approved validator candidates. Transaction Flow: 1. References governance UTxO for authorization validation (read-only) 2. Consumes the existing permissioned candidates UTxO containing current list 3. Creates new permissioned candidates UTxO with updated validator list 4. Preserves the permissioned candidates token (no token operations required) 5. Returns change to the payment address Security Requirements: - Must have valid governance authorization for candidate list modifications - Existing candidates UTxO must be properly identified and consumed - New candidate data must be properly formatted for consensus participation - Atomic update ensures no intermediate invalid candidate states Governance Control: - Enables adding new pre-approved validators to the system - Allows removal of validators who should no longer participate - Supports updating consensus keys for existing candidates - Maintains governance oversight over validator selection process System Impact: - Immediately affects validator eligibility for Partner Chain consensus - Updated candidates become available for validator selection - Removed candidates are no longer eligible for validation - Changes are permanent until subsequent governance updates Parameters: - candidates: Updated list of governance-approved validator candidates - existing_utxo: Reference to the current permissioned candidates UTxO Post-Conditions: - Permissioned candidates list reflects the new governance decisions - Previous candidate list is permanently replaced - All consensus systems respect the updated candidate eligibility

register_candidate

Register New Validator Candidate =============================== Enables stake pool operators to register as validator candidates for the Partner Chain. Registration requires cryptographic proof of stake pool ownership and control. Transaction Flow: 1. Consumes registration UTxO as proof of registration rights/payment 2. Optionally consumes existing registration UTxOs for the same candidate (updates) 3. Creates new candidate UTxO with complete registration data and cryptographic proofs 4. Validates stake pool ownership through signature verification 5. Stores all consensus keys required for validator participation Security Requirements: - Must provide valid stake pool ownership signature - Partner chain signature must be verifiable with provided public key - Registration UTxO proves payment/authorization for registration - All consensus keys must be properly formatted for their respective protocols Cryptographic Validations: - Stake ownership signature validates control of existing Cardano stake pool - Partner chain signature proves control of dedicated validator keys - Multiple consensus keys support different aspects of validation (Aura, Grandpa, etc.) Parameters: - stake_ownership_pub_key: Public key of the Cardano stake pool - stake_ownership_signature: Signature proving stake pool control - partner_chain_pub_key: Dedicated public key for Partner Chain operations - partner_chain_signature: Signature with partner chain key - registration_utxo: UTxO used as registration proof/payment - own_pkh: Payment key hash identifying the registrant - candidate_keys: Additional consensus keys for validation protocols - existing_registration_utxos: Any existing registrations to update Post-Conditions: - Candidate is registered and eligible for validator selection - All cryptographic proofs are stored for verification - Previous registrations for this candidate are replaced

deregister_candidate

Deregister Existing Validator Candidate ====================================== Removes a validator candidate from the Partner Chain registration system. This allows candidates to voluntarily exit or be removed from validator eligibility. Transaction Flow: 1. Consumes all existing registration UTxOs associated with the candidate 2. Validates stake pool ownership to ensure only authorized deregistration 3. Burns registered candidate tokens (effectively removing candidate status) 4. Returns all ADA value to the candidate address 5. Permanently removes candidate from validator selection eligibility Security Requirements: - Must be initiated by the candidate address (self-deregistration) - Stake pool public key must match existing registration records - All registration UTxOs for the candidate must be properly consumed - Candidate key signature required for transaction authorization Validation Process: - Identifies all registration UTxOs associated with the stake pool - Ensures complete removal of candidate registration data - Prevents partial deregistration that could leave invalid states Parameters: - stake_ownership_pub_key: Stake pool public key to identify the candidate - existing_registration_utxos: List of all registration UTxOs to remove Post-Conditions: - Candidate is no longer eligible for validator selection - All registration tokens are burned and removed from circulation - Registration data is permanently deleted from the Partner Chain - ADA value is returned to the candidate for potential re-registration

update_reserve_settings

Update Reserve Configuration and Vesting Parameters ================================================= Modifies the operational parameters of an existing reserve system. This enables governance to adjust vesting functions and reward distribution logic. Transaction Flow: 1. References multiple validator scripts for comprehensive authorization 2. Mints governance token to prove authorization for configuration changes 3. Consumes existing reserve UTxO containing current settings 4. Creates updated reserve UTxO with new vesting function configuration 5. Preserves all tokens and auth tokens while updating settings 6. Returns governance token and change to payment address Security Requirements: - Must have valid governance authorization for reserve modifications - Reserve auth token must be present to authorize configuration changes - New vesting function hash must be cryptographically secure - All existing tokens and balances must be preserved during update Configuration Management: - Updates the mathematical vesting function controlling token releases - Enables governance to respond to changing economic conditions - Allows optimization of reward distribution mechanisms - Maintains operational continuity while updating parameters Economic Impact: - Changes future token release patterns according to new vesting function - Does not affect past releases or current token balances - Enables adaptive economic policy for validator rewards - Supports long-term sustainability of reward distribution Parameters: - new_total_accrued_function_script_hash: Hash of the new V-function for vesting - existing_reserve_utxo: Reference to the current reserve UTxO to update Post-Conditions: - Reserve operates with updated vesting function parameters - All existing tokens and auth tokens remain unchanged - Future token releases follow the new vesting mathematics - Governance retains control over subsequent configuration changes

init_governance

Initialize Partner Chain Governance System ======================================== Bootstrap transaction that establishes the foundational governance infrastructure for a new Partner Chain. This is typically the first governance transaction executed. Transaction Flow: 1. Consumes a genesis UTxO to establish unique Partner Chain identity 2. Mints the initial version oracle token using governance script authorization 3. Creates the first governance UTxO containing the governance authority parameters 4. Stores the multi-signature policy script reference for future governance operations Security Requirements: - Must consume a specific genesis UTxO to prevent duplicate chains - Requires multi-signature authorization through governance script - Creates immutable initial governance state with upgrade capabilities Post-Conditions: - Governance system is operational and ready for subsequent operations - Version oracle validator contains the governance authority token - Multi-signature policy is established for future governance decisions

create_reserve

Create Token Reserve for Controlled Distribution ============================================== Establishes a new token reserve system for managing reward distribution and vesting. Creates the complete infrastructure for controlled token release mechanisms. Transaction Flow: 1. References multiple script versions for validation and minting authorization 2. Mints essential tokens: Reserve Auth, Governance, and ICS Authority tokens 3. Creates primary reserve UTxO with initial token deposits and configuration 4. Creates multiple ICS (Illiquid Circulation Supply) UTxOs for token management 5. Establishes vesting function and reward distribution parameters Security Requirements: - Must have valid governance authorization for reserve creation - Reserve auth token provides exclusive control over reserve operations - ICS authority tokens control illiquid supply management - Vesting function hash must be cryptographically secure Token Management: - Deposits specified reward tokens into the reserve for distribution - Creates multiple ICS UTxOs for granular token release control - Establishes mathematical vesting function for time-based releases Parameters: - reward_tokens_amount: Initial amount of reward tokens to deposit - total_accrued_function_script_hash: Hash of the vesting calculation function - ics_initial_utxos_amount: Number of ICS UTxOs to create for management Post-Conditions: - Reserve is operational and ready for token distribution - Vesting mechanism is configured and functional - ICS system is initialized for controlled token releases - Governance has authority over reserve configuration changes

insert_key_value

Insert New Key-Value Pair into Governed Map ========================================== Creates a new entry in the decentralized governed map storage system. All map operations require governance authorization to ensure controlled access. Transaction Flow: 1. References governance UTxO to verify current authority (read-only) 2. Mints a new governed map token to represent the storage entry 3. Creates UTxO at governed map validator containing the key-value data 4. Enforces uniqueness and governance oversight for all map entries Security Requirements: - Must have valid governance reference for authorization - Each entry requires a unique governed map token - Key-value pairs are immutably stored in UTxO datums Parameters: - key: The storage key (must be unique across the map) - value: The associated data value to store Post-Conditions: - New key-value pair is available for querying - Governed map token exists representing the entry - Entry can be updated or removed through subsequent transactions

remove_key_value

Remove Key-Value Pair from Governed Map ====================================== Permanently removes an existing entry from the governed map storage system. This operation requires governance authorization and properly handles token burning. Transaction Flow: 1. References governance UTxO for authorization validation (read-only) 2. Consumes the existing UTxO containing the key-value pair to be removed 3. Burns the governed map token associated with the removed entry 4. Returns the ADA value to the payment address Security Requirements: - Must have valid governance authorization for map modifications - Target UTxO must exist and contain a valid governed map token - Ensures complete removal of the key-value mapping Current Implementation Note: - Token burning is commented out due to tx3 version limitations - Creates a placeholder UTxO instead of true token burning - Future versions should implement proper token burning mechanism Parameters: - existing_utxo: Reference to the UTxO containing the key-value pair to remove Post-Conditions: - Key-value pair is no longer accessible in the governed map - Associated map token is effectively removed from circulation - ADA value is returned to the payment address

update_governance

Update Governance Authority and Transfer Control ============================================== Critical transaction that transfers governance control to new authority parameters. This enables governance evolution and multi-signature policy updates for Partner Chains. Transaction Flow: 1. Consumes the current governance UTxO containing existing authority tokens 2. Burns the old version oracle token (effectively ending previous governance) 3. Mints new version oracle token with updated governance policy parameters 4. Creates new governance UTxO with the updated authority configuration 5. Establishes the new multi-signature parameters for future operations Security Requirements: - Must be authorized by the current governance authority - Atomic transition ensures no governance power vacuum or overlap - New governance parameters must be cryptographically valid - Multi-signature policy must be properly formatted and secure Critical Security Implications: - This transaction effectively transfers complete control of the Partner Chain - New governance authority gains control over all governed operations - Previous governance authority is permanently revoked after execution - All future governance decisions require the new multi-signature policy Governance Continuity: - Ensures seamless transition between governance authorities - Maintains governance token uniqueness (only one valid at a time) - Preserves governance UTxO reference for subsequent operations Parameters: - old_version_oracle_policy_hash: Hash of the current governance policy to revoke Post-Conditions: - New governance authority has exclusive control over Partner Chain operations - Previous governance tokens are permanently burned and invalid - All governed systems (maps, parameters, candidates) respect new authority - Governance evolution mechanism remains available for future updates

handover_reserve

Handover Reserve Control to Illiquid Circulation Supply ====================================================== Transfers complete reserve control to the illiquid circulation supply system. This represents a permanent transition from controlled reserve to open circulation. Transaction Flow: 1. References multiple validator scripts for authorization and validation 2. Mints governance token to prove authorization for this critical operation 3. Consumes the existing reserve UTxO containing all reserve assets 4. Burns the reserve auth token, permanently disabling reserve operations 5. Transfers all reserve tokens to illiquid circulation supply validator 6. Creates ICS output with appropriate datum based on token content Security Requirements: - Must have valid governance authorization for this irreversible operation - Reserve auth token burning ensures no future reserve operations are possible - All reserve tokens must be completely transferred to ICS system - Governance token validates the authority for this critical transition Permanent Transition: - This operation is irreversible once executed successfully - Reserve system becomes permanently non-operational after handover - All token management transitions to illiquid circulation supply - No future reserve deposits, releases, or updates are possible Economic Impact: - Completes the transition from controlled reserve to open circulation - All remaining tokens become available through ICS mechanisms - Eliminates central reserve control over token distribution - Represents final stage of token distribution lifecycle Token Management: - Creates ReserveTransfer datum if tokens are present in output - Creates unit datum for minimal ADA-only outputs - Ensures proper ICS integration for continued token management Parameters: - existing_reserve_utxo: Reference to the reserve UTxO to be handed over Post-Conditions: - Reserve system is permanently disabled and non-operational - All reserve tokens are under illiquid circulation supply control - Reserve auth tokens are burned and cannot be recreated - Token distribution continues through ICS mechanisms only