Game of Domains: Crossing the Narrow Sea Results

Announcements
1

image
image1920×1080 257 KB

Crossing the Narrow Sea - Results & Community Audit Invitation

The first Trial of Innovation, Crossing the Narrow Sea, set out to validate Cross Domain Messaging (XDM) between the Taurus consensus chain and domain 0 (Auto EVM) under real conditions. Many of you jumped in - thank you. We’re now publishing the results, the code we used to compute them, and a clear path for anyone in the community to reproduce and audit the numbers.

:magnifying_glass_tilted_right: Invitation to audit: Results have been reproduced internally by multiple team members, but we want you to check our work. Please review, re-run, and tell us if you find any discrepancies - in this thread or via issues/PRs in the repo.

What we’re sharing

Event window & scoring

  • Campaign Window: From Taurus block 1,740,677 to block 2,460,732.
    • These consensus blocks derive domain blocks 1,060,691 and 1,561,826 respectively.
  • What counts: 1 point per successful XDM (consensus → domain or domain → consensus).
  • Policy: We use destination-only ACK mode - only transfers acknowledged by the destination chain are counted. Partial/failed attempts are excluded by design.
  • Rewards: Points are recorded on-chain and will be converted to AI3 after Game of Domains concludes.

The Crossing the Narrow Sea app

At a high level, the app does three things:

  1. Capture - scan consensus and domain over the defined block windows; persist events to SQLite and NDJSON
  2. Match - offline correlation by strict key (channel_id, nonce) in dest-only mode
  3. Aggregate - wallet-level counts by direction; export JSON

:blue_book: Deeper detail: The app’s README(s) in the repo explain environment variables, script commands, schema, and edge cases. Start there for exact setup and run instructions.

Reproduce the results locally

First, you will need access to a Taurus domain archive RPC node. The rate limits on the public RPC endpoints will prevent the app from running. You have two good routes:

Option A - Sync from genesis (maximum assurance)

Run your own archive node for consensus and domain 0.

Option B - Restore from snapshot (fastest to start)

Use our Taurus archive snapshot (consensus + domain 0) to get an auditing node running quickly, then execute the same capture → match → aggregate steps.

:warning: Snapshot trust: Snapshots are a convenience, not a substitute for syncing from genesis. Always verify checksums and only use snapshots from sources you trust. For full assurance, re-run the pipeline on a self-synced archive.

Once you have an archive node available you can follow the app’s quick start guide to:

  • capture consensus (capture:consensus) and domain (capture:domain) flows,
  • run the offline match step,
  • aggregate to per-wallet scores with the count step.

You may also want to adjust the BLOCK_CONCURRENCY variable. BLOCK_CONCURRENCY=80 worked well for running against a local node and sped things up considerably.

How to report discrepancies

Transparency is the point. If anything looks off:

  • Open an issue/PR with a minimal reproduction guide (block/tx hashes, expected vs. observed, node version, node start command/flags): GitHub · Where software is built
  • Or reply under this post, in Discord or Telegram and we’ll investigate.

What’s next

This was the first Trial of Innovation. We’ll continue to run focused trials, publish code/results, and invite audits as we progress through the Game of Domains. Your feedback directly shapes performance, UX, and security across the stack.

Thank you to everyone who crossed the Narrow Sea with us - now help us verify every last wave :ocean:

2

I don’t know anything else. My address: 0xA787430FABad34Aa48426D35bb457164a12fc8C9. I must have made at least one D2C transfer and it was within the statistical time. But now it has been found that this HTML statistic does not reflect it. Because of this address. Discovered token recast issue with E2C transfer.

6b191babd93450b0a8c1e21c73fb3baf
6b191babd93450b0a8c1e21c73fb3baf1844×864 42.7 KB

1:0xA787430FABad34Aa48426D35bb457164a12fc8C9

2:0xD47A71Fe1bA1116d5c26aB6b914194aA216Fd989

3

And I’m sure I used D2C transfer more than once at that time. Because of multiple transfers. Identify issues. I just went to the forum to give a detailed report.

4

In my memory. This account has at least 30-50 D2C transfers. There are about 10-20 successful coin deductions, and there are also about 10-20 unsuccessful coin deductions. After the bug fix is completed. There are probably 2-3 D2C transfers as well. But there hasn’t been a single record. Then there must be an issue with the statistical table.

5

Engineers have taken a deeper look at both of these addresses and while some transfers were requested from the domain none of them successfully completed. If you have details to the contrary we’ll happily take another look.

6

Thank you for the detailed inspection by the engineer. This is the spirit of blockchain. Every transaction is traceable on the chain.

Firstly, it can be confirmed that. This is definitely not a failure for all transfers. That is to say, there are no transfer records. Because before fixing the bug. My account has undergone multiple D2C transfers. Otherwise, we wouldn’t have discovered the bug. And after fixing the bug. I must have also conducted test transfers. Otherwise, I will continue to report bugs. So its successful transfer record is definitely not zero

1 Like
7

Actually, we all know. The authenticity of the 1 or 20 transactions I am pursuing. It’s for science, not just for the profits obtained from this transfer. The rigor of BTC is: fixed at 21 million. Every transaction can be traced back.
It’s definitely not just about “big difference”, “almost enough”, or “similar”

We need to trace the transfer records of this Taurus. It’s to prevent the same mistakes from happening again on Chronos. If we want to trace Taurus D2C, we need to trace where it was transferred to? Which successes and which failures? What are the successful ‘dual coinage’.
And how many C2D transfers have been generated from these ‘dual coinage’ transactions. How many records have been obtained.
This is the true ‘traceability’.

I actually predicted this a long time ago: it cannot be completed!

So I just hope this’ crossing the strait 'ends soon. The reward to be distributed should be distributed earlier, instead of “guess”, “I have the right to explain”, “the project party the final say”

Everything will be based on Chronos in the future. Make a very ‘rigorous’,’ scientific ‘, and’ fair 'blockchain. There will no longer be “big difference”, “the project party has the final say”, “the right to interpret the decision is in the project party”

But there is a distributed system that is “fair,” “open,” and "trusted by the public

8

I am also experiencing issues with accessing the wallets listed on the leaderboard.

I used the exact same mnemonic phrase for each of the following wallets:

  • Talisman - EVM wallet (hereafter - address1)

  • The script for transferring tokens from the domain to the consensus (hereafter - address2).

This same phrase was also used to access the wallet in the network’s consensus layer.

While developing the script, I consulted with Mark about the fact that the address in Talisman EVM and the address generated by the script were different. He told me that this can happen and it was not a problem. He also suggested, as one option, to transfer the tokens from “address1” to “address2” and only then run the script. This is exactly what I did.

However, now:

  • Mark is no longer with the team;

  • The mnemonic phrase does not generate the wallet addresses that I obtained when the script was run.

9

It is by design that the Auto SDK EVM wallet generation uses a different default derivation path to the BIP44 standard wallets like Talisman and MetaMask use. This behaviour is inherited from the Polkadot SDK and we’ve recently updated the Auto SDK to highlight the way this works and added a derivation path parameter to the function that creates wallets: feat: add optional derivationPath for Ethereum HD wallets by jfrank-summit · Pull Request #483 · autonomys/auto-sdk · GitHub

You’ve raised this issue previously and I’ve tried to reproduce your problem using every release of the Auto SDK since Ethereum wallet features were introduced but have not been able to.

Thinking pragmatically, the only two ways to get a different address would be:

  1. A different seed phrase was used
  2. A different derivation path was used

We’re going to need an example of the behaviour you describe to investigate further. Ideally a simple test script that demonstrates it.

10
  1. I had multiple wallets (one wallet per computer). It was more convenient for me to track which computer was failing to process transactions. Moreover, this was not prohibited. However, none of these wallets can now regenerate the 0x-formatted address that was generated by the script during the “Crossing the Narrow Sea” event.
  2. What do you mean by “different derivation path”? When I try to run the scripts (which I saved in the exact state they were in during the event), I get a message that Taurus has ended and it is recommended to use either Mainnet or Chronos. This means the script is essentially non-functional now. When I attempt to switch the network from Taurus to “Chronos” or “Mainnet”, the script starts working (at least partially) and produces the same wallet address as the Talisman EVM wallet.

Could you please provide more detailed explanation of what you mean?

11

It’s possible to provide a suffix on the seed phrase - a derivation path. They change the address generated. Did you discuss adding anything to the end of the mnemonic with Marc?

Could you provide the script exactly as it was used (make sure to remove any seed phrase or private key details).

My understanding is that the network the SDK connects to is irrelevant - wallet generation behaviour should be consistent across all networks.

This is interesting. Does MetaMask give you the same address as Talisman when you import the seed phrase?

To investigate the issue we need to be able to reproduce it and at the moment we’re unable to. A script that demonstrates generating unexpected addresses will mean we can support effectively.

12

After examining my message history with Mark, I found nothing of this nature.

Sure. I’ll DM you on Discord later.

Yep!)

Снимок экрана 2025-11-06 в 22.39.40
Снимок экрана 2025-11-06 в 22.39.401418×890 142 KB

13

Upd. The wallet address 0x4729D00834d9A605c9e690AcaCC87aB6e126eBaF is also mine, but it only appears on the list because I processed transactions manually through polkadot.js.

14

Here is the script provided via DM:

import { activateWallet } from '@autonomys/auto-utils';
import { transferToConsensus } from '@autonomys/auto-xdm';

(async () => {
  try {
    // 1. Активация кошелька
    const wallet = await activateWallet({ 
      networkId: 'chronos', 
      domainId: '0', 
      type: 'ethereum',
      uri: 'alice' // Gol31
    });

    // 2. Проверка аккаунтов
    if (!wallet.accounts || wallet.accounts.length === 0) {
      throw new Error('No accounts found in wallet');
    }

    // 3. Получаем первый аккаунт как подписывающий
    const signer = wallet.accounts[0];
    const evmAddress = wallet.accounts[0].address;
    console.log('EVM адрес кошелька:', evmAddress);

    // 4. Создаём и отправляем транзакцию
    const transfer = await transferToConsensus(
      wallet.api,
      'subVteLcPGSZJy8By5c8VRdm1pKBYFeY7PC7jAXn1SqEZh5dj', // gol31
      '10000000000000' // Сумма
    );

    const transferResult = await transfer.signAndSend(signer);

    console.log('Хэш транзакции:', transfer.hash.toHex());
    console.log('Результат транзакции:', transferResult);

    // 5. Отключаемся
    await wallet.api.disconnect();
  } catch (error) {
    console.error('Ошибка:', error);
    process.exit(1);
  }
})();
15

There’s a reasonable primer on derivation paths here: https://ethereum.stackexchange.com/a/70029

According to How to import a seed phrase from another wallet | MetaMask Help Center

MetaMask only supports the default BIP-44 derivation path (m/44’/60’/0’/0)

Which is different to the default derivation path that the Auto SDK produces so something does not add up that you’re getting the same address as MetaMask from the seed phrase when using Auto SDK. Unless I’m misunderstanding.

I know I asked you this via DM but for any other reader’s benefit could you confirm that you are replacing this line with the real mnemonic - a 12 or 24 word seed phrase with nothing on the end of it?

16

Yes, a 12-word phrase instead of ‘alice’.

17

I might be getting ahead of myself, but we have outgoing D2C transactions and outgoing C2D transactions. While D2C is clear and straightforward (users have already received testnet rewards for these wallets), C2D raises some questions.

This led me to a small suggestion. What if we count C2D not by the number of OUTGOING SUCCESSFUL transactions, but by the number of INCOMING transactions to the consensus wallet? After all, a testnet participant is unlikely to transfer tokens to other people’s wallets. As I understand it, the script compares the “success” of transactions in either direction anyway, so maybe we could modify the script to track where the transaction was sent? Ultimately, a transaction is worth 1 point regardless of its direction.

18

Your logic is incorrect. Because most of the time. D2C is actually a failure. So we discovered the double coinage bug

19

I appreciate why you’re suggesting this but it appears to be more work for less accurate results.

20

It just so happens in my case that:

  • 90,000 transactions that I sent several days before the end of the event and that got stuck because the network stopped producing blocks were not counted. Despite the fact that I, for my part, fulfilled all the event conditions: with an estimated transaction processing time of 24 hours and an actual time of slightly more, around 30 hours, I sent the transactions approximately 100 hours before the event ended.

  • The wallet addresses, which I cannot reproduce but whose seed phrases I own, are also potentially excluded from my reward pool. Even though in this case, I acted based on advice from one of the team members, albeit a former one at this point.

So what am I supposed to do in this situation?)
Of course, I will be suggesting some options)