FAQ

Analog GMP is a composable, permissionless, on-chain toolkit that enables messages to flow freely and securely across supported blockchains. It facilitates cross-chain smart contract execution calls , value transfer, and message delivery, allowing developers to build cross-chain DApps that can leverage liquidity from multiple blockchains.

No. Analog GMP is not a blockchain even though it is built on top of a sovereign blockchain, the Timechain. Timechain creates an accountability layer for all transactions occurring across Analog GMP. Some of the protocol events that Timechain manages include registration and tracking of validators, management of shards through key rotations, and initiation of tasks on the destination shards to trigger execution of cross-chain requests.

For more details, check out Timechain.

ANLOG is the native token for the Analog Network. ANLOG token holders contribute to decentralized security and governance and earn rewards and fees.

Analog GMP benefits both blockchain and DApp developers. Blockchain developers can tap into user bases, assets, and valuable states from supported blockchains using Analog GMP. DApp developers, on the other hand, can create cross-chain network effects and liquidity, allowing users to access their DApps from preferred chains effortlessly with Analog GMP.

While you could build specific cross-chain bridges on top of Analog GMP, the platform isn’t your typical cross-chain bridge. At its core, Analog GMP is a general message-passing platform that leverages a sovereign blockchain (i.e., Timechain) to pass messages securely and reliably across supported blockchains. As such, it transcends the idea of transferring tokens from one chain to another. For example, with Analog GMP, you can move arbitrary messages (data), value (token), and message + value (i.e., programmable tokens) between different connected chains.

You can request Testnet ANLOG (TANLOG) tokens in the Faucet channel in our Discord. Check out Testnet Faucet for more details.

• Threshold Signatures: Shards are groups of nodes that collaboratively sign messages using Schnorr signatures, ensuring no single point of failure.
• Management: Admins can register (setShard) or revoke (revokeShard) shard keys. Active shards are stored in ShardStore.
• Verification: Signatures are validated using stored public keys, and revoked shards cannot sign new messages.

The Gateway contract facilitates cross-chain communication by enabling the submission and execution of GMP messages. It allows users to send messages to different blockchain networks, manages security through Threshold Signature Scheme (TSS) shards, and ensures message integrity via cryptographic signatures.

Analog GMP is built on top of the Timechain, a battle-tested NPoS consensus protocol, to secure cross-chain transactions. Timechain ensures message validity through a permissionless ecosystem consisting of dynamic validator sets and employs Threshold Cryptography to connect to external blockchains, requiring supermajority approval for transaction execution. See the Security & Audits page for more details.

• Replay Protection: The contract uses a mapping _executedMessages to store hashes of executed messages, preventing reuse.
• Nonce Tracking: Each sender has a nonce (nonceOf) that increments with every message, ensuring uniqueness.
• Signature Verification: Messages require valid Schnorr signatures from authorized TSS shards, tied to specific shard IDs.

• Source Validation: Messages include a source field (address or contract flag) to identify the origin.
• Signature Checks: Inbound messages require valid Schnorr signatures from the current active shard, verified via _verifySignature.

The time to finality depends on three factors: the time it takes for the transaction to be considered final on the source chain, the time it takes for the Timechain to create the task for the destination shard (which is minimal), and the time it takes for the transaction to be executed on the destination chain.

Before signing any attestation for a source chain event, the designated source chain shard must wait for a pre-determined number of on-chain block confirmations to pass to ensure the transaction is final. This is essential for the integrity and security of the transaction.

For more details, see "Time to Finality."

• Estimation: The estimateMessageCost function computes fees based on the target network, message size, and gas limit.
• Dynamic Costs: Fees account for network-specific parameters (e.g., gas price, message size) stored in RouteStore.
• Payment: Users must attach sufficient funds when calling submitMessage, which is used to cover execution costs on the destination chain.

Refer to the Fee Management page for more details.

• Command Lookup Table: Batched commands (e.g., GMP, shard updates) use a lookup table (_cmdTableLookup) for constant-time dispatch, minimizing gas costs.
• Memory Reuse: Memory is recycled during batch execution to prevent exponential expansion costs.
• Gas Refunds: Excess gas is refunded to the caller after execution, incentivizing efficient batch submissions.

If the user calls the submitMessage and provides a low gasLimit, the GMP message will be delivered just fine. However, during execution, the message might return with an Out of Gas error, causing the user to be charged regardless.

On the other hand, if the user sets the gas limit to 100000, for example, but pays less than the relativeGasPrice*100000 when calling submitMessage, the gateway will reject the message and return an “insufficient tx value error,” reimbursing the user in the process.

It is the size of the payload in bytes.

A dApp/contract on the origin chain calls submitMessage() on its gateway contract. The origin chain's shard relays this message to the Timechain upon detecting an GmpCreated event and completing TSS operations. The Timechain then creates a GMP message for the destination shard, which executes it by calling execute() after validation. Refer to submitMessage() and execute() methods.

• Size Limit: Messages are capped at MAX_PAYLOAD_SIZE (defined in Primitives.sol). Exceeding this limit reverts the transaction.
• Cost Impact: Larger payloads increase gas fees, as estimated by estimateMessageCost.

• Status Tracking: Each message’s status (GmpInfo) is stored, with states like SUCCESS, REVERT, or PENDING.
• Retries: Failed messages (status REVERT) must be resubmitted with a new nonce. The contract does not auto-retry.
• Event Logging: The GmpExecuted event records the result, including error data for debugging.
  

• Query Function: Use gmpInfo(bytes32 id) to check the status (GmpStatus) and block number of a message.
• Events: The GmpCreated and GmpExecuted events emit message IDs, source/destination details, and execution results.

After finalization on the source chain (which varies by blockchain, see Time to Finality for more details), messages typically appear on the Timechain within 1-2 blocks.