In case NIS encounters an error while processing a request it returns an error.
This chapter describes the errors messages that can be returned from NIS.
Request method 'GET' not supported
The request was performed as GET request but was expected to be a POST request.
address must be valid:
At least one address supplied in the request was invalid. Addresses are validated before processing a request. If validation fails, an error containing this message is returned.
The number of accounts that are allowed to harvest on NIS was exceeded.
JSON Object was expected:
A parameter is missing in the request.
The account specified in the request is not known.
block not found in the db
The block that was requested could not be found in the database.
height must be positive
The block height supplied in a request was zero or negative. Block height must always be greater than zero.
network has not been booted yet
Most requests need the node that should answer the request to be already booted. If node is not booted yet, this error message will be returned.
network boot was already attempted
It was attempted to boot an already booted node. Nodes can only be booted once.
remote 126.96.36.199 attempted to call local /node/boot
It was attempted to boot a remote node. Only local node can be booted.
The deadline for the entity has already expired. The deadline must always lie in the future.
The deadline lies too far in the future. Deadlines are only allowed to lie up to 24 hours in the future.
The account does not have enough funds.
The message for the transaction exceeds the limit of 512 bytes.
The hash of the entity already exists either in the cache or in the database.
The signature of the entity failed upon verification.
The timestamp of the entity lies to far in the past.
The timestamp of the entity lies too far in the future.
Validation failed because the block had an ineligible signer. This usually occurs when remote harvesting is in the process of being activated or deactivated.
The entity cannot be processed because the remote node is out of synchronization with the local node. This happens frequently when a node is not fully synchronized and receives a new block with much larger height than its own chain.
The supplied transaction has an insufficient fee.
The supplied transaction has the nemesis account as sender and cannot be included in a normal block.
The transaction was rejected because the transaction cache is too full. This happens when an account tries to send too many transactions in a short time. To improve the chance that the transaction gets accepted you can try to raise the transaction fee.
Entity was rejected because it has the wrong network specified.
Block was rejected because it was harvested by a blocked account (typically a reserved NEM fund).
The importance cannot be transferred to an account with nonzero balance.
The transaction is conflicting because there is already a transfer of importance in progress.
The transaction is conflicting because the importance was already transferred.
The transaction is conflicting because no importance has been transferred yet.
Validation failed because transaction is using remote account in an improper way.
The multisig transaction was rejected because the signer of the transaction is not a cosignatory of the sender account of the inner transaction.
Validation failed because the cosignatories attached to a multisig transaction were invalid.
The signature transaction was rejected because the corresponding multisig transaction was not found.
The transaction was rejected because the signer is a multisig account. Multisig accounts are not allowed to initiate any transaction (only cosignatories are allowed to do so).
The transaction was rejected because it tried to add a cosignatory to a multisig account which already has this cosignatory.
The transaction was rejected because it tried to remove multiple cosignatories at once. It is only allowed to remove one cosignatory at a time.
The transaction was rejected because it tried to do redundant modifications. This can happen if a transaction tries to add the same cosignatory two time.
The transaction was rejected because it contained conflicting modifications to a multisig account. This can for instance happen if a transaction tries to add and then delete the same cosignatory.
The transaction was rejected because it contains too many cosignatories. The maximum number of cosignatories allowed for a multisig account is 32.
Validation failed because a multisig modification would result in a multisig account being a cosigner.
Validation failed because the minimum number of cosignatories is negative or larger than the number of cosignatories.
Validation failed because the namespace is unknown.
Validation failed because the namespace already exists.
Validation failed because the namespace has expired.
Validation failed because the transaction signer is not the owner of the namespace.
Validation failed because the name for the namespace is invalid.
Validation failed because the specified namespace rental fee sink is invalid.
Validation failed because the specified rental fee is invalid.
Validation failed because the provision was done too early.
Validation failed because the namespace contains a reserved part and is not claimable.
Validation failed because the mosaic is unknown.
Validation failed because the modification of the existing mosaic is not allowed.
Validation failed because the transaction signer is not the creator of the mosaic.
Validation failed because the mosaic supply is immutable.
Validation failed because the maximum overall mosaic supply is exceeded.
Validation failed because the resulting mosaic supply would be negative.
Validation failed because the mosaic is not transferable.
Validation failed because the divisibility of the mosaic is violated.
Validation failed because conflicting mosaic creation is present.
Validation failed because the mosaic creation fee sink is invalid.
Validation failed because the specified creation fee is invalid.
Validation failed because a transfer transaction had too many attached mosaic transfers.