{"docsConfig":{"theme":"mint","$schema":"https://mintlify.com/docs.json","name":"Cosmos Docs","description":"Developer documentation for the Cosmos stack. Build secure, reliable, and high-performance blockchains.","colors":{"primary":"#000000","light":"#cccccc","dark":"#0E0E0E"},"logo":{"light":"https://mintcdn.com/cosmos-docs/QQRcm34voxlHZJJD/assets/brand/cosmos-wordmark-dark.svg?fit=max\u0026auto=format\u0026n=QQRcm34voxlHZJJD\u0026q=85\u0026s=cd248dfba0e2e05e30786f2bb3f64fe9","dark":"https://mintcdn.com/cosmos-docs/QQRcm34voxlHZJJD/assets/brand/cosmos-wordmark.svg?fit=max\u0026auto=format\u0026n=QQRcm34voxlHZJJD\u0026q=85\u0026s=bec1c5143607bae16714a74214e59936"},"favicon":{"light":"https://mintcdn.com/cosmos-docs/QQRcm34voxlHZJJD/assets/brand/cosmos.svg?fit=max\u0026auto=format\u0026n=QQRcm34voxlHZJJD\u0026q=85\u0026s=894cf1378c2e13292b5729f71ffcdfa3","dark":"https://mintcdn.com/cosmos-docs/QQRcm34voxlHZJJD/assets/brand/cosmos-dark.svg?fit=max\u0026auto=format\u0026n=QQRcm34voxlHZJJD\u0026q=85\u0026s=84a9ac891f12ecddec2f5bbc50774eb1"},"appearance":{"default":"system","strict":false},"background":{"color":{"light":"#F1F1F1","dark":"#000000"}},"navbar":{"links":[{"href":"/sdk/latest/learn","label":"Cosmos SDK"},{"href":"/evm/latest/documentation/overview","label":"Cosmos EVM"},{"href":"https://ibcprotocol.dev/docs","label":"IBC"},{"href":"/cometbft/latest/docs/README","label":"CometBFT"}]},"footer":{"socials":{"twitter":"https://twitter.com/cosmos","github":"https://github.com/cosmos","discord":"https://discord.gg/interchain","website":"https://cosmos.network"},"links":[{"header":"Technology","items":[{"label":"Cosmos SDK","href":"/sdk/latest/learn"},{"label":"Cosmos EVM","href":"/evm"},{"label":"IBC","href":"https://ibcprotocol.dev/docs"},{"label":"CometBFT","href":"/cometbft"},{"label":"Cosmos Github","href":"https://github.com/cosmos"},{"label":"Cosmos HackerOne","href":"https://hackerone.com/cosmos"},{"label":"Skip Go","href":"/skip-go/general/getting-started"},{"label":"Cosmos Hub","href":"/hub/latest"}]},{"header":"Get In Touch","items":[{"label":"Developer Discord","href":"https://discord.gg/interchain"},{"label":"Community Telegram","href":"https://t.me/CosmosOG"},{"label":"Contact Us","href":"https://www.cosmoslabs.io/contact"},{"label":"Cosmos Website","href":"https://cosmos.network/"}]},{"header":"Legal","items":[{"label":"Privacy","href":"https://cosmos.network/privacy-policy"},{"label":"Trademark","href":"https://cosmos.network/trademark"},{"label":"Security Policy","href":"/sdk/latest/security/security-policy"},{"label":"Security Audits","href":"/sdk/latest/security/audits"},{"label":"Bug Bounty Program","href":"/sdk/latest/security/bug-bounty"}]}]},"search":{"prompt":"Search..."},"seo":{"metatags":{"description":"Developer documentation for the Cosmos stack. Build secure, reliable, and high-performance blockchains.","og:description":"Developer documentation for the Cosmos stack. Build secure, reliable, and high-performance blockchains.","twitter:description":"Developer documentation for the Cosmos stack. Build secure, reliable, and high-performance blockchains."}},"icons":{"library":"lucide"},"styling":{"codeblocks":{"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}},"latex":true},"integrations":{"gtm":{"tagId":"GTM-5XMZ695Z"}},"errors":{"404":{"redirect":false,"title":"Page not found","description":"The page you are looking for has either moved or doesn't exist anymore.\n\nPlease create an issue on the [Cosmos Docs GitHub repository](https://github.com/cosmos/docs/issues/new) to report the problem and it will be fixed as soon as possible."}},"contextual":{"options":["copy","view","chatgpt","claude","perplexity","mcp","cursor","vscode"],"display":"header"},"interaction":{"drilldown":false},"navigation":{"pages":[]}},"deployment":{"deploymentMetadataValue":{"subdomain":"cosmos-docs","hasAudioNarration":false,"actualSubdomain":"cosmos-docs","customDomains":["docs.cosmos.network","cosmos.network"],"gitSource":{"type":"github","owner":"cosmos","repo":"docs","deployBranch":"main","contentDirectory":"","isPrivate":true,"mountPath":"","label":""},"chroma":{"liveDeploymentHistoryId":"6ae4d7a84af72709c3cb8597","collectionId":"935d4ee8-69ed-48ea-88d5-81d6941678d2","schemaVersion":"v3","latestBuiltDeploymentHistoryId":"6ae4d7a84af72709c3cb8597"},"feedback":{"thumbs":true,"edits":true,"issues":true},"entitlements":{"AI_CHAT":{"status":"ENABLED"},"REMOVE_BRANDING":{"status":"ENABLED"},"CONTEXTUAL_FEEDBACK":{"status":"DISABLED"},"CODE_SNIPPET_FEEDBACK":{"status":"DISABLED"},"WEB_MCP":{"status":"ENABLED"},"NARRATION":{"status":"ENABLED"}},"buildId":"6ae4d7a84af72709c3cb8597","clientVersion":"0.0.4054","searchFilterCounts":[{"language":"default","tag":"Cosmos SDK","count":629},{"language":"default","tag":"API Reference","count":401},{"language":"default","tag":"CometBFT","count":236},{"language":"default","tag":"REST (gRPC Gateway)","count":216},{"language":"default","tag":"Documentation","count":154},{"language":"default","tag":"RPC Methods","count":120},{"language":"default","tag":"Cosmos Hub","count":106},{"language":"default","tag":"Info","count":91},{"language":"default","tag":"Architecture Reference","count":70},{"language":"default","tag":"Learn","count":69}]},"assistantConfig":{},"basePath":"","hasChatPermissions":true,"hasWebMcpPermissions":true,"toggles":[{"name":"kill-isr","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"agent-mintlify-slack","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"agent-integrations-settings","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"automations-pr-grouping","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"custom-prefix","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"analytics-v7","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"user-flows-analytics","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"no-publish-flow","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"workos-onboarding","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"llms-txt-v2","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"snapshot-serving-live","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"stripTemperatureMiddleware","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"support-platform-pylon-zendesk","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"snapshot-serving","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"instant-rollback","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"granular-notifications-server","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"granular-notifications","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"automations-fable","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"fixed-ai-action-pricing","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"automation-resolve-merge-conflict","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"scoped-publishing","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"mintql","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"page-level-analytics","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"editor-version-history-v2","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"billing-page-v2","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"full-page-search","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"workspace-projects","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"assistant-v5","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"byok-sep-25","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"fork-pr-previews","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"revalidation-jwt","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"vite-origin","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"billing-updated-9-15","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"workos-sso-scim","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"hobby-abuse-scan","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"dashboard-inbox","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"workos-signup","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"turbopuffer-dual-write","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"workos-enabled","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"approve-review-flow","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"sso-setup-deadline-banner","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false},{"name":"rbac-expansion","enabled":true,"variant":{"name":"disabled","enabled":false,"feature_enabled":true},"impressionData":false}],"googleFontsInlined":false},"customCss":[{"filePath":"style.css","content":"/* cyrillic-ext */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 400;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh0NSDulI.woff2) format('woff2');\n unicode-range: U+0460-052F, U+1C80-1C8A, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;\n}\n/* cyrillic */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 400;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh2dSDulI.woff2) format('woff2');\n unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;\n}\n/* greek-ext */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 400;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh0dSDulI.woff2) format('woff2');\n unicode-range: U+1F00-1FFF;\n}\n/* greek */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 400;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh3tSDulI.woff2) format('woff2');\n unicode-range: U+0370-0377, U+037A-037F, U+0384-038A, U+038C, U+038E-03A1, U+03A3-03FF;\n}\n/* symbols2 */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 400;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bhZ_Wmh2uX.woff2) format('woff2');\n unicode-range: U+2000-2001, U+2004-2008, U+200A, U+23B8-23BD, U+2500-259F;\n}\n/* latin-ext */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 400;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh09SDulI.woff2) format('woff2');\n unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C4, U+2113, U+2C60-2C7F, U+A720-A7FF;\n}\n/* latin */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 400;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh3dSD.woff2) format('woff2');\n unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;\n}\n/* cyrillic-ext */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 500;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh0NSDulI.woff2) format('woff2');\n unicode-range: U+0460-052F, U+1C80-1C8A, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;\n}\n/* cyrillic */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 500;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh2dSDulI.woff2) format('woff2');\n unicode-range: U+0301, U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;\n}\n/* greek-ext */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 500;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh0dSDulI.woff2) format('woff2');\n unicode-range: U+1F00-1FFF;\n}\n/* greek */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 500;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh3tSDulI.woff2) format('woff2');\n unicode-range: U+0370-0377, U+037A-037F, U+0384-038A, U+038C, U+038E-03A1, U+03A3-03FF;\n}\n/* symbols2 */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 500;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bhZ_Wmh2uX.woff2) format('woff2');\n unicode-range: U+2000-2001, U+2004-2008, U+200A, U+23B8-23BD, U+2500-259F;\n}\n/* latin-ext */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 500;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh09SDulI.woff2) format('woff2');\n unicode-range: U+0100-02BA, U+02BD-02C5, U+02C7-02CC, U+02CE-02D7, U+02DD-02FF, U+0304, U+0308, U+0329, U+1D00-1DBF, U+1E00-1E9F, U+1EF2-1EFF, U+2020, U+20A0-20AB, U+20AD-20C4, U+2113, U+2C60-2C7F, U+A720-A7FF;\n}\n/* latin */\n@font-face {\n font-family: 'Fira Code';\n font-style: normal;\n font-weight: 500;\n font-display: swap;\n src: url(/_mintlify/assets/fonts/google/s/firacode/v27/uU9NCBsR6Z2vfE9aq3bh3dSD.woff2) format('woff2');\n unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;\n}\n:root{--background-light:255 255 255}.bg-primary\\/10{background-color:#40b3ff}.dark .bg-primary\\/10{background-color:#4251fa}.bg-primary\\/10 .text-primary,.bg-primary\\/10.text-primary{color:#fff}.dark\\:bg-primary-light\\/10:is(.dark *){background-color:#4251fa}@font-face{font-family:'The Future';src:url(/assets/fonts/the-future-regular.woff2) format('woff2');font-weight:400;font-style:normal;font-display:swap}@font-face{font-family:'The Future';src:url(/assets/fonts/the-future-medium.woff2) format('woff2');font-weight:500;font-style:normal;font-display:swap}@font-face{font-family:'The Future';src:url(/assets/fonts/the-future-bold.woff2) format('woff2');font-weight:700;font-style:normal;font-display:swap}@font-face{font-family:'The Future';src:url(/assets/fonts/the-future-light.woff2) format('woff2');font-weight:300;font-style:normal;font-display:swap}body:has(#custom-index-content) #header,body:has(#custom-index-content) #navbar,body:has(#custom-index-content) #search-bar-entry,body:has(#custom-index-content) #search-bar-entry-mobile,body:has(#custom-index-content) .chat-assistant-floating-input,body:has(#custom-index-content) :has(>.chat-assistant-floating-input),body:has(#custom-index-content) button#search-bar-entry,body:has(#custom-index-content) button#search-bar-entry-mobile,body:has(#custom-index-content) header,body:has(#custom-index-content) nav[aria-label]{display:none!important;visibility:hidden!important;opacity:0!important;width:0!important;height:0!important;position:absolute!important;left:-99999px!important;pointer-events:none!important}body:has(#custom-index-content) #custom-index-content,body:has(#custom-index-content) #custom-index-content a,body:has(#custom-index-content) #custom-index-content h1,body:has(#custom-index-content) #custom-index-content h2,body:has(#custom-index-content) #custom-index-content h3,body:has(#custom-index-content) #custom-index-content p{font-family:'The Future',sans-serif}@media (max-width:768px){button[aria-label=\"More actions\"]{display:none!important}#custom-index-content{margin-top:-120px}}@media (min-width:769px) and (max-width:1023px){#custom-index-content{margin-top:-120px}}.prose .callout a,.prose .info a,.prose .note a,.prose .step a,.prose .steps a,.prose .tip a,.prose .warning a,.prose [role=listitem] a,.prose div[data-callout-type] a,.prose li a,.prose p a,.prose span a,.prose ul a{border-bottom-color:#0e0e0e!important;text-decoration-color:#0e0e0e!important}.dark .prose .callout a,.dark .prose .info a,.dark .prose .note a,.dark .prose .step a,.dark .prose .steps a,.dark .prose .tip a,.dark .prose .warning a,.dark .prose [role=listitem] a,.dark .prose div[data-callout-type] a,.dark .prose li a,.dark .prose p a,.dark .prose span a,.dark .prose ul a{border-bottom-color:#ccc!important;text-decoration-color:#ccc!important}.highlighted-card-bg{background-color:#ffb84d;position:relative;overflow:hidden;transition:box-shadow .3s ease-in-out}.highlighted-card-bg:hover{box-shadow:0 0 30px rgba(255,184,77,.5),0 0 60px rgba(255,184,77,.3),0 10px 40px rgba(255,184,77,.2)}.highlighted-card-bg::before{content:'';position:absolute;top:-50%;left:-50%;width:200%;height:200%;background:linear-gradient(45deg,transparent 30%,rgba(255,255,255,.4) 50%,transparent 70%);transform:translateX(-100%) translateY(-100%) rotate(45deg);transition:transform .6s ease-in-out}.highlighted-card-bg:hover::before{transform:translateX(100%) translateY(100%) rotate(45deg)}@layer utilities{body:has(#custom-index-content) #footer{display:flex!important}}code,pre,pre code{font-family:'Fira Code','Cascadia Code','JetBrains Mono',monospace!important}"}],"page":{"pagePath":"sdk/next/api-reference/rest/tx/txdecode","slug":"/sdk/next/api-reference/rest/tx/txdecode","pageMetadata":{"title":"TxDecode","description":"gRPC: `cosmos.tx.v1beta1.Service/TxDecode` ([reference](/sdk/next/api-reference/grpc/tx#txdecode))\n\nTxDecode decodes the transaction.","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml post /cosmos/tx/v1beta1/decode","href":"/sdk/next/api-reference/rest/tx/txdecode","autogeneratedByOpenApi":true},"description":{"compiledSource":"\"use strict\";\nconst {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0];\nconst {useMDXComponents: _provideComponents} = arguments[0];\nfunction _createMdxContent(props) {\n const _components = {\n a: \"a\",\n code: \"code\",\n p: \"p\",\n ..._provideComponents(),\n ...props.components\n };\n return _jsxs(_Fragment, {\n children: [_jsxs(_components.p, {\n children: [\"gRPC: \", _jsx(_components.code, {\n children: \"cosmos.tx.v1beta1.Service/TxDecode\"\n }), \" (\", _jsx(_components.a, {\n href: \"/sdk/next/api-reference/grpc/tx#txdecode\",\n children: \"reference\"\n }), \")\"]\n }), \"\\n\", _jsx(_components.p, {\n children: \"TxDecode decodes the transaction.\"\n })]\n });\n}\nfunction MDXContent(props = {}) {\n const {wrapper: MDXLayout} = {\n ..._provideComponents(),\n ...props.components\n };\n return MDXLayout ? _jsx(MDXLayout, {\n ...props,\n children: _jsx(_createMdxContent, {\n ...props\n })\n }) : _createMdxContent(props);\n}\nreturn {\n default: MDXContent\n};\n","frontmatter":{},"scope":{}},"pageType":"default","mdx":{"mdxSource":{"compiledSource":"\"use strict\";const{Fragment:_Fragment,jsx:_jsx}=arguments[0];const{useMDXComponents:_provideComponents}=arguments[0];function _createMdxContent(props){return _jsx(_Fragment,{})}function MDXContent(props={}){const{wrapper:MDXLayout}={..._provideComponents(),...props.components};return MDXLayout?_jsx(MDXLayout,{...props,children:_jsx(_createMdxContent,{...props})}):_createMdxContent(props)}return{default:MDXContent}","frontmatter":{},"scope":{"codeStyling":{"theme":{"light":"github-light-high-contrast","dark":"github-dark-high-contrast"}},"config":{},"pageMetadata":{"title":"TxDecode","description":"gRPC: `cosmos.tx.v1beta1.Service/TxDecode` ([reference](/sdk/next/api-reference/grpc/tx#txdecode))\n\nTxDecode decodes the transaction.","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml post /cosmos/tx/v1beta1/decode","href":"/sdk/next/api-reference/rest/tx/txdecode","autogeneratedByOpenApi":true}}},"mdxSourceWithNoJs":null},"mdxExtracts":{"tableOfContents":[],"codeExamples":{}},"jsLinks":[],"openApiReferenceData":{"operation":{"summary":"TxDecode","operationId":"tx_v1beta1_TxDecode","responses":{"200":"6857aa1c-a486-47df-839d-cd91fef6ff39","default":"ca850f68-b09f-47bd-97f9-7f6a15140833"},"requestBody":"6a85fcf8-4cf5-4ac7-b8b9-112dc0bd4fe3","tags":["tx"],"description":"gRPC: `cosmos.tx.v1beta1.Service/TxDecode` ([reference](/sdk/next/api-reference/grpc/tx#txdecode))\n\nTxDecode decodes the transaction.","x-grpc-method":"cosmos.tx.v1beta1.Service/TxDecode","method":"post","type":"path","servers":["a9f8ae3b-0246-48ff-af65-1f5630d769c5","f0b124ec-07c0-430c-9ffe-742b4568c32c"],"security":[],"path":"/cosmos/tx/v1beta1/decode","baseUrlOptions":["https://cosmos-rest.publicnode.com","http://localhost:1317"],"title":"TxDecode","codeSamples":[],"requiredOnlyExamples":false,"requestExampleType":"generated","responseExampleType":"generated"},"dependencies":{"parameters":{},"requestBody":{"content":{"application/json":{"schema":{"type":"object","properties":{"tx_bytes":{"type":"string","format":"byte","description":"tx_bytes is the raw transaction.","uniqueKey":"tx_bytes","typeLabel":"string\u003cbyte>"}},"description":"TxDecodeRequest is the request type for the Service.TxDecode\nRPC method.","uniqueKey":"","typeLabel":"object"},"examples":{"Example":{"title":"Example","value":{"tx_bytes":"aSDinaTvuI8gbWludGxpZnk="}}},"exampleType":"generated"}},"description":"TxDecodeRequest is the request type for the Service.TxDecode\nRPC method.","required":true,"exampleType":"generated"},"responses":{"6857aa1c-a486-47df-839d-cd91fef6ff39":{"description":"A successful response.","content":{"*/*":{"schema":{"type":"object","properties":{"tx":{"oneOf":[{"type":"object","properties":{"body":{"oneOf":[{"title":"body is the processable content of the transaction","type":"object","properties":{"messages":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics.","uniqueKey":"tx.oneOf.0.body.oneOf.0.messages.oneOf.0.items.[INDEX].@type","typeLabel":"string"}},"additionalProperties":{"oneOf":[{}],"uniqueKey":"tx.oneOf.0.body.oneOf.0.messages.oneOf.0.items.[INDEX].additionalProperties","typeLabel":"any"},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }","uniqueKey":"tx.oneOf.0.body.oneOf.0.messages.oneOf.0.items.[INDEX]","typeLabel":"object"},"description":"messages is a list of messages to be executed. The required signers of\nthose messages define the number and order of elements in AuthInfo's\nsigner_infos and Tx's signatures. Each required signer address is added to\nthe list only the first time it occurs.\nBy convention, the first required signer (usually from the first message)\nis referred to as the primary signer and pays the fee for the whole\ntransaction.","uniqueKey":"tx.oneOf.0.body.oneOf.0.messages.oneOf.0","typeLabel":"object[]"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"description":"messages is a list of messages to be executed. The required signers of\nthose messages define the number and order of elements in AuthInfo's\nsigner_infos and Tx's signatures. Each required signer address is added to\nthe list only the first time it occurs.\nBy convention, the first required signer (usually from the first message)\nis referred to as the primary signer and pays the fee for the whole\ntransaction.","uniqueKey":"tx.oneOf.0.body.oneOf.0.messages.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.body.oneOf.0.messages","typeLabel":"object[] | null"},"memo":{"type":"string","description":"memo is any arbitrary note/comment to be added to the transaction.\nWARNING: in clients, any publicly exposed text should not be called memo,\nbut should be called `note` instead (see\nhttps://github.com/cosmos/cosmos-sdk/issues/9122).","uniqueKey":"tx.oneOf.0.body.oneOf.0.memo","typeLabel":"string"},"timeout_height":{"type":"string","format":"uint64","description":"timeout_height is the block height after which this transaction will not\nbe processed by the chain.","uniqueKey":"tx.oneOf.0.body.oneOf.0.timeout_height","typeLabel":"string\u003cuint64>"},"unordered":{"type":"boolean","description":"unordered, when set to true, indicates that the transaction signer(s)\nintend for the transaction to be evaluated and executed in an un-ordered\nfashion. Specifically, the account's nonce will NOT be checked or\nincremented, which allows for fire-and-forget as well as concurrent\ntransaction execution.\n\nNote, when set to true, the existing 'timeout_timestamp' value must\nbe set and will be used to correspond to a timestamp in which the transaction is deemed\nvalid.\n\nWhen true, the sequence value MUST be 0, and any transaction with unordered=true and a non-zero sequence value will\nbe rejected.\nExternal services that make assumptions about sequence values may need to be updated because of this.","uniqueKey":"tx.oneOf.0.body.oneOf.0.unordered","typeLabel":"boolean"},"timeout_timestamp":{"oneOf":[{"type":"string","format":"date-time","description":"timeout_timestamp is the block time after which this transaction will not\nbe processed by the chain.\n\nNote, if unordered=true this value MUST be set\nand will act as a short-lived TTL in which the transaction is deemed valid\nand kept in memory to prevent duplicates.","uniqueKey":"tx.oneOf.0.body.oneOf.0.timeout_timestamp.oneOf.0","typeLabel":"string\u003cdate-time>"},{"type":"null","format":"date-time","description":"timeout_timestamp is the block time after which this transaction will not\nbe processed by the chain.\n\nNote, if unordered=true this value MUST be set\nand will act as a short-lived TTL in which the transaction is deemed valid\nand kept in memory to prevent duplicates.","uniqueKey":"tx.oneOf.0.body.oneOf.0.timeout_timestamp.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.body.oneOf.0.timeout_timestamp","typeLabel":"string\u003cdate-time> | null"},"extension_options":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics.","uniqueKey":"tx.oneOf.0.body.oneOf.0.extension_options.oneOf.0.items.[INDEX].@type","typeLabel":"string"}},"additionalProperties":{"oneOf":[{}],"uniqueKey":"tx.oneOf.0.body.oneOf.0.extension_options.oneOf.0.items.[INDEX].additionalProperties","typeLabel":"any"},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }","uniqueKey":"tx.oneOf.0.body.oneOf.0.extension_options.oneOf.0.items.[INDEX]","typeLabel":"object"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected","uniqueKey":"tx.oneOf.0.body.oneOf.0.extension_options.oneOf.0","typeLabel":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected · object[]"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected","uniqueKey":"tx.oneOf.0.body.oneOf.0.extension_options.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.body.oneOf.0.extension_options","typeLabel":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected · object[] | null"},"non_critical_extension_options":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics.","uniqueKey":"tx.oneOf.0.body.oneOf.0.non_critical_extension_options.oneOf.0.items.[INDEX].@type","typeLabel":"string"}},"additionalProperties":{"oneOf":[{}],"uniqueKey":"tx.oneOf.0.body.oneOf.0.non_critical_extension_options.oneOf.0.items.[INDEX].additionalProperties","typeLabel":"any"},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }","uniqueKey":"tx.oneOf.0.body.oneOf.0.non_critical_extension_options.oneOf.0.items.[INDEX]","typeLabel":"object"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored","uniqueKey":"tx.oneOf.0.body.oneOf.0.non_critical_extension_options.oneOf.0","typeLabel":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored · object[]"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored","uniqueKey":"tx.oneOf.0.body.oneOf.0.non_critical_extension_options.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.body.oneOf.0.non_critical_extension_options","typeLabel":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored · object[] | null"}},"description":"TxBody is the body of a transaction that all signers sign over.","uniqueKey":"tx.oneOf.0.body.oneOf.0","typeLabel":"body is the processable content of the transaction · object"},{"title":"body is the processable content of the transaction","type":"null","properties":{"messages":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"description":"messages is a list of messages to be executed. The required signers of\nthose messages define the number and order of elements in AuthInfo's\nsigner_infos and Tx's signatures. Each required signer address is added to\nthe list only the first time it occurs.\nBy convention, the first required signer (usually from the first message)\nis referred to as the primary signer and pays the fee for the whole\ntransaction."},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"description":"messages is a list of messages to be executed. The required signers of\nthose messages define the number and order of elements in AuthInfo's\nsigner_infos and Tx's signatures. Each required signer address is added to\nthe list only the first time it occurs.\nBy convention, the first required signer (usually from the first message)\nis referred to as the primary signer and pays the fee for the whole\ntransaction."}]},"memo":{"type":"string","description":"memo is any arbitrary note/comment to be added to the transaction.\nWARNING: in clients, any publicly exposed text should not be called memo,\nbut should be called `note` instead (see\nhttps://github.com/cosmos/cosmos-sdk/issues/9122)."},"timeout_height":{"type":"string","format":"uint64","description":"timeout_height is the block height after which this transaction will not\nbe processed by the chain."},"unordered":{"type":"boolean","description":"unordered, when set to true, indicates that the transaction signer(s)\nintend for the transaction to be evaluated and executed in an un-ordered\nfashion. Specifically, the account's nonce will NOT be checked or\nincremented, which allows for fire-and-forget as well as concurrent\ntransaction execution.\n\nNote, when set to true, the existing 'timeout_timestamp' value must\nbe set and will be used to correspond to a timestamp in which the transaction is deemed\nvalid.\n\nWhen true, the sequence value MUST be 0, and any transaction with unordered=true and a non-zero sequence value will\nbe rejected.\nExternal services that make assumptions about sequence values may need to be updated because of this."},"timeout_timestamp":{"oneOf":[{"type":"string","format":"date-time","description":"timeout_timestamp is the block time after which this transaction will not\nbe processed by the chain.\n\nNote, if unordered=true this value MUST be set\nand will act as a short-lived TTL in which the transaction is deemed valid\nand kept in memory to prevent duplicates."},{"type":"null","format":"date-time","description":"timeout_timestamp is the block time after which this transaction will not\nbe processed by the chain.\n\nNote, if unordered=true this value MUST be set\nand will act as a short-lived TTL in which the transaction is deemed valid\nand kept in memory to prevent duplicates."}]},"extension_options":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected"}]},"non_critical_extension_options":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored"}]}},"description":"TxBody is the body of a transaction that all signers sign over.","uniqueKey":"tx.oneOf.0.body.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.body","typeLabel":"body is the processable content of the transaction · object | null"},"auth_info":{"oneOf":[{"type":"object","properties":{"signer_infos":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"public_key":{"oneOf":[{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics.","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].public_key.oneOf.0.@type","typeLabel":"string"}},"additionalProperties":{"oneOf":[{}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].public_key.oneOf.0.additionalProperties","typeLabel":"any"},"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].public_key.oneOf.0","typeLabel":"object"},{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"null","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].public_key.oneOf.1.additionalProperties","typeLabel":"any"},"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].public_key.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].public_key","typeLabel":"object | null"},"mode_info":{"oneOf":[{"type":"object","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.single.oneOf.0.mode.oneOf.0","typeLabel":"enum\u003cstring>"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.single.oneOf.0.mode.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.single.oneOf.0.mode","typeLabel":"enum\u003cstring> | null"}},"additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.single.oneOf.0","typeLabel":"single represents a single signer · object"},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.single.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.single","typeLabel":"single represents a single signer · object | null"},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.bitarray.oneOf.0.extra_bits_stored","typeLabel":"integer\u003cint64>"},"elems":{"oneOf":[{"type":"string","format":"byte","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.bitarray.oneOf.0.elems.oneOf.0","typeLabel":"string\u003cbyte>"},{"type":"null","format":"byte","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.bitarray.oneOf.0.elems.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.bitarray.oneOf.0.elems","typeLabel":"string\u003cbyte> | null"}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.bitarray.oneOf.0","typeLabel":"bitarray specifies which keys within the multisig are signing · object"},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.bitarray.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.bitarray","typeLabel":"bitarray specifies which keys within the multisig are signing · object | null"},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.mode_infos.oneOf.0.items.[INDEX]","typeLabel":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.mode_infos.oneOf.0","typeLabel":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys · object[]"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.mode_infos.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0.mode_infos","typeLabel":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys · object[] | null"}},"title":"multi represents a nested multisig signer","additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.0","typeLabel":"multi represents a nested multisig signer · object"},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0.multi","typeLabel":"multi represents a nested multisig signer · object | null"}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.0","typeLabel":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's · object"},{"type":"null","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].mode_info","typeLabel":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's · object | null"},"sequence":{"type":"string","format":"uint64","description":"sequence is the sequence of the account, which describes the\nnumber of committed transactions signed by a given address. It is used to\nprevent replay attacks.","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX].sequence","typeLabel":"string\u003cuint64>"}},"description":"SignerInfo describes the public key and signing mode of a single top-level\nsigner.","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0.items.[INDEX]","typeLabel":"object"},"description":"signer_infos defines the signing modes for the required signers. The number\nand order of elements must match the required signers from TxBody's\nmessages. The first element is the primary signer and the one which pays\nthe fee.","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.0","typeLabel":"object[]"},{"type":"null","items":{"type":"object","properties":{"public_key":{"oneOf":[{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}},{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"null","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}}]},"mode_info":{"oneOf":[{"type":"object","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"},{"type":"null","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"}]},"sequence":{"type":"string","format":"uint64","description":"sequence is the sequence of the account, which describes the\nnumber of committed transactions signed by a given address. It is used to\nprevent replay attacks."}},"description":"SignerInfo describes the public key and signing mode of a single top-level\nsigner."},"description":"signer_infos defines the signing modes for the required signers. The number\nand order of elements must match the required signers from TxBody's\nmessages. The first element is the primary signer and the one which pays\nthe fee.","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.signer_infos","typeLabel":"object[] | null"},"fee":{"oneOf":[{"description":"Fee is the fee and gas limit for the transaction. The first signer is the\nprimary signer and the one which pays the fee. The fee can be calculated\nbased on the cost of evaluating the body and doing signature verification\nof the signers. This can be estimated via simulation.","type":"object","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.amount.oneOf.0.items.[INDEX].denom","typeLabel":"string"},"amount":{"type":"string","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.amount.oneOf.0.items.[INDEX].amount","typeLabel":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.amount.oneOf.0.items.[INDEX]","typeLabel":"object"},"title":"amount is the amount of coins to be paid as a fee","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.amount.oneOf.0","typeLabel":"amount is the amount of coins to be paid as a fee · object[]"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.amount.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.amount","typeLabel":"amount is the amount of coins to be paid as a fee · object[] | null"},"gas_limit":{"type":"string","format":"uint64","title":"gas_limit is the maximum gas that can be used in transaction processing\nbefore an out of gas error occurs","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.gas_limit","typeLabel":"string\u003cuint64>"},"payer":{"type":"string","description":"if unset, the first signer is responsible for paying the fees. If set, the\nspecified account must pay the fees. the payer must be a tx signer (and\nthus have signed this field in AuthInfo). setting this field does *not*\nchange the ordering of required signers for the transaction.","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.payer","typeLabel":"string"},"granter":{"type":"string","title":"if set, the fee payer (either the first signer or the value of the payer\nfield) requests that a fee grant be used to pay fees instead of the fee\npayer's own balance. If an appropriate fee grant does not exist or the\nchain does not support fee grants, this will fail","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0.granter","typeLabel":"string"}},"additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.0","typeLabel":"object"},{"description":"Fee is the fee and gas limit for the transaction. The first signer is the\nprimary signer and the one which pays the fee. The fee can be calculated\nbased on the cost of evaluating the body and doing signature verification\nof the signers. This can be estimated via simulation.","type":"null","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"}]},"gas_limit":{"type":"string","format":"uint64","title":"gas_limit is the maximum gas that can be used in transaction processing\nbefore an out of gas error occurs"},"payer":{"type":"string","description":"if unset, the first signer is responsible for paying the fees. If set, the\nspecified account must pay the fees. the payer must be a tx signer (and\nthus have signed this field in AuthInfo). setting this field does *not*\nchange the ordering of required signers for the transaction."},"granter":{"type":"string","title":"if set, the fee payer (either the first signer or the value of the payer\nfield) requests that a fee grant be used to pay fees instead of the fee\npayer's own balance. If an appropriate fee grant does not exist or the\nchain does not support fee grants, this will fail"}},"additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.fee","typeLabel":"object | null"},"tip":{"oneOf":[{"description":"Tip is the optional tip used for transactions fees paid in another denom.\n\nThis field is ignored if the chain didn't enable tips, i.e. didn't add the\n`TipDecorator` in its posthandler.","type":"object","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.0.amount.oneOf.0.items.[INDEX].denom","typeLabel":"string"},"amount":{"type":"string","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.0.amount.oneOf.0.items.[INDEX].amount","typeLabel":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.0.amount.oneOf.0.items.[INDEX]","typeLabel":"object"},"title":"amount is the amount of the tip","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.0.amount.oneOf.0","typeLabel":"amount is the amount of the tip · object[]"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.0.amount.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.0.amount","typeLabel":"amount is the amount of the tip · object[] | null"},"tipper":{"type":"string","title":"tipper is the address of the account paying for the tip","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.0.tipper","typeLabel":"string"}},"additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.0","typeLabel":"object"},{"description":"Tip is the optional tip used for transactions fees paid in another denom.\n\nThis field is ignored if the chain didn't enable tips, i.e. didn't add the\n`TipDecorator` in its posthandler.","type":"null","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"}]},"tipper":{"type":"string","title":"tipper is the address of the account paying for the tip"}},"additionalProperties":false,"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info.oneOf.0.tip","typeLabel":"object | null"}},"description":"AuthInfo describes the fee and signer modes that are used to sign a\ntransaction.","additionalProperties":false,"title":"auth_info is the authorization related content of the transaction,\nspecifically signers, signer modes and fee","uniqueKey":"tx.oneOf.0.auth_info.oneOf.0","typeLabel":"auth_info is the authorization related content of the transaction,\nspecifically signers, signer modes and fee · object"},{"type":"null","properties":{"signer_infos":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"public_key":{"oneOf":[{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}},{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"null","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}}]},"mode_info":{"oneOf":[{"type":"object","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"},{"type":"null","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"}]},"sequence":{"type":"string","format":"uint64","description":"sequence is the sequence of the account, which describes the\nnumber of committed transactions signed by a given address. It is used to\nprevent replay attacks."}},"description":"SignerInfo describes the public key and signing mode of a single top-level\nsigner."},"description":"signer_infos defines the signing modes for the required signers. The number\nand order of elements must match the required signers from TxBody's\nmessages. The first element is the primary signer and the one which pays\nthe fee."},{"type":"null","items":{"type":"object","properties":{"public_key":{"oneOf":[{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}},{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"null","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}}]},"mode_info":{"oneOf":[{"type":"object","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"},{"type":"null","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"}]},"sequence":{"type":"string","format":"uint64","description":"sequence is the sequence of the account, which describes the\nnumber of committed transactions signed by a given address. It is used to\nprevent replay attacks."}},"description":"SignerInfo describes the public key and signing mode of a single top-level\nsigner."},"description":"signer_infos defines the signing modes for the required signers. The number\nand order of elements must match the required signers from TxBody's\nmessages. The first element is the primary signer and the one which pays\nthe fee."}]},"fee":{"oneOf":[{"description":"Fee is the fee and gas limit for the transaction. The first signer is the\nprimary signer and the one which pays the fee. The fee can be calculated\nbased on the cost of evaluating the body and doing signature verification\nof the signers. This can be estimated via simulation.","type":"object","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"}]},"gas_limit":{"type":"string","format":"uint64","title":"gas_limit is the maximum gas that can be used in transaction processing\nbefore an out of gas error occurs"},"payer":{"type":"string","description":"if unset, the first signer is responsible for paying the fees. If set, the\nspecified account must pay the fees. the payer must be a tx signer (and\nthus have signed this field in AuthInfo). setting this field does *not*\nchange the ordering of required signers for the transaction."},"granter":{"type":"string","title":"if set, the fee payer (either the first signer or the value of the payer\nfield) requests that a fee grant be used to pay fees instead of the fee\npayer's own balance. If an appropriate fee grant does not exist or the\nchain does not support fee grants, this will fail"}},"additionalProperties":false},{"description":"Fee is the fee and gas limit for the transaction. The first signer is the\nprimary signer and the one which pays the fee. The fee can be calculated\nbased on the cost of evaluating the body and doing signature verification\nof the signers. This can be estimated via simulation.","type":"null","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"}]},"gas_limit":{"type":"string","format":"uint64","title":"gas_limit is the maximum gas that can be used in transaction processing\nbefore an out of gas error occurs"},"payer":{"type":"string","description":"if unset, the first signer is responsible for paying the fees. If set, the\nspecified account must pay the fees. the payer must be a tx signer (and\nthus have signed this field in AuthInfo). setting this field does *not*\nchange the ordering of required signers for the transaction."},"granter":{"type":"string","title":"if set, the fee payer (either the first signer or the value of the payer\nfield) requests that a fee grant be used to pay fees instead of the fee\npayer's own balance. If an appropriate fee grant does not exist or the\nchain does not support fee grants, this will fail"}},"additionalProperties":false}]},"tip":{"oneOf":[{"description":"Tip is the optional tip used for transactions fees paid in another denom.\n\nThis field is ignored if the chain didn't enable tips, i.e. didn't add the\n`TipDecorator` in its posthandler.","type":"object","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"}]},"tipper":{"type":"string","title":"tipper is the address of the account paying for the tip"}},"additionalProperties":false},{"description":"Tip is the optional tip used for transactions fees paid in another denom.\n\nThis field is ignored if the chain didn't enable tips, i.e. didn't add the\n`TipDecorator` in its posthandler.","type":"null","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"}]},"tipper":{"type":"string","title":"tipper is the address of the account paying for the tip"}},"additionalProperties":false}]}},"description":"AuthInfo describes the fee and signer modes that are used to sign a\ntransaction.","additionalProperties":false,"title":"auth_info is the authorization related content of the transaction,\nspecifically signers, signer modes and fee","uniqueKey":"tx.oneOf.0.auth_info.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.auth_info","typeLabel":"auth_info is the authorization related content of the transaction,\nspecifically signers, signer modes and fee · object | null"},"signatures":{"oneOf":[{"type":"array","items":{"type":"string","format":"byte","uniqueKey":"tx.oneOf.0.signatures.oneOf.0.items.[INDEX]","typeLabel":"string\u003cbyte>"},"description":"signatures is a list of signatures that matches the length and order of\nAuthInfo's signer_infos to allow connecting signature meta information like\npublic key and signing mode by position.","uniqueKey":"tx.oneOf.0.signatures.oneOf.0","typeLabel":"string\u003cbyte>[]"},{"type":"null","items":{"type":"string","format":"byte"},"description":"signatures is a list of signatures that matches the length and order of\nAuthInfo's signer_infos to allow connecting signature meta information like\npublic key and signing mode by position.","uniqueKey":"tx.oneOf.0.signatures.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx.oneOf.0.signatures","typeLabel":"string\u003cbyte>[] | null"}},"description":"tx is the decoded transaction.","additionalProperties":false,"uniqueKey":"tx.oneOf.0","typeLabel":"object"},{"type":"null","properties":{"body":{"oneOf":[{"title":"body is the processable content of the transaction","type":"object","properties":{"messages":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"description":"messages is a list of messages to be executed. The required signers of\nthose messages define the number and order of elements in AuthInfo's\nsigner_infos and Tx's signatures. Each required signer address is added to\nthe list only the first time it occurs.\nBy convention, the first required signer (usually from the first message)\nis referred to as the primary signer and pays the fee for the whole\ntransaction."},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"description":"messages is a list of messages to be executed. The required signers of\nthose messages define the number and order of elements in AuthInfo's\nsigner_infos and Tx's signatures. Each required signer address is added to\nthe list only the first time it occurs.\nBy convention, the first required signer (usually from the first message)\nis referred to as the primary signer and pays the fee for the whole\ntransaction."}]},"memo":{"type":"string","description":"memo is any arbitrary note/comment to be added to the transaction.\nWARNING: in clients, any publicly exposed text should not be called memo,\nbut should be called `note` instead (see\nhttps://github.com/cosmos/cosmos-sdk/issues/9122)."},"timeout_height":{"type":"string","format":"uint64","description":"timeout_height is the block height after which this transaction will not\nbe processed by the chain."},"unordered":{"type":"boolean","description":"unordered, when set to true, indicates that the transaction signer(s)\nintend for the transaction to be evaluated and executed in an un-ordered\nfashion. Specifically, the account's nonce will NOT be checked or\nincremented, which allows for fire-and-forget as well as concurrent\ntransaction execution.\n\nNote, when set to true, the existing 'timeout_timestamp' value must\nbe set and will be used to correspond to a timestamp in which the transaction is deemed\nvalid.\n\nWhen true, the sequence value MUST be 0, and any transaction with unordered=true and a non-zero sequence value will\nbe rejected.\nExternal services that make assumptions about sequence values may need to be updated because of this."},"timeout_timestamp":{"oneOf":[{"type":"string","format":"date-time","description":"timeout_timestamp is the block time after which this transaction will not\nbe processed by the chain.\n\nNote, if unordered=true this value MUST be set\nand will act as a short-lived TTL in which the transaction is deemed valid\nand kept in memory to prevent duplicates."},{"type":"null","format":"date-time","description":"timeout_timestamp is the block time after which this transaction will not\nbe processed by the chain.\n\nNote, if unordered=true this value MUST be set\nand will act as a short-lived TTL in which the transaction is deemed valid\nand kept in memory to prevent duplicates."}]},"extension_options":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected"}]},"non_critical_extension_options":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored"}]}},"description":"TxBody is the body of a transaction that all signers sign over."},{"title":"body is the processable content of the transaction","type":"null","properties":{"messages":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"description":"messages is a list of messages to be executed. The required signers of\nthose messages define the number and order of elements in AuthInfo's\nsigner_infos and Tx's signatures. Each required signer address is added to\nthe list only the first time it occurs.\nBy convention, the first required signer (usually from the first message)\nis referred to as the primary signer and pays the fee for the whole\ntransaction."},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"description":"messages is a list of messages to be executed. The required signers of\nthose messages define the number and order of elements in AuthInfo's\nsigner_infos and Tx's signatures. Each required signer address is added to\nthe list only the first time it occurs.\nBy convention, the first required signer (usually from the first message)\nis referred to as the primary signer and pays the fee for the whole\ntransaction."}]},"memo":{"type":"string","description":"memo is any arbitrary note/comment to be added to the transaction.\nWARNING: in clients, any publicly exposed text should not be called memo,\nbut should be called `note` instead (see\nhttps://github.com/cosmos/cosmos-sdk/issues/9122)."},"timeout_height":{"type":"string","format":"uint64","description":"timeout_height is the block height after which this transaction will not\nbe processed by the chain."},"unordered":{"type":"boolean","description":"unordered, when set to true, indicates that the transaction signer(s)\nintend for the transaction to be evaluated and executed in an un-ordered\nfashion. Specifically, the account's nonce will NOT be checked or\nincremented, which allows for fire-and-forget as well as concurrent\ntransaction execution.\n\nNote, when set to true, the existing 'timeout_timestamp' value must\nbe set and will be used to correspond to a timestamp in which the transaction is deemed\nvalid.\n\nWhen true, the sequence value MUST be 0, and any transaction with unordered=true and a non-zero sequence value will\nbe rejected.\nExternal services that make assumptions about sequence values may need to be updated because of this."},"timeout_timestamp":{"oneOf":[{"type":"string","format":"date-time","description":"timeout_timestamp is the block time after which this transaction will not\nbe processed by the chain.\n\nNote, if unordered=true this value MUST be set\nand will act as a short-lived TTL in which the transaction is deemed valid\nand kept in memory to prevent duplicates."},{"type":"null","format":"date-time","description":"timeout_timestamp is the block time after which this transaction will not\nbe processed by the chain.\n\nNote, if unordered=true this value MUST be set\nand will act as a short-lived TTL in which the transaction is deemed valid\nand kept in memory to prevent duplicates."}]},"extension_options":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, the transaction will be rejected"}]},"non_critical_extension_options":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored"},{"type":"null","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }"},"title":"extension_options are arbitrary options that can be added by chains\nwhen the default options are not sufficient. If any of these are present\nand can't be handled, they will be ignored"}]}},"description":"TxBody is the body of a transaction that all signers sign over."}]},"auth_info":{"oneOf":[{"type":"object","properties":{"signer_infos":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"public_key":{"oneOf":[{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}},{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"null","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}}]},"mode_info":{"oneOf":[{"type":"object","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"},{"type":"null","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"}]},"sequence":{"type":"string","format":"uint64","description":"sequence is the sequence of the account, which describes the\nnumber of committed transactions signed by a given address. It is used to\nprevent replay attacks."}},"description":"SignerInfo describes the public key and signing mode of a single top-level\nsigner."},"description":"signer_infos defines the signing modes for the required signers. The number\nand order of elements must match the required signers from TxBody's\nmessages. The first element is the primary signer and the one which pays\nthe fee."},{"type":"null","items":{"type":"object","properties":{"public_key":{"oneOf":[{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}},{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"null","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}}]},"mode_info":{"oneOf":[{"type":"object","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"},{"type":"null","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"}]},"sequence":{"type":"string","format":"uint64","description":"sequence is the sequence of the account, which describes the\nnumber of committed transactions signed by a given address. It is used to\nprevent replay attacks."}},"description":"SignerInfo describes the public key and signing mode of a single top-level\nsigner."},"description":"signer_infos defines the signing modes for the required signers. The number\nand order of elements must match the required signers from TxBody's\nmessages. The first element is the primary signer and the one which pays\nthe fee."}]},"fee":{"oneOf":[{"description":"Fee is the fee and gas limit for the transaction. The first signer is the\nprimary signer and the one which pays the fee. The fee can be calculated\nbased on the cost of evaluating the body and doing signature verification\nof the signers. This can be estimated via simulation.","type":"object","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"}]},"gas_limit":{"type":"string","format":"uint64","title":"gas_limit is the maximum gas that can be used in transaction processing\nbefore an out of gas error occurs"},"payer":{"type":"string","description":"if unset, the first signer is responsible for paying the fees. If set, the\nspecified account must pay the fees. the payer must be a tx signer (and\nthus have signed this field in AuthInfo). setting this field does *not*\nchange the ordering of required signers for the transaction."},"granter":{"type":"string","title":"if set, the fee payer (either the first signer or the value of the payer\nfield) requests that a fee grant be used to pay fees instead of the fee\npayer's own balance. If an appropriate fee grant does not exist or the\nchain does not support fee grants, this will fail"}},"additionalProperties":false},{"description":"Fee is the fee and gas limit for the transaction. The first signer is the\nprimary signer and the one which pays the fee. The fee can be calculated\nbased on the cost of evaluating the body and doing signature verification\nof the signers. This can be estimated via simulation.","type":"null","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"}]},"gas_limit":{"type":"string","format":"uint64","title":"gas_limit is the maximum gas that can be used in transaction processing\nbefore an out of gas error occurs"},"payer":{"type":"string","description":"if unset, the first signer is responsible for paying the fees. If set, the\nspecified account must pay the fees. the payer must be a tx signer (and\nthus have signed this field in AuthInfo). setting this field does *not*\nchange the ordering of required signers for the transaction."},"granter":{"type":"string","title":"if set, the fee payer (either the first signer or the value of the payer\nfield) requests that a fee grant be used to pay fees instead of the fee\npayer's own balance. If an appropriate fee grant does not exist or the\nchain does not support fee grants, this will fail"}},"additionalProperties":false}]},"tip":{"oneOf":[{"description":"Tip is the optional tip used for transactions fees paid in another denom.\n\nThis field is ignored if the chain didn't enable tips, i.e. didn't add the\n`TipDecorator` in its posthandler.","type":"object","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"}]},"tipper":{"type":"string","title":"tipper is the address of the account paying for the tip"}},"additionalProperties":false},{"description":"Tip is the optional tip used for transactions fees paid in another denom.\n\nThis field is ignored if the chain didn't enable tips, i.e. didn't add the\n`TipDecorator` in its posthandler.","type":"null","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"}]},"tipper":{"type":"string","title":"tipper is the address of the account paying for the tip"}},"additionalProperties":false}]}},"description":"AuthInfo describes the fee and signer modes that are used to sign a\ntransaction.","additionalProperties":false,"title":"auth_info is the authorization related content of the transaction,\nspecifically signers, signer modes and fee"},{"type":"null","properties":{"signer_infos":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"public_key":{"oneOf":[{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}},{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"null","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}}]},"mode_info":{"oneOf":[{"type":"object","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"},{"type":"null","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"}]},"sequence":{"type":"string","format":"uint64","description":"sequence is the sequence of the account, which describes the\nnumber of committed transactions signed by a given address. It is used to\nprevent replay attacks."}},"description":"SignerInfo describes the public key and signing mode of a single top-level\nsigner."},"description":"signer_infos defines the signing modes for the required signers. The number\nand order of elements must match the required signers from TxBody's\nmessages. The first element is the primary signer and the one which pays\nthe fee."},{"type":"null","items":{"type":"object","properties":{"public_key":{"oneOf":[{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}},{"description":"public_key is the public key of the signer. It is optional for accounts\nthat already exist in state. If unset, the verifier can use the required \\\nsigner address for this position and lookup the public key.","type":"null","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics."}},"additionalProperties":{"oneOf":[{}]}}]},"mode_info":{"oneOf":[{"type":"object","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"},{"type":"null","properties":{"single":{"oneOf":[{"title":"single represents a single signer","type":"object","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false},{"title":"single represents a single signer","type":"null","properties":{"mode":{"oneOf":[{"title":"mode is the signing mode of the single signer","type":"string","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"},{"title":"mode is the signing mode of the single signer","type":"null","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"],"default":"SIGN_MODE_UNSPECIFIED","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2"}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false},{"type":"null","properties":{"bitarray":{"oneOf":[{"title":"bitarray specifies which keys within the multisig are signing","type":"object","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false},{"title":"bitarray specifies which keys within the multisig are signing","type":"null","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","items":{"$circularRef":"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff","type":"object"},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"title":"multi represents a nested multisig signer","additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false,"title":"mode_info describes the signing mode of the signer and is a nested\nstructure to support nested multisig pubkey's"}]},"sequence":{"type":"string","format":"uint64","description":"sequence is the sequence of the account, which describes the\nnumber of committed transactions signed by a given address. It is used to\nprevent replay attacks."}},"description":"SignerInfo describes the public key and signing mode of a single top-level\nsigner."},"description":"signer_infos defines the signing modes for the required signers. The number\nand order of elements must match the required signers from TxBody's\nmessages. The first element is the primary signer and the one which pays\nthe fee."}]},"fee":{"oneOf":[{"description":"Fee is the fee and gas limit for the transaction. The first signer is the\nprimary signer and the one which pays the fee. The fee can be calculated\nbased on the cost of evaluating the body and doing signature verification\nof the signers. This can be estimated via simulation.","type":"object","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"}]},"gas_limit":{"type":"string","format":"uint64","title":"gas_limit is the maximum gas that can be used in transaction processing\nbefore an out of gas error occurs"},"payer":{"type":"string","description":"if unset, the first signer is responsible for paying the fees. If set, the\nspecified account must pay the fees. the payer must be a tx signer (and\nthus have signed this field in AuthInfo). setting this field does *not*\nchange the ordering of required signers for the transaction."},"granter":{"type":"string","title":"if set, the fee payer (either the first signer or the value of the payer\nfield) requests that a fee grant be used to pay fees instead of the fee\npayer's own balance. If an appropriate fee grant does not exist or the\nchain does not support fee grants, this will fail"}},"additionalProperties":false},{"description":"Fee is the fee and gas limit for the transaction. The first signer is the\nprimary signer and the one which pays the fee. The fee can be calculated\nbased on the cost of evaluating the body and doing signature verification\nof the signers. This can be estimated via simulation.","type":"null","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of coins to be paid as a fee"}]},"gas_limit":{"type":"string","format":"uint64","title":"gas_limit is the maximum gas that can be used in transaction processing\nbefore an out of gas error occurs"},"payer":{"type":"string","description":"if unset, the first signer is responsible for paying the fees. If set, the\nspecified account must pay the fees. the payer must be a tx signer (and\nthus have signed this field in AuthInfo). setting this field does *not*\nchange the ordering of required signers for the transaction."},"granter":{"type":"string","title":"if set, the fee payer (either the first signer or the value of the payer\nfield) requests that a fee grant be used to pay fees instead of the fee\npayer's own balance. If an appropriate fee grant does not exist or the\nchain does not support fee grants, this will fail"}},"additionalProperties":false}]},"tip":{"oneOf":[{"description":"Tip is the optional tip used for transactions fees paid in another denom.\n\nThis field is ignored if the chain didn't enable tips, i.e. didn't add the\n`TipDecorator` in its posthandler.","type":"object","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"}]},"tipper":{"type":"string","title":"tipper is the address of the account paying for the tip"}},"additionalProperties":false},{"description":"Tip is the optional tip used for transactions fees paid in another denom.\n\nThis field is ignored if the chain didn't enable tips, i.e. didn't add the\n`TipDecorator` in its posthandler.","type":"null","properties":{"amount":{"oneOf":[{"type":"array","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"},{"type":"null","items":{"type":"object","properties":{"denom":{"type":"string"},"amount":{"type":"string"}},"description":"Coin defines a token with a denomination and an amount.\n\nNOTE: The amount field is an Int which implements the custom method\nsignatures required by gogoproto.","additionalProperties":false},"title":"amount is the amount of the tip"}]},"tipper":{"type":"string","title":"tipper is the address of the account paying for the tip"}},"additionalProperties":false}]}},"description":"AuthInfo describes the fee and signer modes that are used to sign a\ntransaction.","additionalProperties":false,"title":"auth_info is the authorization related content of the transaction,\nspecifically signers, signer modes and fee"}]},"signatures":{"oneOf":[{"type":"array","items":{"type":"string","format":"byte"},"description":"signatures is a list of signatures that matches the length and order of\nAuthInfo's signer_infos to allow connecting signature meta information like\npublic key and signing mode by position."},{"type":"null","items":{"type":"string","format":"byte"},"description":"signatures is a list of signatures that matches the length and order of\nAuthInfo's signer_infos to allow connecting signature meta information like\npublic key and signing mode by position."}]}},"description":"tx is the decoded transaction.","additionalProperties":false,"uniqueKey":"tx.oneOf.1","typeLabel":"null"}],"uniqueKey":"tx","typeLabel":"object | null"}},"description":"TxDecodeResponse is the response type for the\nService.TxDecode method.","additionalProperties":false,"uniqueKey":"","typeLabel":"object"},"examples":{"Example":{"title":"Example","value":{"tx":{"body":{"messages":[{"@type":"\u003cstring>"}],"memo":"\u003cstring>","timeout_height":"\u003cstring>","unordered":true,"timeout_timestamp":"2023-11-07T05:31:56Z","extension_options":[{"@type":"\u003cstring>"}],"non_critical_extension_options":[{"@type":"\u003cstring>"}]},"auth_info":{"signer_infos":[{"public_key":{"@type":"\u003cstring>"},"mode_info":{"single":{"mode":"SIGN_MODE_UNSPECIFIED"},"multi":{"bitarray":{"extra_bits_stored":123,"elems":"aSDinaTvuI8gbWludGxpZnk="},"mode_infos":[{}]}},"sequence":"\u003cstring>"}],"fee":{"amount":[{"denom":"\u003cstring>","amount":"\u003cstring>"}],"gas_limit":"\u003cstring>","payer":"\u003cstring>","granter":"\u003cstring>"},"tip":{"amount":[{"denom":"\u003cstring>","amount":"\u003cstring>"}],"tipper":"\u003cstring>"}},"signatures":["aSDinaTvuI8gbWludGxpZnk="]}}}},"exampleType":"generated"}},"exampleType":"generated"},"ca850f68-b09f-47bd-97f9-7f6a15140833":{"description":"An unexpected error response.","content":{"*/*":{"schema":{"type":"object","properties":{"code":{"type":"integer","format":"int32","uniqueKey":"code","typeLabel":"integer\u003cint32>"},"message":{"type":"string","uniqueKey":"message","typeLabel":"string"},"details":{"type":"array","items":{"type":"object","properties":{"@type":{"type":"string","description":"A URL/resource name that uniquely identifies the type of the serialized\nprotocol buffer message. This string must contain at least\none \"/\" character. The last segment of the URL's path must represent\nthe fully qualified name of the type (as in\n`path/google.protobuf.Duration`). The name should be in a canonical form\n(e.g., leading \".\" is not accepted).\n\nIn practice, teams usually precompile into the binary all types that they\nexpect it to use in the context of Any. However, for URLs which use the\nscheme `http`, `https`, or no scheme, one can optionally set up a type\nserver that maps type URLs to message definitions as follows:\n\n* If no scheme is provided, `https` is assumed.\n* An HTTP GET on the URL must yield a [google.protobuf.Type][]\n value in binary format, or produce an error.\n* Applications are allowed to cache lookup results based on the\n URL, or have them precompiled into a binary to avoid any\n lookup. Therefore, binary compatibility needs to be preserved\n on changes to types. (Use versioned type names to manage\n breaking changes.)\n\nNote: this functionality is not currently available in the official\nprotobuf release, and it is not used for type URLs beginning with\ntype.googleapis.com. As of May 2023, there are no widely used type server\nimplementations and no plans to implement one.\n\nSchemes other than `http`, `https` (or the empty scheme) might be\nused with implementation specific semantics.","uniqueKey":"details.items.[INDEX].@type","typeLabel":"string"}},"additionalProperties":{"oneOf":[{}],"uniqueKey":"details.items.[INDEX].additionalProperties","typeLabel":"any"},"description":"`Any` contains an arbitrary serialized protocol buffer message along with a\nURL that describes the type of the serialized message.\n\nProtobuf library provides support to pack/unpack Any values in the form\nof utility functions or additional generated methods of the Any type.\n\nExample 1: Pack and unpack a message in C++.\n\n Foo foo = ...;\n Any any;\n any.PackFrom(foo);\n ...\n if (any.UnpackTo(\u0026foo)) {\n ...\n }\n\nExample 2: Pack and unpack a message in Java.\n\n Foo foo = ...;\n Any any = Any.pack(foo);\n ...\n if (any.is(Foo.class)) {\n foo = any.unpack(Foo.class);\n }\n // or ...\n if (any.isSameTypeAs(Foo.getDefaultInstance())) {\n foo = any.unpack(Foo.getDefaultInstance());\n }\n\n Example 3: Pack and unpack a message in Python.\n\n foo = Foo(...)\n any = Any()\n any.Pack(foo)\n ...\n if any.Is(Foo.DESCRIPTOR):\n any.Unpack(foo)\n ...\n\n Example 4: Pack and unpack a message in Go\n\n foo := \u0026pb.Foo{...}\n any, err := anypb.New(foo)\n if err != nil {\n ...\n }\n ...\n foo := \u0026pb.Foo{}\n if err := any.UnmarshalTo(foo); err != nil {\n ...\n }\n\nThe pack methods provided by protobuf library will by default use\n'type.googleapis.com/full.type.name' as the type URL and the unpack\nmethods only use the fully qualified type name after the last '/'\nin the type URL, for example \"foo.bar.com/x/y.z\" will yield type\nname \"y.z\".\n\nJSON\n====\nThe JSON representation of an `Any` value uses the regular\nrepresentation of the deserialized, embedded message, with an\nadditional field `@type` which contains the type URL. Example:\n\n package google.profile;\n message Person {\n string first_name = 1;\n string last_name = 2;\n }\n\n {\n \"@type\": \"type.googleapis.com/google.profile.Person\",\n \"firstName\": \u003cstring>,\n \"lastName\": \u003cstring>\n }\n\nIf the embedded message type is well-known and has a custom JSON\nrepresentation, that representation will be embedded adding a field\n`value` which holds the custom JSON in addition to the `@type`\nfield. Example (for message [google.protobuf.Duration][]):\n\n {\n \"@type\": \"type.googleapis.com/google.protobuf.Duration\",\n \"value\": \"1.212s\"\n }","uniqueKey":"details.items.[INDEX]","typeLabel":"object"},"uniqueKey":"details","typeLabel":"object[]"}},"uniqueKey":"","typeLabel":"object"},"examples":{"Example":{"title":"Example","value":{"code":123,"message":"\u003cstring>","details":[{"@type":"\u003cstring>"}]}}},"exampleType":"generated"}},"exampleType":"generated"}},"security":{},"servers":{"a9f8ae3b-0246-48ff-af65-1f5630d769c5":{"url":"https://cosmos-rest.publicnode.com","description":"Community-run public endpoint serving Cosmos Hub. Not operated by the Cosmos SDK team, and running a different SDK version than these pages document. Endpoints for modules the chain does not include return 501."},"f0b124ec-07c0-430c-9ffe-742b4568c32c":{"url":"http://localhost:1317","description":"Your own node. Requires api.enable in app.toml."}},"schemas":{"ecbcde82-fbe0-453e-a6d9-c5ef433f31ff":{"type":"object","properties":{"single":{"oneOf":[{"type":"object","title":"single represents a single signer","properties":{"mode":{"oneOf":[{"type":"string","title":"mode is the signing mode of the single signer","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2","default":"SIGN_MODE_UNSPECIFIED","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"]},{"type":"null","title":"mode is the signing mode of the single signer","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2","default":"SIGN_MODE_UNSPECIFIED","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"]}]}},"additionalProperties":false},{"type":"null","title":"single represents a single signer","properties":{"mode":{"oneOf":[{"type":"string","title":"mode is the signing mode of the single signer","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2","default":"SIGN_MODE_UNSPECIFIED","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"]},{"type":"null","title":"mode is the signing mode of the single signer","description":"SignMode represents a signing mode with its own security guarantees.\n\nThis enum should be considered a registry of all known sign modes\nin the Cosmos ecosystem. Apps are not expected to support all known\nsign modes. Apps that would like to support custom sign modes are\nencouraged to open a small PR against this file to add a new case\nto this SignMode enum describing their sign mode so that different\napps have a consistent version of this enum.\n\n - SIGN_MODE_UNSPECIFIED: SIGN_MODE_UNSPECIFIED specifies an unknown signing mode and will be\nrejected.\n - SIGN_MODE_DIRECT: SIGN_MODE_DIRECT specifies a signing mode which uses SignDoc and is\nverified with raw bytes from Tx.\n - SIGN_MODE_TEXTUAL: SIGN_MODE_TEXTUAL is a future signing mode that will verify some\nhuman-readable textual representation on top of the binary representation\nfrom SIGN_MODE_DIRECT.\n\nSince: cosmos-sdk 0.50\n - SIGN_MODE_DIRECT_AUX: SIGN_MODE_DIRECT_AUX specifies a signing mode which uses\nSignDocDirectAux. As opposed to SIGN_MODE_DIRECT, this sign mode does not\nrequire signers signing over other signers' `signer_info`.\n\nSince: cosmos-sdk 0.46\n - SIGN_MODE_LEGACY_AMINO_JSON: SIGN_MODE_LEGACY_AMINO_JSON is a backwards compatibility mode which uses\nAmino JSON and will be removed in the future.\n - SIGN_MODE_EIP_191: SIGN_MODE_EIP_191 specifies the sign mode for EIP 191 signing on the Cosmos\nSDK. Ref: https://eips.ethereum.org/EIPS/eip-191\n\nCurrently, SIGN_MODE_EIP_191 is registered as a SignMode enum variant,\nbut is not implemented on the SDK by default. To enable EIP-191, you need\nto pass a custom `TxConfig` that has an implementation of\n`SignModeHandler` for EIP-191. The SDK may decide to fully support\nEIP-191 in the future.\n\nSince: cosmos-sdk 0.45.2","default":"SIGN_MODE_UNSPECIFIED","enum":["SIGN_MODE_UNSPECIFIED","SIGN_MODE_DIRECT","SIGN_MODE_TEXTUAL","SIGN_MODE_DIRECT_AUX","SIGN_MODE_LEGACY_AMINO_JSON","SIGN_MODE_EIP_191"]}]}},"additionalProperties":false}]},"multi":{"oneOf":[{"type":"object","title":"multi represents a nested multisig signer","properties":{"bitarray":{"oneOf":[{"type":"object","title":"bitarray specifies which keys within the multisig are signing","description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"additionalProperties":false},{"type":"null","title":"bitarray specifies which keys within the multisig are signing","description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"oneOf":[{}]},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"additionalProperties":false},{"type":"null","title":"multi represents a nested multisig signer","properties":{"bitarray":{"oneOf":[{"type":"object","title":"bitarray specifies which keys within the multisig are signing","description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"additionalProperties":false},{"type":"null","title":"bitarray specifies which keys within the multisig are signing","description":"CompactBitArray is an implementation of a space efficient bit array.\nThis is used to ensure that the encoded data takes up a minimal amount of\nspace after proto encoding.\nThis is not thread safe, and is not intended for concurrent usage.","properties":{"extra_bits_stored":{"type":"integer","format":"int64"},"elems":{"oneOf":[{"type":"string","format":"byte"},{"type":"null","format":"byte"}]}},"additionalProperties":false}]},"mode_infos":{"oneOf":[{"type":"array","items":{"oneOf":[{}]},"title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"},{"type":"null","title":"mode_infos is the corresponding modes of the signers of the multisig\nwhich could include nested multisig public keys"}]}},"additionalProperties":false}]}},"description":"ModeInfo describes the signing mode of a single or nested multisig signer.","additionalProperties":false}}},"originalFileLocation":"sdk/next/api-reference/rest/openapi.yaml"},"subdomain":"cosmos-docs","siteName":"Cosmos Docs","title":"TxDecode - Cosmos Docs","navMaps":{"firstHrefInVersion":{"v0.55":{"href":"/sdk/latest/api-reference/rest/tx/txdecode","matchLevel":1},"next":{"href":"/sdk/next/api-reference/rest/tx/txdecode","matchLevel":0},"v0.54":{"href":"/sdk/v0.54/learn","matchLevel":4},"v0.53":{"href":"/sdk/v0.53/learn","matchLevel":4},"v0.50":{"href":"/sdk/v0.50/learn","matchLevel":4},"v0.47":{"href":"/sdk/v0.47/learn","matchLevel":4},"v0.7.0":{"href":"/evm/latest/documentation/overview","matchLevel":4},"v0.6.0":{"href":"/evm/v0.6.0/documentation/overview","matchLevel":4},"v0.5.0":{"href":"/evm/v0.5.0/documentation/overview","matchLevel":4},"v0.4.x":{"href":"/evm/v0.4.x/documentation/overview","matchLevel":4},"v0.40":{"href":"/cometbft/latest/docs/README","matchLevel":4},"v0.39":{"href":"/cometbft/v0.39/docs/README","matchLevel":4},"v0.38":{"href":"/cometbft/v0.38/docs/README","matchLevel":4},"v0.37":{"href":"/cometbft/v0.37/docs/README","matchLevel":4},"Latest":{"href":"/hub/latest","matchLevel":4},"v25":{"href":"/hub/v25/index","matchLevel":4}},"firstHrefInLanguage":{}},"lastModified":"2026-09-04T16:48:02.977Z","originalFileLocation":"sdk/next/api-reference/rest/tx/txdecode.mdx"},"headHtml":"\u003cscript data-mint-head>(function(){var d=document.documentElement,p=null;if(!p){try{p=localStorage.getItem(\"isDarkMode\")}catch(e){}if(p==='true')p='dark';else if(p==='false')p='light';if(p!=='light'\u0026\u0026p!=='dark'\u0026\u0026p!=='system')p=\"system\"}var r=p==='system'?(matchMedia(\"(prefers-color-scheme: dark)\").matches?'dark':'light'):p;d.classList.remove(r==='dark'?'light':'dark');d.classList.add(r);d.setAttribute(\"data-theme-preference\",p)})();\u003c/script>\u003cmeta data-mint-head name=\"description\" content=\"gRPC: cosmos.tx.v1beta1.Service/TxDecode (reference) TxDecode decodes the transaction.\">\u003cmeta data-mint-head name=\"application-name\" content=\"Cosmos Docs\">\u003cmeta data-mint-head name=\"generator\" content=\"Mintlify\">\u003clink data-mint-head rel=\"icon\" type=\"image/png\" sizes=\"192x192\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon/android-chrome-192x192.png\" media=\"(prefers-color-scheme: light)\">\u003clink data-mint-head rel=\"apple-touch-icon\" type=\"image/png\" sizes=\"180x180\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon/apple-touch-icon.png\">\u003clink data-mint-head rel=\"icon\" type=\"image/png\" sizes=\"16x16\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon/favicon-16x16.png\" media=\"(prefers-color-scheme: light)\">\u003clink data-mint-head rel=\"icon\" type=\"image/png\" sizes=\"32x32\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon/favicon-32x32.png\" media=\"(prefers-color-scheme: light)\">\u003clink data-mint-head rel=\"shortcut icon\" type=\"image/x-icon\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon/favicon.ico\" media=\"(prefers-color-scheme: light)\">\u003clink data-mint-head rel=\"icon\" type=\"image/png\" sizes=\"192x192\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon-dark/android-chrome-192x192.png\" media=\"(prefers-color-scheme: dark)\">\u003clink data-mint-head rel=\"icon\" type=\"image/png\" sizes=\"16x16\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon-dark/favicon-16x16.png\" media=\"(prefers-color-scheme: dark)\">\u003clink data-mint-head rel=\"icon\" type=\"image/png\" sizes=\"32x32\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon-dark/favicon-32x32.png\" media=\"(prefers-color-scheme: dark)\">\u003clink data-mint-head rel=\"shortcut icon\" type=\"image/x-icon\" href=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon-dark/favicon.ico\" media=\"(prefers-color-scheme: dark)\">\u003cmeta data-mint-head property=\"og:title\" content=\"TxDecode - Cosmos Docs\">\u003cmeta data-mint-head property=\"og:description\" content=\"Developer documentation for the Cosmos stack. Build secure, reliable, and high-performance blockchains.\">\u003cmeta data-mint-head property=\"og:site_name\" content=\"Cosmos Docs\">\u003cmeta data-mint-head property=\"og:url\" content=\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode\">\u003cmeta data-mint-head property=\"og:type\" content=\"website\">\u003cmeta data-mint-head property=\"og:image\" content=\"https://cosmos-docs.mintlify.app/_mintlify/api/og/v2?division=tx\u0026amp;title=TxDecode\u0026amp;description=gRPC%3A+%60cosmos.tx.v1beta1.Service%2FTxDecode%60+%28%5Breference%5D%28%2Fsdk%2Fnext%2Fapi-reference%2Fgrpc%2Ftx%23txdecode%29%29%0A%0ATxDecode+decodes+the+transaction.\u0026amp;theme=fcf436d6188c17e0fd925a75\u0026amp;signature=db4405d32fc88a3c59f7726ab273d35e022e2efe72c36b5a80bfee32bac3983b\">\u003cmeta data-mint-head property=\"og:image:width\" content=\"1200\">\u003cmeta data-mint-head property=\"og:image:height\" content=\"630\">\u003cmeta data-mint-head name=\"twitter:card\" content=\"summary_large_image\">\u003cmeta data-mint-head name=\"twitter:title\" content=\"TxDecode - Cosmos Docs\">\u003cmeta data-mint-head name=\"twitter:description\" content=\"Developer documentation for the Cosmos stack. Build secure, reliable, and high-performance blockchains.\">\u003cmeta data-mint-head name=\"twitter:image\" content=\"https://cosmos-docs.mintlify.app/_mintlify/api/og/v2?division=tx\u0026amp;title=TxDecode\u0026amp;description=gRPC%3A+%60cosmos.tx.v1beta1.Service%2FTxDecode%60+%28%5Breference%5D%28%2Fsdk%2Fnext%2Fapi-reference%2Fgrpc%2Ftx%23txdecode%29%29%0A%0ATxDecode+decodes+the+transaction.\u0026amp;theme=fcf436d6188c17e0fd925a75\u0026amp;signature=db4405d32fc88a3c59f7726ab273d35e022e2efe72c36b5a80bfee32bac3983b\">\u003cmeta data-mint-head name=\"twitter:image:width\" content=\"1200\">\u003cmeta data-mint-head name=\"twitter:image:height\" content=\"630\">\u003cmeta data-mint-head name=\"msapplication-config\" content=\"/mintlify-assets/_mintlify/favicons/cosmos-docs/48l-dIoPdyiiCW5H/_generated/favicon/browserconfig.xml\">\u003cmeta data-mint-head name=\"apple-mobile-web-app-title\" content=\"Cosmos Docs\">\u003cmeta data-mint-head name=\"msapplication-TileColor\" content=\"#000000\">\u003clink data-mint-head rel=\"canonical\" href=\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode\">\u003clink data-mint-head rel=\"alternate\" type=\"application/xml\" href=\"/sitemap.xml\">\u003clink data-mint-head rel=\"alternate\" type=\"text/markdown\" href=\"/sdk/next/api-reference/rest/tx/txdecode.md\">\u003cscript data-mint-head type=\"application/ld+json\">{\"@context\":\"https://schema.org\",\"@graph\":[{\"@type\":\"Organization\",\"@id\":\"https://docs.cosmos.network/#organization\",\"name\":\"Cosmos Docs\",\"url\":\"https://docs.cosmos.network\",\"logo\":{\"@type\":\"ImageObject\",\"url\":\"https://mintcdn.com/cosmos-docs/QQRcm34voxlHZJJD/assets/brand/cosmos-wordmark-dark.svg?fit=max\u0026auto=format\u0026n=QQRcm34voxlHZJJD\u0026q=85\u0026s=cd248dfba0e2e05e30786f2bb3f64fe9\"}},{\"@type\":\"WebSite\",\"@id\":\"https://docs.cosmos.network#website\",\"name\":\"Cosmos Docs\",\"url\":\"https://docs.cosmos.network\",\"publisher\":{\"@id\":\"https://docs.cosmos.network/#organization\"}},{\"@type\":\"WebPage\",\"@id\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode#webpage\",\"url\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode\",\"name\":\"TxDecode\",\"description\":\"gRPC: cosmos.tx.v1beta1.Service/TxDecode (reference) TxDecode decodes the transaction.\",\"dateModified\":\"2026-09-04T16:48:02.977Z\",\"isPartOf\":{\"@id\":\"https://docs.cosmos.network#website\"},\"breadcrumb\":{\"@id\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode#breadcrumb\"}},{\"@type\":\"BreadcrumbList\",\"@id\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"REST (gRPC Gateway)\",\"item\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/auth/accountinfo\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"TxDecode\",\"item\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode\"}]},{\"@type\":[\"TechArticle\",\"APIReference\"],\"@id\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode#apireference\",\"headline\":\"TxDecode\",\"name\":\"TxDecode\",\"description\":\"gRPC: cosmos.tx.v1beta1.Service/TxDecode (reference) TxDecode decodes the transaction.\",\"url\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode\",\"mainEntityOfPage\":{\"@id\":\"https://docs.cosmos.network/sdk/next/api-reference/rest/tx/txdecode#webpage\"},\"dateModified\":\"2026-09-04T16:48:02.977Z\",\"publisher\":{\"@id\":\"https://docs.cosmos.network/#organization\"},\"isPartOf\":{\"@id\":\"https://docs.cosmos.network#website\"}}]}\u003c/script>","siteName":"Cosmos Docs","nav":{"global":null,"dropdowns":[{"dropdown":"Home","pages":[{"title":"Cosmos Developer Documentation","mode":"custom","href":""}]},{"dropdown":"Cosmos SDK","icon":"https://mintlify.s3.us-west-1.amazonaws.com/cosmos-docs/assets/icons/cosmos-sdk.svg","versions":[{"version":"v0.55","default":true,"tag":"Latest","pages":[{"title":"v0.55","href":"/sdk/latest/api-reference/rest/tx/txdecode"}]},{"version":"next","tag":"Unreleased","tabs":[{"tab":"Cosmos SDK","pages":[{"title":"Cosmos SDK","href":"/sdk/next/learn"}]},{"tab":"Release Notes","pages":[{"title":"Release Notes","href":"/sdk/next/upgrade/v0.55-release"}]},{"tab":"API Reference","groups":[{"group":"Overview","pages":[{"title":"API Reference","href":"/sdk/next/api-reference"},{"title":"Sending Transactions","href":"/sdk/next/api-reference/transactions"}]},{"group":"gRPC Services","pages":[{"title":"gRPC Services","href":"/sdk/next/api-reference/grpc/index"},{"title":"Auth","href":"/sdk/next/api-reference/grpc/auth"},{"title":"Authz","href":"/sdk/next/api-reference/grpc/authz"},{"title":"Autocli","href":"/sdk/next/api-reference/grpc/autocli"},{"title":"Bank","href":"/sdk/next/api-reference/grpc/bank"},{"title":"Base","href":"/sdk/next/api-reference/grpc/base"},{"title":"Consensus","href":"/sdk/next/api-reference/grpc/consensus"},{"title":"Counter","href":"/sdk/next/api-reference/grpc/counter"},{"title":"Distribution","href":"/sdk/next/api-reference/grpc/distribution"},{"title":"Epochs","href":"/sdk/next/api-reference/grpc/epochs"},{"title":"Evidence","href":"/sdk/next/api-reference/grpc/evidence"},{"title":"Feegrant","href":"/sdk/next/api-reference/grpc/feegrant"},{"title":"Gov","href":"/sdk/next/api-reference/grpc/gov"},{"title":"Mint","href":"/sdk/next/api-reference/grpc/mint"},{"title":"Reflection","href":"/sdk/next/api-reference/grpc/reflection"},{"title":"Slashing","href":"/sdk/next/api-reference/grpc/slashing"},{"title":"Staking","href":"/sdk/next/api-reference/grpc/staking"},{"title":"Store","href":"/sdk/next/api-reference/grpc/store"},{"title":"Tx","href":"/sdk/next/api-reference/grpc/tx"},{"title":"Upgrade","href":"/sdk/next/api-reference/grpc/upgrade"},{"title":"Vesting","href":"/sdk/next/api-reference/grpc/vesting"}]},{"group":"REST (gRPC Gateway)","pages":[{"group":"auth","pages":[{"title":"AccountInfo","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/account_info/{address}","href":"/sdk/next/api-reference/rest/auth/accountinfo"},{"title":"Accounts","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/accounts","href":"/sdk/next/api-reference/rest/auth/accounts"},{"title":"Account","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/accounts/{address}","href":"/sdk/next/api-reference/rest/auth/account"},{"title":"AccountAddressByID","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/address_by_id/{accountId}","href":"/sdk/next/api-reference/rest/auth/accountaddressbyid"},{"title":"Bech32Prefix","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/bech32","href":"/sdk/next/api-reference/rest/auth/bech32prefix"},{"title":"AddressBytesToString","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/bech32/{addressBytes}","href":"/sdk/next/api-reference/rest/auth/addressbytestostring"},{"title":"ModuleAccounts","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/module_accounts","href":"/sdk/next/api-reference/rest/auth/moduleaccounts"},{"title":"ModuleAccountByName","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/module_accounts/{name}","href":"/sdk/next/api-reference/rest/auth/moduleaccountbyname"},{"title":"Params","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/auth/v1beta1/params","href":"/sdk/next/api-reference/rest/auth/params"}]},{"group":"authz","pages":[{"title":"Grants","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/authz/v1beta1/grants","href":"/sdk/next/api-reference/rest/authz/grants"},{"title":"GranteeGrants","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/authz/v1beta1/grants/grantee/{grantee}","href":"/sdk/next/api-reference/rest/authz/granteegrants"},{"title":"GranterGrants","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/authz/v1beta1/grants/granter/{granter}","href":"/sdk/next/api-reference/rest/authz/grantergrants"}]},{"group":"bank","pages":[{"title":"AllBalances","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/balances/{address}","href":"/sdk/next/api-reference/rest/bank/allbalances"},{"title":"Balance","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/balances/{address}/by_denom","href":"/sdk/next/api-reference/rest/bank/balance"},{"title":"DenomOwners","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/denom_owners/{denom}","href":"/sdk/next/api-reference/rest/bank/denomowners"},{"title":"DenomOwnersByQuery","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/denom_owners_by_query","href":"/sdk/next/api-reference/rest/bank/denomownersbyquery"},{"title":"DenomsMetadata","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/denoms_metadata","href":"/sdk/next/api-reference/rest/bank/denomsmetadata"},{"title":"DenomMetadata","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/denoms_metadata/{denom}","href":"/sdk/next/api-reference/rest/bank/denommetadata"},{"title":"DenomMetadataByQueryString","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/denoms_metadata_by_query_string","href":"/sdk/next/api-reference/rest/bank/denommetadatabyquerystring"},{"title":"Params","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/params","href":"/sdk/next/api-reference/rest/bank/params"},{"title":"SendEnabled","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/send_enabled","href":"/sdk/next/api-reference/rest/bank/sendenabled"},{"title":"SpendableBalances","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/spendable_balances/{address}","href":"/sdk/next/api-reference/rest/bank/spendablebalances"},{"title":"SpendableBalanceByDenom","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/spendable_balances/{address}/by_denom","href":"/sdk/next/api-reference/rest/bank/spendablebalancebydenom"},{"title":"TotalSupply","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/supply","href":"/sdk/next/api-reference/rest/bank/totalsupply"},{"title":"SupplyOf","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/bank/v1beta1/supply/by_denom","href":"/sdk/next/api-reference/rest/bank/supplyof"}]},{"group":"base","pages":[{"title":"Config","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/node/v1beta1/config","href":"/sdk/next/api-reference/rest/base/config"},{"title":"Status","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/node/v1beta1/status","href":"/sdk/next/api-reference/rest/base/status"},{"title":"ABCIQuery","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/abci_query","href":"/sdk/next/api-reference/rest/base/abciquery"},{"title":"GetLatestBlockResults","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/block_results/latest","href":"/sdk/next/api-reference/rest/base/getlatestblockresults"},{"title":"GetBlockResults","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/block_results/{height}","href":"/sdk/next/api-reference/rest/base/getblockresults"},{"title":"GetLatestBlock","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/blocks/latest","href":"/sdk/next/api-reference/rest/base/getlatestblock"},{"title":"GetBlockByHeight","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/blocks/{height}","href":"/sdk/next/api-reference/rest/base/getblockbyheight"},{"title":"GetNodeInfo","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/node_info","href":"/sdk/next/api-reference/rest/base/getnodeinfo"},{"title":"GetSyncing","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/syncing","href":"/sdk/next/api-reference/rest/base/getsyncing"},{"title":"GetLatestValidatorSet","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/validatorsets/latest","href":"/sdk/next/api-reference/rest/base/getlatestvalidatorset"},{"title":"GetValidatorSetByHeight","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/base/tendermint/v1beta1/validatorsets/{height}","href":"/sdk/next/api-reference/rest/base/getvalidatorsetbyheight"}]},{"group":"consensus","pages":[{"title":"Params","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/consensus/v1/params","href":"/sdk/next/api-reference/rest/consensus/params"}]},{"group":"distribution","pages":[{"title":"CommunityPool","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/community_pool","href":"/sdk/next/api-reference/rest/distribution/communitypool"},{"title":"DelegationTotalRewards","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/delegators/{delegatorAddress}/rewards","href":"/sdk/next/api-reference/rest/distribution/delegationtotalrewards"},{"title":"DelegationRewards","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/delegators/{delegatorAddress}/rewards/{validatorAddress}","href":"/sdk/next/api-reference/rest/distribution/delegationrewards"},{"title":"DelegatorStartingInfo","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/delegators/{delegatorAddress}/starting_info/{validatorAddress}","href":"/sdk/next/api-reference/rest/distribution/delegatorstartinginfo"},{"title":"DelegatorValidators","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/delegators/{delegatorAddress}/validators","href":"/sdk/next/api-reference/rest/distribution/delegatorvalidators"},{"title":"DelegatorWithdrawAddress","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/delegators/{delegatorAddress}/withdraw_address","href":"/sdk/next/api-reference/rest/distribution/delegatorwithdrawaddress"},{"title":"Params","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/params","href":"/sdk/next/api-reference/rest/distribution/params"},{"title":"ValidatorDistributionInfo","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/validators/{validatorAddress}","href":"/sdk/next/api-reference/rest/distribution/validatordistributioninfo"},{"title":"ValidatorCommission","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/validators/{validatorAddress}/commission","href":"/sdk/next/api-reference/rest/distribution/validatorcommission"},{"title":"ValidatorCurrentRewards","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/validators/{validatorAddress}/current_rewards","href":"/sdk/next/api-reference/rest/distribution/validatorcurrentrewards"},{"title":"ValidatorHistoricalRewards","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/validators/{validatorAddress}/historical_rewards/{period}","href":"/sdk/next/api-reference/rest/distribution/validatorhistoricalrewards"},{"title":"ValidatorOutstandingRewards","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/validators/{validatorAddress}/outstanding_rewards","href":"/sdk/next/api-reference/rest/distribution/validatoroutstandingrewards"},{"title":"ValidatorSlashes","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/distribution/v1beta1/validators/{validatorAddress}/slashes","href":"/sdk/next/api-reference/rest/distribution/validatorslashes"}]},{"group":"epochs","pages":[{"title":"CurrentEpoch","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/epochs/v1beta1/current_epoch","href":"/sdk/next/api-reference/rest/epochs/currentepoch"},{"title":"EpochInfos","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/epochs/v1beta1/epochs","href":"/sdk/next/api-reference/rest/epochs/epochinfos"}]},{"group":"evidence","pages":[{"title":"AllEvidence","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/evidence/v1beta1/evidence","href":"/sdk/next/api-reference/rest/evidence/allevidence"},{"title":"Evidence","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/evidence/v1beta1/evidence/{hash}","href":"/sdk/next/api-reference/rest/evidence/evidence"}]},{"group":"feegrant","pages":[{"title":"Allowance","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/feegrant/v1beta1/allowance/{granter}/{grantee}","href":"/sdk/next/api-reference/rest/feegrant/allowance"},{"title":"Allowances","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/feegrant/v1beta1/allowances/{grantee}","href":"/sdk/next/api-reference/rest/feegrant/allowances"},{"title":"AllowancesByGranter","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/feegrant/v1beta1/issued/{granter}","href":"/sdk/next/api-reference/rest/feegrant/allowancesbygranter"}]},{"group":"gov","pages":[{"title":"Constitution","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/constitution","href":"/sdk/next/api-reference/rest/gov/constitution"},{"title":"Params (v1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/params/{paramsType}","href":"/sdk/next/api-reference/rest/gov/params-v1"},{"title":"Proposals (v1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/proposals","href":"/sdk/next/api-reference/rest/gov/proposals-v1"},{"title":"Proposal (v1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/proposals/{proposalId}","href":"/sdk/next/api-reference/rest/gov/proposal-v1"},{"title":"Deposits (v1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/proposals/{proposalId}/deposits","href":"/sdk/next/api-reference/rest/gov/deposits-v1"},{"title":"Deposit (Query, v1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/proposals/{proposalId}/deposits/{depositor}","href":"/sdk/next/api-reference/rest/gov/deposit-query-v1"},{"title":"TallyResult (v1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/proposals/{proposalId}/tally","href":"/sdk/next/api-reference/rest/gov/tallyresult-v1"},{"title":"Votes (v1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/proposals/{proposalId}/votes","href":"/sdk/next/api-reference/rest/gov/votes-v1"},{"title":"Vote (Query, v1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1/proposals/{proposalId}/votes/{voter}","href":"/sdk/next/api-reference/rest/gov/vote-query-v1"},{"title":"Params (v1beta1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1beta1/params/{paramsType}","href":"/sdk/next/api-reference/rest/gov/params-v1beta1"},{"title":"Proposals (v1beta1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1beta1/proposals","href":"/sdk/next/api-reference/rest/gov/proposals-v1beta1"},{"title":"Proposal (v1beta1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1beta1/proposals/{proposalId}","href":"/sdk/next/api-reference/rest/gov/proposal-v1beta1"},{"title":"Deposits (v1beta1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1beta1/proposals/{proposalId}/deposits","href":"/sdk/next/api-reference/rest/gov/deposits-v1beta1"},{"title":"Deposit (Query, v1beta1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1beta1/proposals/{proposalId}/deposits/{depositor}","href":"/sdk/next/api-reference/rest/gov/deposit-query-v1beta1"},{"title":"TallyResult (v1beta1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1beta1/proposals/{proposalId}/tally","href":"/sdk/next/api-reference/rest/gov/tallyresult-v1beta1"},{"title":"Votes (v1beta1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1beta1/proposals/{proposalId}/votes","href":"/sdk/next/api-reference/rest/gov/votes-v1beta1"},{"title":"Vote (Query, v1beta1)","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/gov/v1beta1/proposals/{proposalId}/votes/{voter}","href":"/sdk/next/api-reference/rest/gov/vote-query-v1beta1"}]},{"group":"mint","pages":[{"title":"AnnualProvisions","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/mint/v1beta1/annual_provisions","href":"/sdk/next/api-reference/rest/mint/annualprovisions"},{"title":"Inflation","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/mint/v1beta1/inflation","href":"/sdk/next/api-reference/rest/mint/inflation"},{"title":"Params","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/mint/v1beta1/params","href":"/sdk/next/api-reference/rest/mint/params"}]},{"group":"slashing","pages":[{"title":"Params","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/slashing/v1beta1/params","href":"/sdk/next/api-reference/rest/slashing/params"},{"title":"SigningInfos","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/slashing/v1beta1/signing_infos","href":"/sdk/next/api-reference/rest/slashing/signinginfos"},{"title":"SigningInfo","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/slashing/v1beta1/signing_infos/{consAddress}","href":"/sdk/next/api-reference/rest/slashing/signinginfo"}]},{"group":"staking","pages":[{"title":"DelegatorDelegations","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/delegations/{delegatorAddr}","href":"/sdk/next/api-reference/rest/staking/delegatordelegations"},{"title":"Redelegations","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/delegators/{delegatorAddr}/redelegations","href":"/sdk/next/api-reference/rest/staking/redelegations"},{"title":"DelegatorUnbondingDelegations","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/delegators/{delegatorAddr}/unbonding_delegations","href":"/sdk/next/api-reference/rest/staking/delegatorunbondingdelegations"},{"title":"DelegatorValidators","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/delegators/{delegatorAddr}/validators","href":"/sdk/next/api-reference/rest/staking/delegatorvalidators"},{"title":"DelegatorValidator","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/delegators/{delegatorAddr}/validators/{validatorAddr}","href":"/sdk/next/api-reference/rest/staking/delegatorvalidator"},{"title":"HistoricalInfo","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/historical_info/{height}","href":"/sdk/next/api-reference/rest/staking/historicalinfo"},{"title":"Params","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/params","href":"/sdk/next/api-reference/rest/staking/params"},{"title":"Pool","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/pool","href":"/sdk/next/api-reference/rest/staking/pool"},{"title":"Validators","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/validators","href":"/sdk/next/api-reference/rest/staking/validators"},{"title":"Validator","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/validators/{validatorAddr}","href":"/sdk/next/api-reference/rest/staking/validator"},{"title":"ValidatorDelegations","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/validators/{validatorAddr}/delegations","href":"/sdk/next/api-reference/rest/staking/validatordelegations"},{"title":"Delegation","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/validators/{validatorAddr}/delegations/{delegatorAddr}","href":"/sdk/next/api-reference/rest/staking/delegation"},{"title":"UnbondingDelegation","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/validators/{validatorAddr}/delegations/{delegatorAddr}/unbonding_delegation","href":"/sdk/next/api-reference/rest/staking/unbondingdelegation"},{"title":"ValidatorUnbondingDelegations","description":"gRPC: `cosmos.staking.v1beta1.Query/ValidatorUnbondingDelegations` ([reference](/sdk/next/api-reference/grpc/staking#validatorunbondingdelegations))\n\nValidatorUnbondingDelegations queries unbonding delegations of a validator.\n\nWhen called from another module, this query might consume a high amount of\ngas if the pagination field is incorrectly set.","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/staking/v1beta1/validators/{validatorAddr}/unbonding_delegations","href":"/sdk/next/api-reference/rest/staking/validatorunbondingdelegations"}]},{"group":"tx","pages":[{"title":"TxDecode","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml post /cosmos/tx/v1beta1/decode","href":"/sdk/next/api-reference/rest/tx/txdecode"},{"title":"TxDecodeAmino","description":"gRPC: `cosmos.tx.v1beta1.Service/TxDecodeAmino` ([reference](/sdk/next/api-reference/grpc/tx#txdecodeamino))\n\nTxDecodeAmino decodes an Amino transaction from encoded bytes to JSON.","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml post /cosmos/tx/v1beta1/decode/amino","href":"/sdk/next/api-reference/rest/tx/txdecodeamino"},{"title":"TxEncode","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml post /cosmos/tx/v1beta1/encode","href":"/sdk/next/api-reference/rest/tx/txencode"},{"title":"TxEncodeAmino","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml post /cosmos/tx/v1beta1/encode/amino","href":"/sdk/next/api-reference/rest/tx/txencodeamino"},{"title":"Simulate","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml post /cosmos/tx/v1beta1/simulate","href":"/sdk/next/api-reference/rest/tx/simulate"},{"title":"GetTxsEvent","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/tx/v1beta1/txs","href":"/sdk/next/api-reference/rest/tx/gettxsevent"},{"title":"BroadcastTx","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml post /cosmos/tx/v1beta1/txs","href":"/sdk/next/api-reference/rest/tx/broadcasttx"},{"title":"GetBlockWithTxs","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/tx/v1beta1/txs/block/{height}","href":"/sdk/next/api-reference/rest/tx/getblockwithtxs"},{"title":"GetTx","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/tx/v1beta1/txs/{hash}","href":"/sdk/next/api-reference/rest/tx/gettx"}]},{"group":"upgrade","pages":[{"title":"AppliedPlan","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/upgrade/v1beta1/applied_plan/{name}","href":"/sdk/next/api-reference/rest/upgrade/appliedplan"},{"title":"Authority","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/upgrade/v1beta1/authority","href":"/sdk/next/api-reference/rest/upgrade/authority"},{"title":"CurrentPlan","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/upgrade/v1beta1/current_plan","href":"/sdk/next/api-reference/rest/upgrade/currentplan"},{"title":"ModuleVersions","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/upgrade/v1beta1/module_versions","href":"/sdk/next/api-reference/rest/upgrade/moduleversions"},{"title":"UpgradedConsensusState","deprecated":null,"version":null,"openapi":"/sdk/next/api-reference/rest/openapi.yaml get /cosmos/upgrade/v1beta1/upgraded_consensus_state/{lastHeight}","href":"/sdk/next/api-reference/rest/upgrade/upgradedconsensusstate"}]}]}]}]},{"version":"v0.54","pages":[{"title":"v0.54","href":"/sdk/v0.54/learn"}]},{"version":"v0.53","pages":[{"title":"v0.53","href":"/sdk/v0.53/learn"}]},{"version":"v0.50","pages":[{"title":"v0.50","href":"/sdk/v0.50/learn"}]},{"version":"v0.47","pages":[{"title":"v0.47","href":"/sdk/v0.47/learn"}]}]},{"dropdown":"Cosmos EVM","icon":"https://mintlify.s3.us-west-1.amazonaws.com/cosmos-docs/assets/icons/cosmos-evm.svg","versions":[{"version":"v0.7.0","default":true,"tag":"Latest","pages":[{"title":"v0.7.0","href":"/evm/latest/documentation/overview"}]},{"version":"next","tag":"Unreleased","tabs":[{"tab":"Documentation","groups":[{"group":"About","pages":[{"title":"Overview","href":"/evm/next/documentation/overview"},{"title":"EVM Compatibility","href":"/evm/next/documentation/evm-compatibility"},{"title":"Frequently Asked Questions","href":"/evm/next/documentation/getting-started/faq"}]},{"group":"Build","pages":[{"title":"Run an EVM Chain","href":"/evm/next/documentation/getting-started/build-a-chain/quick-start"},{"group":"Additional Configuration","expanded":true,"pages":[{"title":"Mempool Configuration","href":"/evm/next/documentation/getting-started/build-a-chain/additional-configuration/mempool-integration"},{"title":"Predeployed Contracts","href":"/evm/next/documentation/getting-started/build-a-chain/additional-configuration/predeployed-contracts"},{"title":"Precompile Configuration","href":"/evm/next/documentation/getting-started/build-a-chain/additional-configuration/precompiles"},{"title":"Node Configuration","mode":"wide","href":"/evm/next/documentation/getting-started/network-operators/node-configuration"}]},{"title":"Tooling \u0026 Resources","href":"/evm/next/documentation/getting-started/tooling-and-resources"}]},{"group":"Learn","pages":[{"group":"Concepts","pages":[{"title":"Overview","icon":"microchip","href":"/evm/next/documentation/concepts/overview"},{"title":"Accounts","icon":"wallet","href":"/evm/next/documentation/concepts/accounts"},{"title":"Chain ID","icon":"fingerprint","href":"/evm/next/documentation/concepts/chain-id"},{"title":"Encoding","icon":"binary","href":"/evm/next/documentation/concepts/encoding"},{"title":"Gas and Fees","icon":"fuel","href":"/evm/next/documentation/concepts/gas-and-fees"},{"title":"IBC","icon":"network","href":"/evm/next/documentation/concepts/ibc"},{"title":"Mempool","icon":"layers","href":"/evm/next/documentation/concepts/mempool"},{"title":"State Export/Import","icon":"git-branch","href":"/evm/next/documentation/concepts/migrations"},{"title":"Pending State","icon":"hourglass","href":"/evm/next/documentation/concepts/pending-state"},{"title":"EIP-155: Replay Protection","icon":"shield","href":"/evm/next/documentation/concepts/replay-protection"},{"title":"Signing","icon":"pen-tool","href":"/evm/next/documentation/concepts/signing"},{"title":"Single Token Representation","icon":"coins","href":"/evm/next/documentation/concepts/single-token-representation"},{"title":"Tokens","icon":"coins","href":"/evm/next/documentation/concepts/tokens"},{"title":"Transactions","icon":"arrow-up-down","href":"/evm/next/documentation/concepts/transactions"},{"title":"EIP-1559 Fee Market","icon":"chart-line","href":"/evm/next/documentation/concepts/eip-1559-feemarket"}]},{"group":"Precompiles","pages":[{"title":"Overview","icon":"code","href":"/evm/next/documentation/smart-contracts/precompiles/overview"},{"title":"Bank","icon":"vault","href":"/evm/next/documentation/smart-contracts/precompiles/bank"},{"title":"Bech32","icon":"binary","href":"/evm/next/documentation/smart-contracts/precompiles/bech32"},{"title":"Callbacks","icon":"webhook","href":"/evm/next/documentation/smart-contracts/precompiles/callbacks"},{"title":"Distribution","icon":"coins","href":"/evm/next/documentation/smart-contracts/precompiles/distribution"},{"title":"ERC20","icon":"refresh-cw","href":"/evm/next/documentation/smart-contracts/precompiles/erc20"},{"title":"Governance","icon":"scale","href":"/evm/next/documentation/smart-contracts/precompiles/governance"},{"title":"ICS20","icon":"chevrons-left-right-ellipsis","href":"/evm/next/documentation/smart-contracts/precompiles/ics20"},{"title":"P256","icon":"shield-check","href":"/evm/next/documentation/smart-contracts/precompiles/p256"},{"title":"Slashing","icon":"gavel","href":"/evm/next/documentation/smart-contracts/precompiles/slashing"},{"title":"Staking","icon":"coins","href":"/evm/next/documentation/smart-contracts/precompiles/staking"},{"title":"WERC20","icon":"refresh-ccw","href":"/evm/next/documentation/smart-contracts/precompiles/werc20"}]},{"group":"Cosmos SDK","pages":[{"title":"Overview","mode":"wide","href":"/evm/next/documentation/cosmos-sdk/overview"},{"title":"Command Line Interface (CLI)","href":"/evm/next/documentation/cosmos-sdk/cli"},{"title":"Technical Architecture","href":"/evm/next/documentation/cosmos-sdk/protocol"},{"group":"Modules","pages":[{"title":"ERC20","href":"/evm/next/documentation/cosmos-sdk/modules/erc20"},{"title":"Fee Market","href":"/evm/next/documentation/cosmos-sdk/modules/feemarket"},{"title":"IBC","href":"/evm/next/documentation/cosmos-sdk/modules/ibc"},{"title":"PreciseBank","href":"/evm/next/documentation/cosmos-sdk/modules/precisebank"},{"title":"VM","href":"/evm/next/documentation/cosmos-sdk/modules/vm"}]}]}]},{"group":"Migrations","pages":[{"title":"Migration: v0.6.0 to v0.7.0","href":"/evm/next/documentation/migrations/migration-v0.6-to-v0.7"},{"title":"Migrating off x/precisebank: Gas Converter Precompile","href":"/evm/next/documentation/migrations/gas-converter-migration"},{"group":"Previous Versions","pages":[{"title":"Migration: v0.5.0 to v0.6.0","href":"/evm/next/documentation/migrations/migration-v0.5-to-v0.6"},{"title":"Migration: v0.4.x to v0.5.0","href":"/evm/next/documentation/migrations/migration-v0.4-to-v0.5"},{"title":"Migration: v0.3.0 to v0.4.0","href":"/evm/next/documentation/migrations/migration-v0.3-to-v0.4"},{"title":"ERC20 Precompiles Migration","href":"/evm/next/documentation/migrations/erc20-precompiles-migration"}]},{"group":"Advanced","pages":[{"title":"Upgrade Handlers","href":"/evm/next/documentation/migrations/upgrade-handlers"},{"title":"Custom Improvement Proposals","href":"/evm/next/documentation/custom-improvement-proposals"},{"title":"Adding EVM to an Existing Chain","href":"/evm/next/documentation/migrations/add-evm-to-existing-chain"}]}]}]},{"tab":"API Reference","pages":[{"title":"Ethereum JSON-RPC","href":"/evm/next/api-reference/ethereum-json-rpc/index"},{"title":"Methods","href":"/evm/next/api-reference/ethereum-json-rpc/methods"},{"title":"JSON-RPC Explorer","mode":"custom","href":"/evm/next/api-reference/ethereum-json-rpc/rpc-explorer"}]},{"tab":"Changelog","pages":[{"title":"Changelog","mode":"wide","href":"/evm/next/changelog/release-notes"}]}]},{"version":"v0.6.0","pages":[{"title":"v0.6.0","href":"/evm/v0.6.0/documentation/overview"}]},{"version":"v0.5.0","pages":[{"title":"v0.5.0","href":"/evm/v0.5.0/documentation/overview"}]},{"version":"v0.4.x","pages":[{"title":"v0.4.x","href":"/evm/v0.4.x/documentation/overview"}]}]},{"dropdown":"CometBFT","icon":"https://mintlify.s3.us-west-1.amazonaws.com/cosmos-docs/assets/icons/comet-bft.svg","versions":[{"version":"v0.40","default":true,"tag":"Latest","pages":[{"title":"v0.40","href":"/cometbft/latest/docs/README"}]},{"version":"next","tag":"Unreleased","tabs":[{"tab":"Learn","groups":[{"group":"CometBFT","pages":[{"title":"CometBFT Documentation","href":"/cometbft/next/docs/README"},{"title":null,"href":"/cometbft/next/docs/introduction/intro"},{"group":"Guides","pages":[{"title":"Quick Start","href":"/cometbft/next/docs/guides/Quick-Start"},{"title":"Install CometBFT","href":"/cometbft/next/docs/guides/Install-CometBFT"},{"title":"Creating an application in Go","href":"/cometbft/next/docs/guides/Creating-an-application-in-Go"},{"title":"Creating a built-in application in Go","href":"/cometbft/next/docs/guides/Creating-a-built-in-application-in-Go"}]},{"group":"Apps","pages":[{"title":"Getting Started","href":"/cometbft/next/docs/app-dev/Getting-Started"},{"title":"Application Architecture Guide","href":"/cometbft/next/docs/app-dev/Application-Architecture-Guide"},{"title":"Using ABCI-CLI","href":"/cometbft/next/docs/app-dev/Using-ABCI-CLI"},{"title":"Indexing Transactions","href":"/cometbft/next/docs/app-dev/Indexing-Transactions"}]},{"group":"Core","pages":[{"title":"Using CometBFT","href":"/cometbft/next/docs/core/Using-CometBFT"},{"title":"Running in production","href":"/cometbft/next/docs/core/Running-in-production"},{"title":"Configuration","href":"/cometbft/next/docs/core/configuration"},{"title":"Mempool","href":"/cometbft/next/docs/core/mempool"},{"title":"Block Sync","href":"/cometbft/next/docs/core/block-sync"},{"title":"State Sync","href":"/cometbft/next/docs/core/state-sync"},{"title":"RPC","href":"/cometbft/next/docs/core/RPC"},{"title":"Subscribing to events via Websocket","href":"/cometbft/next/docs/core/Subscribing-to-events-via-Websocket"},{"title":"Metrics","href":"/cometbft/next/docs/core/metrics"},{"title":"Validators","href":"/cometbft/next/docs/core/Validators"},{"title":"Light Client","href":"/cometbft/next/docs/core/light-client"},{"title":"Block Structure","href":"/cometbft/next/docs/core/block-structure"},{"title":"How to read logs","href":"/cometbft/next/docs/core/how-to-read-logs"},{"group":"Experimental","pages":[{"title":"Lib-P2P Networking","icon":"waypoints","href":"/cometbft/next/docs/experimental/lib-p2p"}]}]},{"group":"Developer Tools","pages":[{"title":"Overview","href":"/cometbft/next/docs/tools/Overview"},{"title":"Debugging","href":"/cometbft/next/docs/tools/debugging"}]},{"group":"Networks","pages":[{"title":"Docker Compose","href":"/cometbft/next/docs/networks/Docker-Compose"}]},{"group":"CometBFT Quality Assurance","pages":[{"title":"CometBFT Quality Assurance","href":"/cometbft/next/docs/qa/CometBFT-qa"},{"title":"Method","href":"/cometbft/next/docs/qa/Method"},{"title":null,"href":"/cometbft/next/docs/qa/CometBFT-QA-38"},{"title":null,"href":"/cometbft/next/docs/qa/CometBFT-QA-37"},{"title":null,"href":"/cometbft/next/docs/qa/CometBFT-QA-34"},{"title":null,"href":"/cometbft/next/docs/qa/TMCore-QA-37"},{"title":null,"href":"/cometbft/next/docs/qa/TMCore-QA-34"}]}]}]},{"tab":"Specification","groups":[{"group":"CometBFT Spec","pages":[{"title":"Overview","href":"/cometbft/next/spec/CometBFT-Spec"},{"group":"Core","pages":[{"title":null,"href":"/cometbft/next/spec/core/Overview"},{"title":"Data Structures","href":"/cometbft/next/spec/core/Data_structures"},{"title":"Encoding","href":"/cometbft/next/spec/core/encoding"},{"title":"Genesis","href":"/cometbft/next/spec/core/genesis"},{"title":"State","href":"/cometbft/next/spec/core/state"}]},{"group":"ABCI++","pages":[{"title":null,"href":"/cometbft/next/spec/abci/Overview"},{"title":"Overview and basic concepts","href":"/cometbft/next/spec/abci/Outline"},{"title":"Methods","href":"/cometbft/next/spec/abci/Methods"},{"title":"Requirements for the Application","href":"/cometbft/next/spec/abci/Requirements-for-the-Application"},{"title":"CometBFT's expected behavior","href":"/cometbft/next/spec/abci/CometBFTs-expected-behavior"},{"title":"Client and Server","href":"/cometbft/next/spec/abci/Client-and-server"},{"title":"ABCI++ extra","href":"/cometbft/next/spec/abci/Introduction"}]},{"group":"Consensus","pages":[{"title":null,"href":"/cometbft/next/spec/consensus/Overview"},{"title":"Consensus Paper","href":"/cometbft/next/spec/consensus/Consensus-Paper"},{"title":"Byzantine Consensus Algorithm","href":"/cometbft/next/spec/consensus/Byzantine-Consensus-Algorithm"},{"title":null,"href":"/cometbft/next/spec/consensus/Light-Client"},{"title":"Creating a proposal","href":"/cometbft/next/spec/consensus/Creating-Proposal"},{"title":"BFT Time","href":"/cometbft/next/spec/consensus/BFT-Time"},{"title":null,"href":"/cometbft/next/spec/consensus/Proposer-Selection"},{"title":"Evidence","href":"/cometbft/next/spec/consensus/Evidence"},{"title":"Validator Signing","href":"/cometbft/next/spec/consensus/Validator-Signing"},{"title":"WAL","href":"/cometbft/next/spec/consensus/WAL"}]},{"group":"Light Client","pages":[{"title":"Light Client Specification","href":"/cometbft/next/spec/light-client/Light-Client-Specification"},{"title":null,"href":"/cometbft/next/spec/light-client/verification"},{"title":null,"href":"/cometbft/next/spec/light-client/Fork-Detection"},{"title":null,"href":"/cometbft/next/spec/light-client/Accountability"}]},{"group":"P2P","pages":[{"title":null,"href":"/cometbft/next/spec/p2p/Peer-to-Peer"},{"title":"Implementation","href":"/cometbft/next/spec/p2p/Implementation-of-the-p2p-layer"},{"group":"Legacy Docs","pages":[{"title":"Legacy Docs","href":"/cometbft/next/spec/p2p/legacy-docs/Overview"},{"group":"Messages","pages":[{"title":null,"href":"/cometbft/next/spec/p2p/legacy-docs/messages/Overview"},{"title":"Block Sync","href":"/cometbft/next/spec/p2p/legacy-docs/messages/block-sync"},{"title":"Evidence","href":"/cometbft/next/spec/p2p/legacy-docs/messages/evidence"},{"title":"Mempool","href":"/cometbft/next/spec/p2p/legacy-docs/messages/mempool"},{"title":"State Sync","href":"/cometbft/next/spec/p2p/legacy-docs/messages/state-sync"},{"title":"Peer Exchange","href":"/cometbft/next/spec/p2p/legacy-docs/messages/Peer-Exchange"},{"title":"Consensus","href":"/cometbft/next/spec/p2p/legacy-docs/messages/consensus"}]},{"title":"P2P Multiplex Connection","href":"/cometbft/next/spec/p2p/legacy-docs/P2P-Multiplex-Connection"},{"title":"Peers","href":"/cometbft/next/spec/p2p/legacy-docs/Peers"},{"title":"P2P Config","href":"/cometbft/next/spec/p2p/legacy-docs/P2P-Config"},{"title":"Peer Discovery","href":"/cometbft/next/spec/p2p/legacy-docs/Peer-Discovery"},{"group":"Reactors","pages":[{"title":"Reactors","href":"/cometbft/next/spec/p2p/reactor-api/Reactors"},{"title":"Reactor API","href":"/cometbft/next/spec/p2p/reactor-api/Reactor-Api"},{"title":"API for Reactors","href":"/cometbft/next/spec/p2p/reactor-api/API-for-Reactors"}]}]}]},{"group":"RPC","pages":[{"title":"RPC spec","href":"/cometbft/next/spec/rpc/Rpc-Spe"}]},{"group":"Blockchain","pages":[{"title":"Blockchain","href":"/cometbft/next/spec/blockchain/Blockchain"}]}]}]},{"tab":"API Reference","groups":[{"group":"Overview","pages":[{"title":"CometBFT RPC","href":"/cometbft/next/api-reference/rpc/index"}]},{"group":"RPC Methods","pages":[{"group":"Tx","pages":[{"title":"broadcast_tx_sync","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /broadcast_tx_sync","href":"/cometbft/next/api-reference/rpc/tx/broadcast_tx_sync"},{"title":"broadcast_tx_async","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /broadcast_tx_async","href":"/cometbft/next/api-reference/rpc/tx/broadcast_tx_async"},{"title":"broadcast_tx_commit","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /broadcast_tx_commit","href":"/cometbft/next/api-reference/rpc/tx/broadcast_tx_commit"},{"title":"check_tx","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /check_tx","href":"/cometbft/next/api-reference/rpc/tx/check_tx"}]},{"group":"Info","pages":[{"title":"health","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /health","href":"/cometbft/next/api-reference/rpc/info/health"},{"title":"status","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /status","href":"/cometbft/next/api-reference/rpc/info/status"},{"title":"net_info","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /net_info","href":"/cometbft/next/api-reference/rpc/info/net_info"},{"title":"blockchain","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /blockchain","href":"/cometbft/next/api-reference/rpc/info/blockchain"},{"title":"header","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /header","href":"/cometbft/next/api-reference/rpc/info/header"},{"title":"header_by_hash","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /header_by_hash","href":"/cometbft/next/api-reference/rpc/info/header_by_hash"},{"title":"block","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /block","href":"/cometbft/next/api-reference/rpc/info/block"},{"title":"block_by_hash","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /block_by_hash","href":"/cometbft/next/api-reference/rpc/info/block_by_hash"},{"title":"block_results","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /block_results","href":"/cometbft/next/api-reference/rpc/info/block_results"},{"title":"commit","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /commit","href":"/cometbft/next/api-reference/rpc/info/commit"},{"title":"validators","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /validators","href":"/cometbft/next/api-reference/rpc/info/validators"},{"title":"genesis","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /genesis","href":"/cometbft/next/api-reference/rpc/info/genesis"},{"title":"genesis_chunked","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /genesis_chunked","href":"/cometbft/next/api-reference/rpc/info/genesis_chunked"},{"title":"dump_consensus_state","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /dump_consensus_state","href":"/cometbft/next/api-reference/rpc/info/dump_consensus_state"},{"title":"consensus_state","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /consensus_state","href":"/cometbft/next/api-reference/rpc/info/consensus_state"},{"title":"consensus_params","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /consensus_params","href":"/cometbft/next/api-reference/rpc/info/consensus_params"},{"title":"unconfirmed_txs","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /unconfirmed_txs","href":"/cometbft/next/api-reference/rpc/info/unconfirmed_txs"},{"title":"num_unconfirmed_txs","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /num_unconfirmed_txs","href":"/cometbft/next/api-reference/rpc/info/num_unconfirmed_txs"},{"title":"tx_search","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /tx_search","href":"/cometbft/next/api-reference/rpc/info/tx_search"},{"title":"block_search","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /block_search","href":"/cometbft/next/api-reference/rpc/info/block_search"},{"title":"tx","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /tx","href":"/cometbft/next/api-reference/rpc/info/tx"},{"title":"broadcast_evidence","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /broadcast_evidence","href":"/cometbft/next/api-reference/rpc/info/broadcast_evidence"}]},{"group":"Unsafe","pages":[{"title":"dial_seeds","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /dial_seeds","href":"/cometbft/next/api-reference/rpc/unsafe/dial_seeds"},{"title":"dial_peers","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /dial_peers","href":"/cometbft/next/api-reference/rpc/unsafe/dial_peers"}]},{"group":"ABCI","pages":[{"title":"abci_info","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /abci_info","href":"/cometbft/next/api-reference/rpc/abci/abci_info"},{"title":"abci_query","deprecated":null,"version":null,"openapi":"/cometbft/next/api-reference/rpc/openapi.yaml get /abci_query","href":"/cometbft/next/api-reference/rpc/abci/abci_query"}]}]}]},{"tab":"Changelog","pages":[{"title":"Changelog","mode":"wide","href":"/cometbft/next/changelog/release-notes"}]}]},{"version":"v0.39","pages":[{"title":"v0.39","href":"/cometbft/v0.39/docs/README"}]},{"version":"v0.38","pages":[{"title":"v0.38","href":"/cometbft/v0.38/docs/README"}]},{"version":"v0.37","pages":[{"title":"v0.37","href":"/cometbft/v0.37/docs/README"}]}]},{"dropdown":"Skip Go","icon":"https://mintlify.s3.us-west-1.amazonaws.com/cosmos-docs/assets/icons/skip-go.svg","hidden":false,"tabs":[{"tab":"Documentation","groups":[{"group":"General API Docs","pages":[{"title":"Introduction","href":"/skip-go/general/getting-started"},{"title":"Quickstart Guide","href":"/skip-go/general/quickstart-guide"},{"title":"Overview \u0026 Common Usage Patterns","href":"/skip-go/general/overview-and-typical-usage"},{"title":"Supported Ecosystems","href":"/skip-go/general/supported-ecosystems-and-bridges"},{"title":"Transaction Tracking","href":"/skip-go/general/multi-chain-realtime-transaction-and-packet-tracking"},{"title":"Skip Explorer Integration","href":"/skip-go/general/explorer-integration"},{"title":"Requesting \u0026 Using API Keys","href":"/skip-go/general/api-keys"},{"title":"Smart Relay","href":"/skip-go/general/smart-relay"},{"title":"Post-Route Actions","href":"/skip-go/general/post-route-actions"},{"title":"Setting Affiliate Fees","href":"/skip-go/general/affiliate-fees"},{"title":"Getting Fee Info","href":"/skip-go/general/fee-info"},{"title":"Transaction Support","href":"/skip-go/general/transaction-support"},{"title":"FAQ","href":"/skip-go/general/faq"}]},{"group":"Skip Go Widget","pages":[{"title":"Getting Started","href":"/skip-go/widget/getting-started"},{"title":"Configuration","href":"/skip-go/widget/configuration"},{"title":"Gas on Receive","href":"/skip-go/widget/gas-on-receive"},{"title":"Web Component","href":"/skip-go/widget/web-component"},{"title":"Migration Guide","href":"/skip-go/widget/migration-guide"},{"title":"FAQ","href":"/skip-go/widget/faq"}]},{"group":"Skip Go Client","pages":[{"title":"Getting Started","href":"/skip-go/client/getting-started"},{"title":"Balances, Gas and Transaction Fee Utilities","href":"/skip-go/client/balance-gas-and-fee-tooling"},{"title":"Executing a route","href":"/skip-go/client/executing-a-route"},{"title":"Gas on Receive with Custom Frontends","href":"/skip-go/client/gas-on-receive"},{"title":"Advanced Features","href":"/skip-go/client/advanced-features"},{"title":"Migration Guide","href":"/skip-go/client/migration-guide"}]},{"group":"Advanced Transfer","pages":[{"title":"Cross-chain Failure Cases","href":"/skip-go/advanced-transfer/handling-cross-chain-failure-cases"},{"title":"Interpreting Transaction \u0026 Transfer Status","href":"/skip-go/advanced-transfer/interpreting-transaction-status"},{"title":"IBC Token Routing: Problem + Skip Go API Routing Algorithm","href":"/skip-go/advanced-transfer/ibc-routing-algorithm"},{"title":"EVM Transactions","href":"/skip-go/advanced-transfer/evm-transactions"},{"title":"SVM Transactions","href":"/skip-go/advanced-transfer/svm-transaction-details"},{"title":"CW20 Tokens \u0026 Their Limitations","href":"/skip-go/advanced-transfer/cw20-swaps"},{"title":"Experimental Features","href":"/skip-go/advanced-transfer/experimental-features"},{"title":"Go Fast","href":"/skip-go/advanced-transfer/go-fast"}]},{"group":"Advanced Swapping","pages":[{"title":"Understanding Quote Quality Metrics","href":"/skip-go/advanced-swapping/understanding-quote-quality-metrics"},{"title":"`allow_unsafe`: Preventing \u0026 Handling Bad Execution","href":"/skip-go/advanced-swapping/allow_unsafe-preventing-handling-bad-execution"},{"title":"SAFE Swapping: How to Protect Users from Bad Trades","href":"/skip-go/advanced-swapping/safe-swapping-how-to-protect-users-from-harming-themselves"},{"title":"Smart Swap","href":"/skip-go/advanced-swapping/smart-swap-options"}]},{"group":"Support Requirements","pages":[{"title":"Chain Support Requirements","href":"/skip-go/support-requirements/chain-support-requirements"},{"title":"Token \u0026 Route Support Requirements","href":"/skip-go/support-requirements/token-support-requirements"},{"title":"Skip Go Asset Registry \u0026 Overrides","href":"/skip-go/support-requirements/asset-registry-overrides"},{"title":"Swap Venue Requirements","href":"/skip-go/support-requirements/swap-venue-requirements"},{"title":"Chain Integration Request","url":"https://42jzxo.share-na2.hsforms.com/2BKju688uROaORNxmEgY2Ug","href":"/skip-go/support-requirements/chain-integration-request"}]},{"group":"Eureka","pages":[{"title":"Overview","href":"/skip-go/eureka/eureka-overview"},{"title":"Technical Overview","href":"/skip-go/eureka/eureka-tech-overview"},{"title":"Integration Guide","href":"/skip-go/eureka/integration-guide"},{"title":"Custom ERC20 Integration","href":"/skip-go/eureka/custom-erc20-integration"},{"title":"Security Properties","href":"/skip-go/eureka/security-properties"},{"title":"Contract Addresses","href":"/skip-go/eureka/contract-addresses"}]}]},{"tab":"API Reference","groups":[{"group":"Prod Endpoints","pages":[{"group":"Info","pages":[{"title":"Get /v2/info/chains","openapi":"swagger get /v2/info/chains","href":"/skip-go/api-reference/prod/info/get-v2infochains"},{"title":"Get /v2/info/bridges","openapi":"swagger get /v2/info/bridges","href":"/skip-go/api-reference/prod/info/get-v2infobridges"},{"title":"Post /v2/info/balances","openapi":"swagger post /v2/info/balances","href":"/skip-go/api-reference/prod/info/post-v2infobalances"}]},{"group":"Fungible","pages":[{"title":"Get /v2/fungible/venues","openapi":"swagger get /v2/fungible/venues","href":"/skip-go/api-reference/prod/fungible/get-v2fungiblevenues"},{"title":"Get /v2/fungible/assets","openapi":"swagger get /v2/fungible/assets","href":"/skip-go/api-reference/prod/fungible/get-v2fungibleassets"},{"title":"Post /v2/fungible/assets_from_source","openapi":"swagger post /v2/fungible/assets_from_source","href":"/skip-go/api-reference/prod/fungible/post-v2fungibleassets_from_source"},{"title":"Post /v2/fungible/route","openapi":"swagger post /v2/fungible/route","href":"/skip-go/api-reference/prod/fungible/post-v2fungibleroute"},{"title":"Post /v2/fungible/msgs","openapi":"swagger post /v2/fungible/msgs","href":"/skip-go/api-reference/prod/fungible/post-v2fungiblemsgs"},{"title":"Post /v2/fungible/msgs_direct","openapi":"swagger post /v2/fungible/msgs_direct","href":"/skip-go/api-reference/prod/fungible/post-v2fungiblemsgs_direct"},{"title":"Post /v2/fungible/ibc_origin_assets","openapi":"swagger post /v2/fungible/ibc_origin_assets","href":"/skip-go/api-reference/prod/fungible/post-v2fungibleibc_origin_assets"},{"title":"Post /v2/fungible/assets_between_chains","openapi":"swagger post /v2/fungible/assets_between_chains","href":"/skip-go/api-reference/prod/fungible/post-v2fungibleassets_between_chains"}]},{"group":"Transaction","pages":[{"title":"Post /v2/tx/submit","openapi":"swagger post /v2/tx/submit","href":"/skip-go/api-reference/prod/transaction/post-v2txsubmit"},{"title":"Post /v2/tx/track","openapi":"swagger post /v2/tx/track","href":"/skip-go/api-reference/prod/transaction/post-v2txtrack"},{"title":"Get /v2/tx/status","openapi":"swagger get /v2/tx/status","href":"/skip-go/api-reference/prod/transaction/get-v2txstatus"}]}]},{"group":"Reference Guides","pages":[{"title":"API Error Codes \u0026 Status Messages","href":"/skip-go/api-reference/error-codes"}]}]}]},{"dropdown":"Cosmos Hub","icon":"https://mintlify.s3.us-west-1.amazonaws.com/cosmos-docs/assets/icons/hub.svg","hidden":false,"versions":[{"version":"Latest","default":true,"tag":"Latest","pages":[{"title":"Latest","href":"/hub/latest"}]},{"version":"next","tag":"Unreleased","tabs":[{"tab":"Documentation","groups":[{"group":"Cosmos Hub","pages":[{"group":"Start here","pages":[{"title":"Cosmos Hub operator docs","href":"/hub/next"},{"title":"What is gaia","href":"/hub/next/getting-started/what-is-gaia"},{"title":"Versions","href":"/hub/next/start/versions"}]},{"group":"Run a node","pages":[{"title":"System requirements","href":"/hub/next/getting-started/system-requirements"},{"title":"Install gaiad","href":"/hub/next/getting-started/installation"},{"title":"Join mainnet","href":"/hub/next/hub-tutorials/join-mainnet"},{"title":"Sync a node","href":"/hub/next/node/sync"},{"title":"Database backends","href":"/hub/next/node/database"},{"title":"Run gaiad as a service","href":"/hub/next/node/service"},{"title":"Join the testnet","href":"/hub/next/hub-tutorials/join-testnet"}]},{"group":"Upgrade a node","pages":[{"title":"Upgrade a node","href":"/hub/next/hub-tutorials/upgrade-node"},{"title":"Upgrade history","href":"/hub/next/upgrade/history"}]},{"group":"Run a validator","pages":[{"title":"Validator overview","href":"/hub/next/validators/overview"},{"title":"Validator onboarding checklist","href":"/hub/next/validators/README"},{"title":"Create and manage a validator","href":"/hub/next/validators/validator-setup"},{"title":"Validator security","href":"/hub/next/validators/security"},{"title":"Remote signing","href":"/hub/next/validators/remote-signing"},{"title":"Monitoring","href":"/hub/next/validators/monitoring"},{"title":"Validator FAQ","href":"/hub/next/validators/validator-faq"}]},{"group":"Run public infrastructure","pages":[{"title":"Run public endpoints","href":"/hub/next/infrastructure/endpoints"},{"title":"Snapshots","href":"/hub/next/infrastructure/snapshots"},{"title":"Peering","href":"/hub/next/infrastructure/peering"},{"title":"Relaying","href":"/hub/next/infrastructure/relaying"},{"title":"Archive nodes and chain archives","href":"/hub/next/resources/archives"}]},{"group":"Delegate and stake","pages":[{"title":"Delegate and stake","href":"/hub/next/delegators/README"},{"title":"Delegator CLI guide","href":"/hub/next/delegators/delegator-guide-cli"},{"title":"Liquid staking module","href":"/hub/next/modules/liquid"},{"title":"Delegator security","href":"/hub/next/delegators/delegator-security"},{"title":"Delegator FAQ","href":"/hub/next/delegators/delegator-faq"}]},{"group":"Governance","pages":[{"title":"Governance process","href":"/hub/next/governance/process"},{"title":"Submitting a proposal","href":"/hub/next/governance/submitting"},{"group":"Proposal types","pages":[{"title":"Proposal types","href":"/hub/next/governance/proposal-types/README"},{"title":"Text proposals","href":"/hub/next/governance/proposal-types/text-prop"},{"title":"Parameter change proposals","href":"/hub/next/governance/proposal-types/param-change"},{"title":"Software upgrade proposals","href":"/hub/next/governance/proposal-types/software-upgrade"},{"title":"Community pool spend","href":"/hub/next/governance/proposal-types/community-pool-spend"}]}]},{"group":"Reference","pages":[{"title":"gaiad reference","href":"/hub/next/hub-tutorials/gaiad"},{"group":"Modules","pages":[{"title":"Modules on the Hub","href":"/hub/next/modules/README"},{"title":"Tokenfactory module","href":"/hub/next/modules/tokenfactory"},{"title":"Fee market module","href":"/hub/next/modules/feemarket"},{"title":"Metaprotocols module","href":"/hub/next/modules/metaprotocols"}]},{"title":"Genesis file","href":"/hub/next/resources/genesis"},{"title":"Build and verify gaiad","href":"/hub/next/resources/reproducible-builds"},{"group":"Wallets","pages":[{"title":"HD wallets","href":"/hub/next/resources/hd-wallets"},{"title":"Ledger hardware wallets","href":"/hub/next/resources/ledger"}]},{"group":"Architecture and ADRs","pages":[{"title":"Architecture Decision Records (ADR)","href":"/hub/next/architecture/README"},{"title":"ADR Creation Process","href":"/hub/next/architecture/PROCESS"},{"title":"Architecture Decision Records (ADR)","href":"/hub/next/architecture/adr/README"},{"title":"ADR Creation Process","href":"/hub/next/architecture/adr/PROCESS"},{"title":"ADR 001: Interchain Accounts","href":"/hub/next/architecture/adr/adr-001-interchain-accounts"},{"title":"ADR 002: Globalfee Module [DEPRECATED]","href":"/hub/next/architecture/adr/adr-002-globalfee"},{"title":"ADR 003: Interchain Accounts Controller Module","href":"/hub/next/architecture/adr/adr-003-ica-controller"},{"title":null,"href":"/hub/next/architecture/templates/adr-template"}]}]}]}]}]},{"version":"v25","pages":[{"title":"v25","href":"/hub/v25/index"}]}]}]},"basePath":"","title":"TxDecode - Cosmos Docs","buildId":"dpl_345ReqzYaAjzS9QpeJemsKdb7KDj","deploymentId":"dpl_345ReqzYaAjzS9QpeJemsKdb7KDj","dynamics":["c2aa737661","2b790eda92","b0f84f53ff","a9bb46feb3"],"chunks":["OpenApiReferenceProvider-C8RPHPxo.js","utils-0BK-9q6z.js","cloneDeep-izs3Hzxb.js","_Uint8Array-BVIqJ90l.js","isObjectLike-C8vmzPEN.js","isArray-Dcu1dQ5t.js","utils-DfjzsUJT.js","toString-BX-iyh8G.js","isSymbol-CSH9U2Gm.js","addUniqueKeysToSchema-B4v9psJ4.js","snippetPresets-CpTQv-Ez.js","style-to-object-BY3JEAdk.js","v4-DIgz8zy6.js","ApiExamples-BNP-Fvr0.js","isEqual-BfaiBbcl.js","usePlaygroundInputsStore-BSgu6h1D.js","shallow-Biv1i9Gs.js","getApiPlaygroundDisplay-BoGOXhtF.js","CodeSnippet-DvQoT18_.js","CodeSnippets-Dnpa15xT.js","Page-Buji1S4J.js","getPastedJson-xAIyhUFE.js","icon-S6FBih11.js","MethodPill-SaYeUZyk.js","DuplicateIcon-Cs-p3v2Q.js","createIcon-DjCFEoHq.js","DynamicMarkdown-BcnBltEQ.js","SectionHeading-BUBl0eEF.js","axios-vUo_bRtp.js","Markdown-h4cOoD8d.js","clsx-B2v50t8t.js","lib-DuNMoZ05.js","lib-B8HbPgcC.js","html-void-elements-mCSPHezU.js","dist-DJnKvr0g.js","katex-YMM-FMeD.js","marked.esm-CZWythHk.js","AssistantPageLink-BHrrjR1K.js"]}