Skip to content

Generated schema for tokenization/approval_criteria.proto: 3 messages in the x/tokenization module.

Proto package tokenization, part of the x/tokenization module. It declares 3 messages. Read the raw source.

Messages

ApprovalCriteria

ApprovalCriteria defines the criteria for approving transfers.

All criteria must be satisfied for the approval to be considered valid.

Field#TypeRuleDescription
merkleChallenges1MerkleChallengerepeatedMerkle challenges that must be satisfied for approval. The initiator must provide valid Merkle proofs that satisfy all specified challenges. Each challenge requires a proof that leads to a specific root hash.
predeterminedBalances2PredeterminedBalancessingularPredetermined balances that must be used for each approval. Defines the exact token amounts and IDs that can be transferred when using this approval.
approvalAmounts3ApprovalAmountssingularThreshold limit of amounts that can be transferred using this approval. Tracks cumulative amounts transferred and enforces maximum limits per approval.
maxNumTransfers4MaxNumTransferssingularMaximum number of transfers that can be processed using this approval. Tracks the count of transfers and enforces the limit to prevent exceeding the allowed number of uses.
coinTransfers5CoinTransferrepeatedThe sdk.Coins that need to be transferred for approval. Defines required coin transfers (e.g., fees, royalties) that must be executed alongside the token transfer for the approval to be valid.
requireToEqualsInitiatedBy6boolsingularRequire the "to" address to be equal to the "initiated by" address for approval. If true, only transfers where the recipient matches the initiator are allowed.
requireFromEqualsInitiatedBy7boolsingularRequire the "from" address to be equal to the "initiated by" address for approval. If true, only transfers where the sender matches the initiator are allowed.
requireToDoesNotEqualInitiatedBy8boolsingularRequire the "to" address to not be equal to the "initiated by" address for approval. If true, transfers where the recipient equals the initiator are forbidden.
requireFromDoesNotEqualInitiatedBy9boolsingularRequire the "from" address to not be equal to the "initiated by" address for approval. If true, transfers where the sender equals the initiator are forbidden.
overridesFromOutgoingApprovals10boolsingularOverrides the user's outgoing approvals for approval. If true, this collection-level approval takes precedence over any outgoing approvals defined by the sender, allowing the collection to control outgoing transfer behavior.
overridesToIncomingApprovals11boolsingularOverrides the user's incoming approvals for approval. If true, this collection-level approval takes precedence over any incoming approvals defined by the recipient, allowing the collection to control incoming transfer behavior.
autoDeletionOptions12AutoDeletionOptionssingularAuto-deletion options for this approval. Defines conditions under which this approval should be automatically deleted (e.g., after a certain number of uses or time period).
mustOwnTokens14MustOwnTokensrepeatedMust own tokens for approval. Defines token ownership requirements that must be satisfied for the approval to be valid. The initiator must own the specified tokens at the specified ownership times.
dynamicStoreChallenges15DynamicStoreChallengerepeatedDynamic store challenges that the initiator must pass for approval. The initiator must provide valid proofs that satisfy all specified dynamic store challenges (e.g., key-value store lookups).
ethSignatureChallenges16ETHSignatureChallengerepeatedETH signature challenges that the initiator must pass for approval. The initiator must provide valid Ethereum signatures for all specified challenges. Each signature can only be used once.
senderChecks17AddressCheckssingularAddress checks for the sender of the transfer. Validates that the sender address meets the specified criteria (e.g., whitelist, blacklist, protocol address requirements).
recipientChecks18AddressCheckssingularAddress checks for the recipient of the transfer. Validates that the recipient address meets the specified criteria (e.g., whitelist, blacklist, protocol address requirements).
initiatorChecks19AddressCheckssingularAddress checks for the initiator of the transfer. Validates that the initiator address meets the specified criteria (e.g., whitelist, blacklist, protocol address requirements).
altTimeChecks20AltTimeCheckssingularAlternative time-based checks for approval denial (offline hours/days). Defines time periods during which this approval should be denied, such as specific hours of the day or days of the week.
mustPrioritize21boolsingularIf true, this approval must be explicitly prioritized in PrioritizedApprovals to be used. This allows fine-grained control over which approvals are applied when multiple approvals could match.
votingChallenges22VotingChallengerepeatedVoting challenges that must be satisfied for approval. The initiator must provide valid votes that meet the quorum threshold for all specified challenges.
allowBackedMinting23boolsingularIf true, this collection approval allows backed minting operations (CosmosCoinBackedPath). When false, this approval cannot be used for transfers involving backed minting addresses. This prevents accidental allowances when toListIds is "All".
allowSpecialWrapping24boolsingularIf true, this collection approval allows special wrapping operations (CosmosCoinWrapperPath). When false, this approval cannot be used for transfers involving wrapping addresses. This prevents accidental allowances when toListIds is "All".
evmQueryChallenges25EVMQueryChallengerepeatedEVM query challenges that must pass for approval. Read-only contract queries that verify external EVM state (e.g., token ownership in another contract).
userApprovalSettings26UserApprovalSettingssingularIssuer-imposed constraints on user-level coin transfers. Propagated to user-level approvals during greedy transfer matching (same pattern as userRoyalties). Only applicable on collection-level approvals. If conflicting settings across multiple matched approvals, the transfer is rejected (like royalties).

IncomingApprovalCriteria

IncomingApprovalCriteria defines the criteria for approving incoming transfers.

This is used for user-level incoming approvals and only includes fields relevant to incoming transfers.

All criteria must be satisfied for the approval to be considered valid.

Field#TypeRuleDescription
merkleChallenges1MerkleChallengerepeatedMerkle challenges that must be satisfied for approval. The initiator must provide valid Merkle proofs that satisfy all specified challenges. Each challenge requires a proof that leads to a specific root hash.
predeterminedBalances2PredeterminedBalancessingularPredetermined balances that must be used for each approval. Defines the exact token amounts and IDs that can be transferred when using this approval.
approvalAmounts3ApprovalAmountssingularThreshold limit of amounts that can be transferred using this approval. Tracks cumulative amounts transferred and enforces maximum limits per approval.
maxNumTransfers4MaxNumTransferssingularMaximum number of transfers that can be processed using this approval. Tracks the count of transfers and enforces the limit to prevent exceeding the allowed number of uses.
coinTransfers5CoinTransferrepeatedThe sdk.Coins that need to be transferred for approval. Defines required coin transfers (e.g., fees, royalties) that must be executed alongside the token transfer for the approval to be valid.
requireFromEqualsInitiatedBy6boolsingularRequire the "from" address to be equal to the "initiated by" address for approval. If true, only transfers where the sender matches the initiator are allowed.
requireFromDoesNotEqualInitiatedBy7boolsingularRequire the "from" address to not be equal to the "initiated by" address for approval. If true, transfers where the sender equals the initiator are forbidden.
autoDeletionOptions8AutoDeletionOptionssingularAuto-deletion options for this approval. Defines conditions under which this approval should be automatically deleted (e.g., after a certain number of uses or time period).
mustOwnTokens9MustOwnTokensrepeatedMust own tokens for approval. Defines token ownership requirements that must be satisfied for the approval to be valid. The initiator must own the specified tokens at the specified ownership times.
dynamicStoreChallenges10DynamicStoreChallengerepeatedDynamic store challenges that the initiator must pass for approval. The initiator must provide valid proofs that satisfy all specified dynamic store challenges (e.g., key-value store lookups).
ethSignatureChallenges11ETHSignatureChallengerepeatedETH signature challenges that the initiator must pass for approval. The initiator must provide valid Ethereum signatures for all specified challenges. Each signature can only be used once.
senderChecks12AddressCheckssingularAddress checks for the sender of the transfer. Validates that the sender address meets the specified criteria (e.g., whitelist, blacklist, protocol address requirements). Note: No recipient checks are included for incoming approvals since the recipient is the user themselves.
initiatorChecks13AddressCheckssingularAddress checks for the initiator of the transfer. Validates that the initiator address meets the specified criteria (e.g., whitelist, blacklist, protocol address requirements).
altTimeChecks14AltTimeCheckssingularAlternative time-based checks for approval denial (offline hours/days). Defines time periods during which this approval should be denied, such as specific hours of the day or days of the week.
mustPrioritize15boolsingularIf true, this approval must be explicitly prioritized in PrioritizedApprovals to be used. This allows fine-grained control over which approvals are applied when multiple approvals could match.
votingChallenges16VotingChallengerepeatedVoting challenges that must be satisfied for approval. The initiator must provide valid votes that meet the quorum threshold for all specified challenges.
evmQueryChallenges17EVMQueryChallengerepeatedEVM query challenges that must pass for approval. Read-only contract queries that verify external EVM state (e.g., token ownership in another contract).

OutgoingApprovalCriteria

OutgoingApprovalCriteria defines the criteria for approving outgoing transfers.

This is used for user-level outgoing approvals and only includes fields relevant to outgoing transfers.

All criteria must be satisfied for the approval to be considered valid.

Field#TypeRuleDescription
merkleChallenges1MerkleChallengerepeatedMerkle challenges that must be satisfied for approval. The initiator must provide valid Merkle proofs that satisfy all specified challenges. Each challenge requires a proof that leads to a specific root hash.
predeterminedBalances2PredeterminedBalancessingularPredetermined balances that must be used for each approval. Defines the exact token amounts and IDs that can be transferred when using this approval.
approvalAmounts3ApprovalAmountssingularThreshold limit of amounts that can be transferred using this approval. Tracks cumulative amounts transferred and enforces maximum limits per approval.
maxNumTransfers4MaxNumTransferssingularMaximum number of transfers that can be processed using this approval. Tracks the count of transfers and enforces the limit to prevent exceeding the allowed number of uses.
coinTransfers5CoinTransferrepeatedThe sdk.Coins that need to be transferred for approval. Defines required coin transfers (e.g., fees, royalties) that must be executed alongside the token transfer for the approval to be valid.
requireToEqualsInitiatedBy6boolsingularRequire the "to" address to be equal to the "initiated by" address for approval. If true, only transfers where the recipient matches the initiator are allowed.
requireToDoesNotEqualInitiatedBy7boolsingularRequire the "to" address to not be equal to the "initiated by" address for approval. If true, transfers where the recipient equals the initiator are forbidden.
autoDeletionOptions8AutoDeletionOptionssingularAuto-deletion options for this approval. Defines conditions under which this approval should be automatically deleted (e.g., after a certain number of uses or time period).
mustOwnTokens9MustOwnTokensrepeatedMust own tokens for approval. Defines token ownership requirements that must be satisfied for the approval to be valid. The initiator must own the specified tokens at the specified ownership times.
dynamicStoreChallenges10DynamicStoreChallengerepeatedDynamic store challenges that the initiator must pass for approval. The initiator must provide valid proofs that satisfy all specified dynamic store challenges (e.g., key-value store lookups).
ethSignatureChallenges11ETHSignatureChallengerepeatedETH signature challenges that the initiator must pass for approval. The initiator must provide valid Ethereum signatures for all specified challenges. Each signature can only be used once.
recipientChecks12AddressCheckssingularAddress checks for the recipient of the transfer. Validates that the recipient address meets the specified criteria (e.g., whitelist, blacklist, protocol address requirements). Note: No sender checks are included for outgoing approvals since the sender is the user themselves.
initiatorChecks13AddressCheckssingularAddress checks for the initiator of the transfer. Validates that the initiator address meets the specified criteria (e.g., whitelist, blacklist, protocol address requirements).
altTimeChecks14AltTimeCheckssingularAlternative time-based checks for approval denial (offline hours/days). Defines time periods during which this approval should be denied, such as specific hours of the day or days of the week.
mustPrioritize15boolsingularIf true, this approval must be explicitly prioritized in PrioritizedApprovals to be used. This allows fine-grained control over which approvals are applied when multiple approvals could match.
votingChallenges16VotingChallengerepeatedVoting challenges that must be satisfied for approval. The initiator must provide valid votes that meet the quorum threshold for all specified challenges.
evmQueryChallenges17EVMQueryChallengerepeatedEVM query challenges that must pass for approval. Read-only contract queries that verify external EVM state (e.g., token ownership in another contract).

Edit this page on GitHub