Implemented in go-tkmchain

Wallet security that can enforce rules.

TKMChain smart accounts add multisignature approvals, spending limits, restricted session keys, delayed recovery, deterministic account creation, and application-sponsored transactions while staying compatible with the network's existing contract execution.

Explore features View pool treasury design Developer interface

AuthorizationOwners + sessions

RecoveryGuardian threshold

SponsorshipTarget allowlist

CompatibilityExisting transactions

Programmable protection for everyday accounts.

A smart account holds TKM and calls contracts like a normal account, but authorization is enforced by transparent contract rules instead of relying on one unrestricted key.

Authorization

Multisignature owners

Require several independently secured owners for high-value transfers and sensitive policy changes.

Policy

Spending limits

Set a daily native-TKM limit and a high-value threshold that activates stronger signature requirements.

Applications

Restricted session keys

Authorize one target, function selector, time window, per-call value, and total value without exposing the primary owner key.

Recovery

Delayed guardians

Recover lost access through a guardian threshold and mandatory delay, while existing owners retain time to cancel an attack.

Onboarding

Deterministic addresses

Calculate an account address before deployment through the factory's CREATE2 account creation process.

Safety

Emergency lock

Stop normal account execution through an authorized self-call while recovery or key rotation is handled.

Replay defense

Chain-bound operations

Every operation commits to its nonce, EntryPoint, chain ID, target, calldata, value, expiry, gas bound, and paymaster data.

Transparency

Open interfaces

Contract source, generated ABI, bytecode, RPC builders, CLI access, and security tests live together in go-tkmchain.

How an operation moves.

The feature stays above consensus. The final submission is an ordinary transaction that existing nodes validate using existing execution rules.

Build

A wallet uses tkmaccount helpers to construct calldata and a chain-bound operation hash.

Authorize

Owners or a narrowly restricted session key sign the operation. A sponsor may separately sign a paymaster permit.

Relay

A user or application relayer submits the signed operation to the EntryPoint as a normal contract transaction.

Enforce

The EntryPoint checks nonce, expiry, gas bound and sponsorship; the account checks signatures, limits, sessions, and lock state.

Execute

The account transfers TKM or calls the chosen contract. A revert rolls the entire operation and policy accounting back atomically.

A dedicated mining-pool treasury design.

The pool treasury contract inherits the full smart-account policy system and starts with the public pool wallet as its initial owner. No password or private credential is embedded.

TKMPoolTreasurySmartAccount is designed to separate long-term treasury control from automated payout activity. The owner can add independently secured signers, raise the signature threshold, configure guardians, set limits, and issue a short-lived payout session.

The payout process should receive only the authority it needs: one payout contract, one function selector, a maximum per payout, a total budget, and a short expiry. It should never receive permission to modify account owners or recovery policy.

Initial public pool owner

0x4441d6fEd0836B77a503e0B2788bfEd6FD8c23A8

Deployment status

The contract is compiled and tested but has not been deployed. Do not send pool funds to any claimed smart-account address until deployment, bytecode, EntryPoint, ownership, and low-value operations have been independently verified.

Step 1 — Separate keysAdd at least two owner keys stored on different secured devices.

Step 2 — Raise thresholdRequire two approvals for treasury policy and high-value movement.

Step 3 — Configure recoveryUse independent guardians with a 48-hour or longer recovery delay.

Step 4 — Limit payoutsSet daily and high-value limits before moving material pool funds.

Step 5 — Restrict automationGive the payout host a short session, limited selector, and finite budget.

Step 6 — Verify firstTest deposit, withdrawal, replay rejection, lock, revocation, and recovery cancellation.

Developer access through node and CLI helpers.

The helper layer builds hashes and calldata. It does not unlock accounts, hold keys, sign operations, or submit transactions.

gtkm --http --http.addr 127.0.0.1 \
  --http.api eth,net,web3,tkmaccount

gtkm smartaccount status \
  /home/mike/.tkmchain/gtkm.ipc

RPC namespace: tkmaccount
Version:       1.0.0
Consensus:     false
Hardfork:      false

Operation helpers

Build operation hashes, execution calldata, account creation data, owner authorization, and session authorization.

Policy helpers

Build owner, guardian, recovery, spending-limit, and session configuration calls.

Sponsorship helpers

Build chain-bound sponsor hashes and ABI-encoded short-lived sponsorship data.

Security review required before mainnet deployment

Successful compilation and local tests are not an independent audit. Contracts should complete external review, public testnet operation, invariant fuzzing, and a bug bounty before protecting material funds.