Connect a Wallet

Native wallets (sign here)

Asentum accounts use ase1 bech32 addresses and sign every transaction with ML-DSA-65 (Dilithium3), a post-quantum signature scheme. This is different from Ethereum, which uses 0x addresses and ECDSA. Because of that difference, an EVM wallet like MetaMask cannot sign Asentum transactions. To hold ASE, send transactions, and connect to Asentum dapps, use one of the native wallets below. Each one generates your keypair, shows your ase1 address and balance, and prompts you to approve every transaction.

• Chrome extension. The Asentum Wallet browser extension: create accounts, sign, and connect to dapps via the injected window.asentum provider. See Chrome extension.
• Telegram wallet. A custodial-free wallet you drive from Telegram, for quick sends and balance checks. See Telegram wallet.
• Operator desktop app. Runs a full node and includes an in-app wallet with live balance and send. See Desktop app.
• Programmatic signing. For scripts and backends, the Asentum SDK signs with ML-DSA-65 for you (see below).

JSON-RPC compatibility

Asentum exposes a JSON-RPC interface compatible with the Ethereum tooling ecosystem. This is what makes Ethereum libraries and explorers useful for reading Asentum. The supported subset includes:

• eth_blockNumber
• eth_getBalance
• eth_call
• eth_sendRawTransaction
• eth_getTransactionReceipt
• eth_chainId
• eth_getLogs
• and most other read methods you would expect.

Two caveats matter. First, Asentum is JSON-RPC compatible, not bytecode compatible. Solidity contracts compiled to EVM bytecode do not run on Asentum. Contracts are written in plain JavaScript, see Smart Contracts.

Second, writes need an ML-DSA-65 signature. eth_sendRawTransaction accepts an already-signed Asentum transaction, but an EVM wallet cannot produce that signature (it signs with ECDSA). So the compatibility surface is genuinely read-first: sign with a native wallet or the SDK, then broadcast.

EVM tools (read-only)

ethers.js, viem, and raw JSON-RPC are useful for reading Asentum from application code with familiar APIs: block numbers, balances, view calls, and logs. Point the provider at the Asentum RPC URL and query. They cannot sign or send native transactions, so treat them as a read layer and hand signing to a native wallet or the SDK.

Note on MetaMask and other EVM browser wallets: you can point them at the Asentum RPC, but they derive ECDSA 0x accounts and sign with ECDSA, neither of which matches Asentum's ase1 addresses or ML-DSA-65 signatures. They are not a way to manage an Asentum account. Use a native wallet above for that.

ethers.js v6, read access:

import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('https://testnet.asentum.com');
const blockNumber = await provider.getBlockNumber();
const balance = await provider.getBalance('0x...'); // read only

viem, read access:

import { createPublicClient, http } from 'viem';

const client = createPublicClient({
  transport: http('https://testnet.asentum.com'),
});

const blockNumber = await client.getBlockNumber(); // read only

The chain id is locked at 1418. Manual RPC config: name Asentum (testnet), RPC https://testnet.asentum.com, chain id 1418, currency ASE.

Asentum SDK

For scripts and backends that need to sign, or that use Asentum-specific features (the JS contract model, async message-passing, transaction bundles, delegation), use the official @asentum/sdk:

import { Chain, Wallet, Contract } from '@asentum/sdk';

const chain = new Chain({ rpc: 'https://testnet.asentum.com' });
const wallet = await Wallet.fromKeystore('./my-key.json');
const contract = await chain.contract('ase1...');

// Async message-passing call, signed with ML-DSA-65
const result = await contract.transfer('ase1...', 100n);

The SDK handles ML-DSA-65 signing transparently, so you do not have to think about post-quantum cryptography in application code. This is the programmatic equivalent of a native wallet.

Differences from Ethereum

The wire format and call interface look enough like Ethereum that existing read tooling works, but there are real differences under the hood:

• Addresses are ase1 bech32, derived as bech32("ase", BLAKE3(pubkey)[0:20]), not Keccak256 hex.
• Signatures are ML-DSA-65 (Dilithium3), not ECDSA. Each signature is ~3.3 KB instead of 65 bytes. Each public key is ~1.9 KB instead of 33 bytes. This is why EVM wallets can read but cannot sign.
• Smart contracts are JavaScript, not EVM bytecode. ABI is generated from the JS contract module, not from a Solidity compiler.
• Finality is GRANDPA. Stake-weighted two-thirds finality means no chain reorgs. Finality trails the head by a few blocks, and once a block is finalized it is never reverted.
• Transaction bundles are first-class. A single transaction can carry an atomic sequence of contract calls, with no intermediary bundler service.