Errors¶
Every exception pyogmios raises is a pyogmios.OgmiosError.
OgmiosError
├── OgmiosConnectionError cannot connect, or the connection dropped (also ConnectionError)
├── OgmiosTimeoutError no answer in time (also TimeoutError)
├── ServerVersionError the server is not Ogmios 7
├── StatefulOverHttpError chain sync, the mempool or ledger_state_at over HTTP
└── ResponseError the server answered with an error
├── JsonRpcError the request was malformed (-32700 to -32600)
├── ChainSyncError 1000s
├── LedgerStateQueryError 2000s
├── TransactionError 3000s: EvaluateTransactionError and SubmitTransactionError
└── MempoolError 4000s
A ResponseError carries what the server said:
code: the Ogmios error code.message: its message.data: its data, as JSON (orNone).details: the error parsed into its model frompyogmios.types, when the method declares one.method: the method that failed.
Catch as broadly or narrowly as you need:
from pyogmios import errors
try:
client.submit_transaction(cbor)
except errors.ValueNotConservedError as error: # one ledger rule
...
except errors.SubmitTransactionError as error: # any rejected submission
...
except errors.OgmiosConnectionError: # the server is unreachable
...
Parameters that do not match a method's schema raise Pydantic's ValidationError before anything is
sent.
Every error code¶
| Code | Exception | Parent | Meaning |
|---|---|---|---|
| 1000 | IntersectionNotFoundError |
ChainSyncError |
None of the given points is on the chain. data holds the server's tip. |
| 1001 | IntersectionInterleavedError |
ChainSyncError |
findIntersection was sent while nextBlock requests were still pending. |
| 2000 | AcquireLedgerStateError |
LedgerStateQueryError |
The point to acquire is too old or not on the chain. |
| 2001 | EraMismatchError |
LedgerStateQueryError |
The query was made for an era other than the ledger's current era. |
| 2002 | UnavailableInCurrentEraError |
LedgerStateQueryError |
The query is not available in the ledger's current era. |
| 2003 | AcquiredExpiredError |
LedgerStateQueryError |
The acquired ledger state is too old to query: acquire it again. |
| 2004 | InvalidGenesisError |
LedgerStateQueryError |
The node has no genesis configuration for the requested era. |
| 3000 | IncompatibleEraError |
EvaluateTransactionError |
Returned when trying to evaluate execution units of a pre-Alonzo transaction. Note that this isn't possible with Ogmios because transactions are always de-serialized as Alonzo transactions. |
| 3001 | UnsupportedEraError |
EvaluateTransactionError |
Returned when trying to evaluate execution units of an era that is now considered too old and is no longer supported. This can solved by using a more recent transaction format. |
| 3002 | OverlappingAdditionalUtxoError |
EvaluateTransactionError |
Happens when providing an additional UTXO set which overlaps with the UTXO on-chain. |
| 3003 | NodeTipTooOldError |
EvaluateTransactionError |
Happens when attempting to evaluate execution units on a node that isn't enough synchronized. |
| 3004 | CannotCreateEvaluationContextError |
EvaluateTransactionError |
The transaction is malformed or missing information; making evaluation impossible. |
| 3005 | SubmitEraMismatchError |
SubmitTransactionError |
Failed to submit the transaction in the current era. This may happen when trying to submit a transaction near an era boundary (i.e. at the moment of a hard-fork). |
| 3010 | ScriptExecutionFailureError |
EvaluateTransactionError |
One or more script execution terminated with an error. |
| 3100 | InvalidSignatoriesError |
SubmitTransactionError |
Some signatures are invalid. Only the serialised transaction body, without metadata or witnesses, must be signed. |
| 3101 | MissingSignatoriesError |
SubmitTransactionError |
Some signatures are missing. A signed transaction must carry signatures for all inputs locked by verification keys or a native script. Transaction may also need signatures for each required extra signatories often required by Plutus Scripts. |
| 3102 | MissingScriptsError |
SubmitTransactionError |
Some script witnesses are missing. Indeed, any script used in a transaction (when spending, minting, withdrawing or publishing certificates) must be provided in full with the transaction. Scripts must therefore be added either to the witness set or provided as a reference inputs should you use Plutus V2+ and a format from Babbage and beyond. |
| 3103 | FailingNativeScriptError |
SubmitTransactionError |
The transaction contains failing phase-1 monetary scripts (a.k.a. native scripts). This can be due to either a missing or invalid signature, or because of a time validity issue. The field 'data.failingNativeScripts' contains a list of hash digests of all failing native scripts found in the transaction. |
| 3104 | ExtraneousScriptsError |
SubmitTransactionError |
Extraneous (i.e. non-required) scripts found in the transaction. A transaction must not contain scripts that aren't strictly needed for validation, that are present in metadata or that are published in an output. Perhaps you have used provided a wrong script for a validator? Anyway, the 'data.extraneousScripts' field lists hash digests of scripts found to be extraneous. |
| 3105 | MissingMetadataHashError |
SubmitTransactionError |
Missing required metadata hash in the transaction body. If the transaction includes metadata, then it must also include a hash digest of these serialised metadata in its body to prevent malicious actors from tempering with the data. The field 'data.metadata.hash' contains the expected missing hash digest of the metadata found in the transaction. |
| 3106 | MissingMetadataError |
SubmitTransactionError |
No metadata corresponding to a specified metadata hash. It appears that you might have forgotten to attach metadata to a transaction, yet included a hash digest of them in the transaction body? The field 'data.metadata.hash' contains the orphan hash found in the body. |
| 3107 | MetadataHashMismatchError |
SubmitTransactionError |
There's a mismatch between the provided metadata hash digest and the one computed from the actual metadata. The two must match exactly. The field 'data.provided.hash' references the provided hash as found in the transaction body, whereas 'data.computed.hash' contains the one the ledger computed from the actual metadata. |
| 3108 | InvalidMetadataError |
SubmitTransactionError |
Invalid metadatum found in transaction metadata. Metadata byte strings must be no longer than 64-bytes and text strings must be no longer than 64 bytes once UTF-8-encoded. Some metadatum in the transaction infringe this rule. |
| 3109 | MissingRedeemersError |
SubmitTransactionError |
Missing required redeemer(s) for Plutus scripts. There are validators needed for the transaction that do not have an associated redeemer. Redeemer are provided when trying to execute the validation logic of a script (e.g. when spending from an input locked by a script, or minting assets from a Plutus monetary policy. The field 'data.missingRedeemers' lists the different purposes for which a redeemer hasn't been provided. |
| 3110 | ExtraneousRedeemersError |
SubmitTransactionError |
Extraneous (non-required) redeemers found in the transaction. There are some redeemers that aren't pointing to any script. This could be because you've left some orphan redeemer behind, because they are pointing at the wrong thing or because you forgot to include their associated validator. Either way, the field 'data.extraneousRedeemers' lists the different orphan redeemer pointers. |
| 3111 | MissingDatumsError |
SubmitTransactionError |
Transaction failed because some Plutus scripts are missing their associated datums. 'data.missingDatums' contains a set of data hashes for the missing datums. Ensure all Plutus scripts have an associated datum in the transaction's witness set or, are provided through inline datums in reference inputs. |
| 3112 | ExtraneousDatumsError |
SubmitTransactionError |
The transaction failed because it contains datums not associated with any script or output. This could be because you've left some orphan datum behind, because you've listed the wrong inputs in the transaction or because you've just forgotten to include a datum associated with an input. Either way, the field 'data.extraneousDatums' contains a set of data hashes for these extraneous datums. |
| 3113 | ScriptIntegrityHashMismatchError |
SubmitTransactionError |
The transaction failed because the provided script integrity hash doesn't match the computed one. This is crucial for ensuring the integrity of cost models and Plutus version used during script execution. The field 'data.providedScriptIntegrity' correspond to what was given, if any, and 'data.computedScriptIntegrity' is what was expected. If the latter is null, this means you shouldn't have included a script integrity hash to begin with. |
| 3114 | OrphanScriptInputsError |
SubmitTransactionError |
This is bad, you're trying to spend inputs that are locked by Plutus scripts, but have no associated datums. Those inputs are so-to-speak unspendable (at least with the current ledger rules). There's nothing you can do apart from re-creating these UTxOs but with a corresponding datum this time. The field 'data.orphanScriptInputs' lists all such inputs found in the transaction. |
| 3115 | MissingCostModelsError |
SubmitTransactionError |
It seems like the transaction is using a Plutus version for which there's no available cost model yet. This could be because that language version is known of the ledger but hasn't yet been enabled through hard-fork. The field 'data.missingCostModels' lists all the languages for which a cost model is missing. |
| 3116 | MalformedScriptsError |
SubmitTransactionError |
Some Plutus scripts in the witness set or in an output are invalid. Scripts must be well-formed flat-encoded Plutus scripts, CBOR-encoded. Yes, there's a double binary encoding. The outer-most encoding is therefore just a plain CBOR bytestring. Note that some tools such as the cardano-cli triple encode scripts for some reasons, resulting in a double outer-most CBOR encoding. Make sure that your script are correctly encoded. The field 'data.malformedScripts' lists the hash digests of all the problematic scripts. |
| 3117 | UnknownOutputReferencesError |
SubmitTransactionError |
The transaction contains unknown UTxO references as inputs. This can happen if the inputs you're trying to spend have already been spent, or if you've simply referred to non-existing UTxO altogether. The field 'data.unknownOutputReferences' indicates all unknown inputs. |
| 3118 | OutsideOfValidityIntervalError |
SubmitTransactionError |
The transaction is outside of its validity interval. It was either submitted too early or too late. A transaction that has a lower validity bound can only be accepted by the ledger (and make it to the mempool) if the ledger's current slot is greater than the specified bound. The upper bound works similarly, as a time to live. The field 'data.currentSlot' contains the current slot as known of the ledger (this may be different from the current network slot if the ledger is still catching up). The field 'data.validityInterval' is a reminder of the validity interval provided with the transaction. |
| 3119 | TransactionTooLargeError |
SubmitTransactionError |
The transaction exceeds the maximum size allowed by the protocol. Indeed, once serialized, transactions must be under a bytes limit specified by a protocol parameter. The field 'data.measuredTransactionSize' indicates the actual measured size of your serialized transaction, whereas 'data.maximumTransactionSize' indicates the current maximum size enforced by the ledger. |
| 3120 | ValueTooLargeError |
SubmitTransactionError |
Some output values in the transaction are too large. Once serialized, values must be below a certain threshold. That threshold sits around 4 KB during the Mary era, and was then made configurable as a protocol parameter in later era. The field 'data.excessivelyLargeOutputs' lists all transaction outputs with values that are above the limit. |
| 3121 | EmptyInputSetError |
SubmitTransactionError |
Transaction must have at least one input, but this one has an empty input set. One input is necessary to prevent replayability of transactions, as it piggybacks on the unique spendable property of UTxO. |
| 3122 | TransactionFeeTooSmallError |
SubmitTransactionError |
Insufficient fee! The transaction doesn't not contain enough fee to cover the minimum required by the protocol. Note that fee depends on (a) a flat cost fixed by the protocol, (b) the size of the serialized transaction, (c) the budget allocated for Plutus script execution. The field 'data.minimumRequiredFee' indicates the minimum required fee whereas 'data.providedFee' refers to the fee currently supplied with the transaction. |
| 3123 | ValueNotConservedError |
SubmitTransactionError |
In and out value not conserved. The transaction must exactly balance: every input must be accounted for. There are various things counting as 'in balance': (a) the total value locked by inputs (or collateral inputs in case of a failing script), (b) rewards coming from withdrawals and (c) return deposits from stake credential or pool de-registration. In a similar fashion, various things count towards the 'out balance': (a) the total value assigned to each transaction output, (b) the fee and (c) any deposit for stake credential or pool registration. The field 'data.valueConsumed' contains the total 'in balance', and 'data.valueProduced' indicates the total amount counting as 'out balance'. |
| 3124 | NetworkMismatchError |
SubmitTransactionError |
Some discriminated entities in the transaction are configured for another network. In fact, payment addresses, stake addresses and stake pool registration certificates are bound to a specific network identifier. This identifier must match the network you're trying to submit them to. Since the Alonzo era, transactions themselves may also contain a network identifier. The field 'data.expectedNetwork' indicates what is the currrently expected network. The field 'data.discriminatedType' indicates what type of entity is causing an issue here. And 'data.invalidEntities' lists all the culprits found in the transaction. The latter isn't present when the transaction's network identifier itself is wrong. |
| 3125 | InsufficientlyFundedOutputsError |
SubmitTransactionError |
Some outputs have an insufficient amount of Ada attached to them. In fact, any new output created in a system must pay for the resources it occupies. Because user-created assets are worthless (from the point of view of the protocol), those resources must be paid in the form of a Ada deposit. The exact depends on the size of the serialized output: the more assets, the higher the amount. The field 'data.insufficientlyFundedOutputs.[].output' contains a list of all transaction outputs that are insufficiently funded. Starting from the Babbage era, the field 'data.insufficientlyFundedOutputs.[].minimumRequiredValue' indicates the required amount of Lovelace (1e6 Lovelace = 1 Ada) needed for each output. |
| 3126 | BootstrapAttributesTooLargeError |
SubmitTransactionError |
Some output associated with legacy / bootstrap (a.k.a. Byron) addresses have attributes that are too large. The field 'data.bootstrapOutputs' lists all affected outputs. |
| 3127 | MintingOrBurningAdaError |
SubmitTransactionError |
The transaction is attempting to mint or burn Ada tokens. That is, fortunately, not allowed by the ledger. |
| 3128 | InsufficientCollateralError |
SubmitTransactionError |
Insufficient collateral value for Plutus scripts in the transaction. Indeed, when executing scripts, you must provide a collateral amount which minimum is a percentage of the total execution budget for the transaction. The exact percentage is given by a protocol parameter. The field 'data.providedCollateral' indicates the amount currently provided as collateral in the transaction, whereas 'data.minimumRequiredCollateral' indicates the minimum amount expected by the ledger |
| 3129 | CollateralLockedByScriptError |
SubmitTransactionError |
Invalid choice of collateral: an input provided for collateral is locked by script. Collateral inputs must be spendable, and the ledger must be able to assert their validity during the first phase of validations (a.k.a phase-1). This discards any input locked by a Plutus script to be used as collateral. Note that for some reason inputs locked by native scripts are also excluded from candidates collateral. The field 'data.unsuitableCollateralInputs' lists all the problematic output references. |
| 3130 | UnforeseeableSlotError |
SubmitTransactionError |
One of the transaction validity bound is outside any foreseeable future. The vision of the ledger in the future when evaluating Plutus scripts is limited because the ledger cannot guarantee that the chain will not hard-fork into a version of the protocol working with a different set of parameters (or even, working with the same consensus protocol). However, the protocol cannot fork in less than k blocks, where k is the security parameter of the chain. Plus, Ouroboros Praos ensures that there are at least k blocks produced in a window of 3 * k / f slots, where f is the density parameter, also known as the active slot coefficient. Short story short, you can only set validity interval in a short timespan, which is around ~36h in the future on Mainnet at the moment of writing this error message. The field 'data.unforeseeableSlot' indicates the slot which couldn't be converted to a POSIX time due to hard fork uncertainty. |
| 3131 | TooManyCollateralInputsError |
SubmitTransactionError |
The transaction contains too many collateral inputs. The maximum number of collateral inputs is constrained by a protocol parameter. The field 'data.maximumCollateralInputs' contains the current value of that parameter, and 'data.countedCollateralInputs' indicates how many inputs were actually found in your transaction. |
| 3132 | MissingCollateralInputsError |
SubmitTransactionError |
The transaction doesn't provide any collateral inputs but it must. Indeed, when executing scripts, you must provide a collateral amount which is collected by the ledger in case of script execution failure. That collateral serves as a compensation for nodes that aren't thus able to collect normal fees set on the transaction. Note that ledger validations are split in two phases. The first phase regards pretty much every validation outside of script executions. Anything from the first phase doesn't require a collateral and will not consume the collateral in case of failure because they require little computing resources. Besides, in principle, any client application or wallet will prevent you from submitting an invalid transaction to begin with. |
| 3133 | NonAdaCollateralError |
SubmitTransactionError |
One of the input provided as collateral carries something else than Ada tokens. Only Ada can be used as collateral. Since the Babbage era, you also have the option to set a 'collateral return' or 'collateral change' output in order to send the surplus non-Ada tokens to it. Regardless, the field 'data.unsuitableCollateralValue' indicates the actual collateral value found by the ledger |
| 3134 | ExecutionUnitsTooLargeError |
SubmitTransactionError |
The transaction execution budget for scripts execution is above the allowed limit. The protocol limits the amount of execution that a single transaction can do. This limit is set by a protocol parameter. The field 'data.maximumExecutionUnits' indicates the current limit and the field 'data.providedExecutionUnits' indicates how much the transaction requires. |
| 3135 | TotalCollateralMismatchError |
SubmitTransactionError |
There's a mismatch between the declared total collateral amount, and the value computed from the inputs and outputs. These must match exactly. The field 'data.declaredTotalCollateral' reports the amount declared in the transaction whereas 'data.computedTotalCollateral' refers to the amount actually computed. |
| 3136 | SpendsMismatchError |
SubmitTransactionError |
Invalid transaction submitted as valid, or vice-versa. Since Alonzo, the ledger may allow invalid transactions to be submitted and included on-chain, provided that they leave a collateral value as compensation. This prevent certain class of attacks. As a consequence, transactions now have a validity tag with them. Your transaction did not match what that validity tag is stating. The field 'data.declaredSpending' indicates what the transaction is supposed to consume (collaterals or inputs) and the field 'data.mismatchReason' provides more information about the mismatch. |
| 3137 | UnauthorizedVotesError |
SubmitTransactionError |
The transaction contains votes from unauthorized voters. The field 'data.unauthorizedVotes' indicates the faulty voters and the action they attempted to incorrectly vote for. |
| 3138 | UnknownGovernanceProposalsError |
SubmitTransactionError |
Reference(s) to unknown governance proposals found in transaction. This may be because you've indicated a wrong identifier or because the proposal hasn't yet been submitted on-chain. Note that the order in which transactions are submitted matters. The field 'data.unknownProposals' tells you about the unknown references. |
| 3139 | InvalidProtocolParametersUpdateError |
SubmitTransactionError |
The transaction contains an invalid or unauthorized protocol parameters update. This operation is reserved to genesis key holders. |
| 3140 | UnknownStakePoolError |
SubmitTransactionError |
The transaction references an unknown stake pool as a target for delegation or update. Double-check the pool id mentioned in 'data.unknownStakePool'. Note also that order in which transactions are submitted matters; if you're trying to register a pool and delegate to it in one go, make sure to submit transactions in the right order. |
| 3141 | IncompleteWithdrawalsError |
SubmitTransactionError |
The transaction contains incomplete or invalid rewards withdrawals. When present, rewards withdrawals must consume rewards in full, there cannot be any leftover. You may also run into this error if the associatd stake credential is not registered. The field 'data.incompleteWithdrawals' contains a map of culprit withdrawals. |
| 3142 | RetirementTooLateError |
SubmitTransactionError |
A stake pool retirement certificate is trying to retire too late in the future. Indeed, there's a maximum delay for stake pool retirement, controlled by a protocol parameter. The field 'data.currentEpoch' indicates the current epoch known of the ledger, 'data.declaredEpoch' refers to the epoch declared in the retirement certificate and 'data.firstInvalidEpoch' is the first epoch considered invalid (too far) for retirement |
| 3143 | StakePoolCostTooLowError |
SubmitTransactionError |
Stake pool cost declared in a registration or update certificate are below the allowed minimum. The minimum cost of a stake pool is fixed by a protocol parameter. The 'data.minimumStakePoolCost' field holds the current value of that parameter whereas 'data.declaredStakePoolCost' indicates which amount was declared. |
| 3144 | MetadataHashTooLargeError |
SubmitTransactionError |
Some hash digest of (optional) stake pool metadata is too long. When registering, stake pools can supply an external metadata file and a hash digest of the content. The hashing algorithm is left open but the output digest must be smaller than 32 bytes. The field 'data.infringingStakePool' indicates which stake pool has an invalid metadata hash and 'data.computedMetadataHashSize' documents the computed hash size. |
| 3145 | CredentialAlreadyRegisteredError |
SubmitTransactionError |
Trying to re-register some already known credentials. Stake credentials can only be registered once. This is true for both keys and scripts. The field 'data.knownCredential' points to an already known credential that's being re-registered by this transaction. |
| 3146 | UnknownCredentialError |
SubmitTransactionError |
The transaction references an unknown stake credential. For example, to delegate to a stake pool, you must first register the stake key or script used for delegation. This may be done in the same transaction or in an earlier transaction but cannot happen retro-actively. The field 'data.unknownCredential' indicates what credential is used without being registered. |
| 3147 | NonEmptyRewardAccountError |
SubmitTransactionError |
Trying to unregister stake credentials associated to a non empty reward account. You must empty the reward account first (or do it as part of the same transaction) to proceed. The field 'data.nonEmptyRewardAccountBalance' indicates how much Lovelace is left in the account. |
| 3148 | InvalidGenesisDelegationError |
SubmitTransactionError |
Invalid or unauthorized genesis delegation. The genesis delegate is unknown, invalid or already in use. |
| 3149 | InvalidMIRTransferError |
SubmitTransactionError |
Invalid MIR transfer. The resulting delta is likely negative. |
| 3150 | ForbiddenWithdrawalError |
SubmitTransactionError |
The transaction is attempting to withdraw rewards from stake credentials that do not engage in on-chain governance. Credentials must be associated with a delegate representative (registered, abstain or noConfidence) before associated rewards can be withdrawn. The field 'data.marginalizedCredentials' lists all the affected credentials. |
| 3151 | CredentialDepositMismatchError |
SubmitTransactionError |
The deposit specified in a stake credential registration (for delegation or governance) does not match the current value set by protocol parameters. The field 'data.expectedDeposit', when present, indicates the deposit amount as currently expected by ledger. |
| 3152 | DRepAlreadyRegisteredError |
SubmitTransactionError |
Trying to re-register some already known delegate representative. Delegate representatives can only be registered once. The field 'data.knownDelegateRepresentatives' points to an already known credential that's being re-registered by this transaction. |
| 3153 | DRepNotRegisteredError |
SubmitTransactionError |
The transaction references an unknown delegate representative. To delegate to a representative, it must first register as such. This may be done in the same transaction or in an earlier transaction but cannot happen retro-actively. The field 'data.unknownDelegateRepresentative' indicates what credential is used without being registered. |
| 3154 | UnknownConstitutionalCommitteeMemberError |
SubmitTransactionError |
The transaction references an unknown constitutional committee member. This can be either because that member does not actually exist or because it was registered but has resigned. The field 'data.unknownConstitutionalCommitteeMember' indicates what credential is unknown. |
| 3155 | GovernanceProposalDepositMismatchError |
SubmitTransactionError |
There's a mismatch between the proposal deposit amount declared in the transaction and the one expected by the ledger. The deposit is actually configured by a protocol parameter. The field 'data.expectedDeposit' indicates the current configuration and amount expected by the ledger. The field 'data.providedDeposit' is a reminder of the what was set in the submitted transaction. |
| 3156 | ConflictingCommitteeUpdateError |
SubmitTransactionError |
The transaction contains an invalid governance action: it tries to both add members to the committee and remove some of those same members. The field 'data.conflictingMembers' indicates which members are found on both sides. |
| 3157 | InvalidCommitteeUpdateError |
SubmitTransactionError |
The transaction contains an invalid governance action: it tries to add new members to the constitutional committee with a retirement epoch in the past. The field 'data.alreadyRetiredMembers' indicates the faulty members that would otherwise be already retired. |
| 3158 | TreasuryWithdrawalMismatchError |
SubmitTransactionError |
The transaction is trying to withdraw more funds than specified in a governance action! The field 'data.providedWithdrawal' indicates the amount specified in the transaction, whereas 'data.computedWithdrawal' is the actual amount as computed by the ledger. |
| 3159 | InvalidOrMissingPreviousProposalsError |
SubmitTransactionError |
The transaction contains invalid or missing reference to previous (ratified) governance proposals. Indeed, some governance proposals such as protocol parameters update or consitutional committee change must point to last action of the same purpose that was ratified. The field 'data.invalidOrMissingPreviousProposals' contains a list of submitted actions that are missing details. For each item, we provide the anchor of the corresponding proposal, the type of previous proposal that is expected and the invalid proposal reference if relevant. |
| 3160 | VotingOnExpiredActionsError |
SubmitTransactionError |
The transaction contains votes for an expired proposal. The field 'data.invalidVotes' indicates the faulty voters and the proposal they attempted to vote for. |
| 3161 | ExecutionBudgetOutOfBoundsError |
SubmitTransactionError |
The transaction ran out of execution budget! This means that the budget granted for the execution of a particular script was too small or exceeding the maximum value allowed by the protocol. The field 'data.budgetUsed' indicates the actual execution units used by the validator before it was interrupted. |
| 3162 | InvalidHardForkVersionBumpError |
SubmitTransactionError |
The new proposed version for a hard-fork isn't a valid version bump. The version (major, minor, patch) follows strict rules which can be summarized as follow: (1) the new triplet must be greater than the current one in the usual order of priorities (i.e. 'major' -> 'minor' -> 'patch'), (2) 'minor' must be 0 if 'major' is bumped, (3) 'minor' can only be bumped in increments of 1 and only if 'major' isn't bumped and (4) 'major' can only be bumped in increments of 1. The field 'data.proposedVersion' indicates the (invalid) version in the submitted proposal whereas 'data.currentVersion' indicates the current protocol version. |
| 3163 | ConstitutionGuardrailsHashMismatchError |
SubmitTransactionError |
The provided constitution guardrails hash doesn't match the expected on defined in the constitution. Some governance actions such as treasury withdrawals or protocol parameters updates must correctly refer to the constitution guardrails hash digest. The latter can be 'null'. The field 'data.providedHash' indicates the hash provided in the proposal, and the field 'data.expectedHash' the one specified in the constitution |
| 3164 | ConflictingInputsAndReferencesError |
SubmitTransactionError |
Identical UTxO references were found in both the transaction inputs and references. This is redundant and no longer allowed by the ledger. Indeed, if the a UTxO is present in the inputs set, it is already in the transaction context. The field 'data.conflictingReferences' contains the culprit references present in both sets. |
| 3165 | UnauthorizedGovernanceActionError |
SubmitTransactionError |
The ledger is still in a bootstrapping phase. During that phase, only protocol parameters changes, hard fork initiations and info actions are authorized. The transaction contains other types of governance action and was therefore rejected |
| 3166 | ReferenceScriptsTooLargeError |
SubmitTransactionError |
(code 3166) |
| 3167 | UnknownVotersError |
SubmitTransactionError |
Some voters in the transaction are unknown. Voters must correspond to registered credentials present in the ledger. They can possibly be registered in the same block, but it must imperatively happens before they are used for voting. The field 'data.unknownVoters' indicates the credentials that couldn't be mapped to any known voter. |
| 3168 | EmptyTreasuryWithdrawalError |
SubmitTransactionError |
Some proposals contain empty treasury withdrawals, which is pointless and a waste of resources. |
| 3169 | PointerAddressInCollateralReturnError |
SubmitTransactionError |
The collateral return output contains a pointer address, which is not permitted in the Dijkstra era. |
| 3170 | StakePoolVRFKeyAlreadyRegisteredError |
SubmitTransactionError |
Stake pool can (no longer) re-use an already used VRF key. Yet this transaction contains a pool which declares a VRF key that is already in use. |
| 3997 | UnexpectedMempoolError |
SubmitTransactionError |
A transaction was rejected due to custom rules that prevented it from entering the mempool. A justification is given as 'data.error'. |
| 3998 | UnrecognizedCertificateTypeError |
SubmitTransactionError |
Unrecognized certificate type. This error is a placeholder due to how internal data-types are modeled. If you ever run into this, please report the issue as you've likely discoverd a critical bug... |
| 4000 | MustAcquireMempoolFirstError |
MempoolError |
The mempool must be acquired (acquireMempool) before this request. |
| -32600 | InvalidRequestError |
JsonRpcError |
Ogmios uses this code for unknown methods and invalid params as well. |
| -32601 | MethodNotFoundError |
JsonRpcError |
The method does not exist. (Ogmios usually answers -32600 for this.) |
| -32602 | InvalidParamsError |
JsonRpcError |
The params are invalid for the method. |
| -32602 | TransactionDeserialisationError |
InvalidParamsError |
The transaction could not be decoded in any era. data lists the decoder errors. |
| -32603 | InternalError |
JsonRpcError |
The server failed while handling the request. |
| -32700 | ParseError |
JsonRpcError |
The server could not parse the request as JSON. |