Problem
TON wallet contracts (WalletContractV5R1 in @ton/ton) require the raw Ed25519 public key to instantiate. Currently OWS exposes wallet addresses via getWallet() but not public keys.
The only workaround is calling exportWallet() to get the mnemonic, then re-deriving the keypair externally (BIP-39 + SLIP-10) just to extract the public key. This partially undermines the key isolation model — even though we immediately zero the secret key material, the mnemonic still passes through the calling process.
Context
We built an OWS integration for [ENACT Protocol](https://enact.info) — trustless escrow for AI agent commerce on TON. The signMessage() callback works perfectly: cell.hash() → OWS signs → 64-byte Ed25519 signature → @ton/ton accepts it via the signer callback in sendTransfer().
The only gap is public key access for wallet contract initialization. Currently we do:
const mnemonic = ows.exportWallet(walletName);
const seed = await bip39.mnemonicToSeed(mnemonic);
const derived = derivePath("m/44'/607'/0'", seed.toString('hex'));
const keyPair = nacl.sign.keyPair.fromSeed(derived.key);
const publicKey = Buffer.from(keyPair.publicKey);
// zero secret material immediately
derived.key.fill(0);
Buffer.from(keyPair.secretKey).fill(0);
This works, but it would be cleaner if OWS exposed the public key directly.
Related: #131 (signDigest for raw hash signing) addresses a similar need from the signing side.
Proposed API
getPublicKey(walletName: string, chainId: string): Buffer // 32-byte Ed25519 public key
Public keys are not secret — exposing them does not weaken the security model. This would eliminate the mnemonic round-trip entirely and keep key isolation clean.
Integration
Repository: https://github.com/ENACT-protocol/enact-protocol/tree/master/examples/ows-integration
Problem
TON wallet contracts (
WalletContractV5R1in@ton/ton) require the raw Ed25519 public key to instantiate. Currently OWS exposes wallet addresses viagetWallet()but not public keys.The only workaround is calling
exportWallet()to get the mnemonic, then re-deriving the keypair externally (BIP-39 + SLIP-10) just to extract the public key. This partially undermines the key isolation model — even though we immediately zero the secret key material, the mnemonic still passes through the calling process.Context
We built an OWS integration for [ENACT Protocol](https://enact.info) — trustless escrow for AI agent commerce on TON. The
signMessage()callback works perfectly:cell.hash()→ OWS signs → 64-byte Ed25519 signature →@ton/tonaccepts it via thesignercallback insendTransfer().The only gap is public key access for wallet contract initialization. Currently we do:
This works, but it would be cleaner if OWS exposed the public key directly.
Related: #131 (
signDigestfor raw hash signing) addresses a similar need from the signing side.Proposed API
Public keys are not secret — exposing them does not weaken the security model. This would eliminate the mnemonic round-trip entirely and keep key isolation clean.
Integration
Repository: https://github.com/ENACT-protocol/enact-protocol/tree/master/examples/ows-integration