# Technical Whitepaper
### AdventureWurld Technical Whitepaper
{% hint style="info" %}
**Disclaimer**
This document is a technical reference. Contract addresses, network parameters, multisig configurations, and governance contracts reflect the state of the AdventureWurld network as of the date issued. The platform is in active development and governed by the DAO, so configurations, contracts, and parameters may change.
{% endhint %}
*GULD Token · Multi-Chain Infrastructure · Decentralized Governance*
## 1. Executive Summary
This whitepaper documents the full technical architecture of the AdventureWurld network, including all smart contract addresses, bridge infrastructure, multi-signature custody arrangements, governance contracts, and token mechanics. It is intended as a reference document for custodians, technical integrators, and governance participants.
## 2. Network Overview
AdventureWurld operates two network environments: a Testnet for development and staging, and a Mainnet for production activity. Both networks are built on the BlockFabric infrastructure stack and are accessible via dedicated RPC endpoints.
### 2.1 Network Parameters
| Parameter | Testnet | Mainnet |
| --------------------- | ---------------------------------------------------- | -------------------------------------------- |
| Network Name | AdventureWurld Testnet | AdventureWurld Mainnet |
| Network ID / Chain ID | 5966 | 24202723 |
| RPC URL | | |
| Block Explorer | | |
## 3. Token Architecture — GULD
The GULD token is the native digital asset of the AdventureWurld ecosystem. It is a multichain token, enabled by synthetic representations (i.e. ERC-20 token contracts) deployed on Ethereum, Binance Smart Chain, and Base with additional on-chain and off-chain bridging infrastructure to facilitate token movement between chains. The native GULD token can be bridged to public chains via the PrivateChainBridge smart contract.
### 3.1 Token Details
GULD Token Identity
Token Name: GULD
Token Symbol: GULD
Deployed Networks: AdventureWurld Mainnet, Ethereum, Binance Smart Chain, Base
Distribution Start: October 1, 2025
## 4. AdventureWurld Mainnet — Smart Contracts
The following contracts are deployed on the AdventureWurld Mainnet (ChainID: 24202723) and govern core protocol functions including bridging, token custody, distribution, governance, and gas operations.
### 4.1 Bridge & Custody Infrastructure
| Contract / Role | Address |
| ---------------------------- | ------------------------------------------ |
| PrivateChainBridge | 0x14d6c649292c5c9790c5196d1a9ea039307947a1 |
| Bridge Fee Receiver | 0x18946817369E5D6Aa4b3894C298319aEbf01F857 |
| Token Vault | 0xD48faec2075a2b35C719B4C985fecab2cB7c44e5 |
| Multisig SAFE (Bridge Owner) | 0xE8f86dF9DdF417C47e99C239409e517C6f453D95 |
### 4.2 Distribution & Lockup
| Contract / Role | Address |
| ------------------------- | ------------------------------------------ |
| Lockup Contract | 0x47e9Fbef8C83A1714F1951F142132E6e90F5fa5D |
| Distribution Contract | 0x8Be503bcdEd90ED42Eff31f56199399B2b0154CA |
| Distribution Issuer (EOA) | 0x499b7F4E84D7ABf93D4f00D80B2ef5310630b1Aa |
### 4.3 Gnosis Safe Multisig
| Contract / Role | Address |
| ---------------- | ------------------------------------------ |
| Gnosis Singleton | 0x3E5c63644E683549055b9Be8653de26E0B4CD36E |
| Gnosis Multisig | 0x1aE42a80dAE5D3A1AB06673fCCeFe7a887D024b4 |
### 4.4 Decentralized Governance Framework (DGF)
The DGF governs node ownership and network-wide voting. The approver role is held by a designated custodian via a hardware-secured wallet.
| Contract / Role | Address |
| ---------------------------- | ------------------------------------------ |
| NodeOwnership Contract (DGF) | 0xD5ba686D221d11AC765fFb916Ddf679066eC4e8d |
| GlobalVoting Contract (DGF) | 0xBe6BA981BcE5f22923F930acdA824Afae3B72335 |
| DGF Approver | 0x04Dd1C24e89a34D1373e147Ff3FAd3E4Fe7cCCC1 |
### 4.5 Ledger / Gas Operations
These contracts support day-to-day operational functions including gas provisioning and on-chain action execution.
| Contract / Role | Address |
| ------------------------------ | ------------------------------------------ |
| Gas Tank | 0x9D2aACA8C3f01F9378fD45235Eb75E134fe70ED4 |
| Action Contract | 0xD5Db7829C37eCe36F355257D2F1C3d3a615b1809 |
| Distribution Contract (Ledger) | 0xf107d54CD2e5A0b96f4f6641454cFfF663df020B |
## 5. Public Bridge — Ethereum Mainnet
The Ethereum public bridge enables GULD tokens to be transferred between the AdventureWurld Mainnet and the Ethereum network. The bridge and token contracts are owned and configurable by a 2-of-3 Multisig SAFE
### 5.1 Ethereum Bridge Contracts
| Contract / Role | Sepolia (Testnet) | Ethereum (Mainnet) |
| ---------------------------- | ------------------------------------------ | ------------------------------------------ |
| PublicBridge | 0xe6d50fF90532fF1926D32B8B4a757Cb44af128E5 | 0xe6d50fF90532fF1926D32B8B4a757Cb44af128E5 |
| Token Vault | 0xDA46EE2535641B2F1411a7B11904e6085395EE37 | 0xDA46EE2535641B2F1411a7B11904e6085395EE37 |
| ERC-20 Token (GULD) | 0x14d6c649292c5c9790c5196d1a9ea039307947a1 | 0x14d6c649292c5c9790c5196d1a9ea039307947a1 |
| Multisig SAFE (Bridge+Token) | — | 0x49b9D4a14c21f01f92644662508FF0228C941bD8 |
| Bridge Fee Receiver | — | 0x18946817369E5D6Aa4b3894C298319aEbf01F857 |
### 5.2 Ethereum Multisig Signers
| Signer | Address |
| -------- | ------------------------------------------ |
| Signer 1 | 0x5c0125c76066215666DFe4751Dd38e484226BCc2 |
| Signer 2 | 0x2312255e6D97D29F9CC623cB2fF7356318E37108 |
| Signer 3 | 0x0079466ED382CC6C60E8a8380d1E8c1b2Cf47A71 |
## 6. Public Bridge — Binance Smart Chain
The BSC bridge enables GULD tokens to circulate on Binance Smart Chain. The bridge and token ownership are jointly controlled by a dedicated Multisig SAFE with the same three signers as the Ethereum bridge.
### 6.1 BSC Bridge Contracts
| Contract / Role | BSC Testnet | Binance Mainnet |
| ---------------------------- | ------------------------------------------ | ------------------------------------------ |
| PublicBridge | 0xe6d50fF90532fF1926D32B8B4a757Cb44af128E5 | 0xe6d50fF90532fF1926D32B8B4a757Cb44af128E5 |
| Token Vault | 0xDA46EE2535641B2F1411a7B11904e6085395EE37 | 0xDA46EE2535641B2F1411a7B11904e6085395EE37 |
| Token — GULD | — | 0x14D6C649292c5c9790c5196D1a9EA039307947a1 |
| Multisig SAFE (Bridge+Token) | — | 0x2CC70734CbafB4AF7373A77fDc3dE250557a4A79 |
| Bridge Fee Receiver | — | 0x18946817369E5D6Aa4b3894C298319aEbf01F857 |
### 6.2 BSC Multisig Signers
| Signer | Address |
| -------- | ------------------------------------------ |
| Signer 1 | 0x5c0125c76066215666DFe4751Dd38e484226BCc2 |
| Signer 2 | 0x2312255e6D97D29F9CC623cB2fF7356318E37108 |
| Signer 3 | 0x0079466ED382CC6C60E8a8380d1E8c1b2Cf47A71 |
## 7. Public Bridge — Base
The Base bridge provides GULD token interoperability on the Base Layer-2 network. It shares the same token contract address as the BSC deployment and uses a dedicated Multisig SAFE for ownership management.
### 7.1 Base Bridge Contracts
| Contract / Role | Base Sepolia (Testnet) | Base (Mainnet) |
| ---------------------------- | ------------------------------------------ | ------------------------------------------ |
| PublicBridge | 0xe6d50ff90532ff1926d32b8b4a757cb44af128e5 | 0xe6d50ff90532ff1926d32b8b4a757cb44af128e5 |
| Token Vault | 0xDA46EE2535641B2F1411a7B11904e6085395EE37 | 0xDA46EE2535641B2F1411a7B11904e6085395EE37 |
| Token (GULD) | — | 0x14D6C649292c5c9790c5196D1a9EA039307947a1 |
| Multisig SAFE (Bridge+Token) | — | 0xB930802a16BD4b823D6E0a380101f63007547dC9 |
| Bridge Fee Receiver | — | 0x18946817369E5D6Aa4b3894C298319aEbf01F857 |
### 7.2 Base Multisig Signers
| Signer | Address |
| -------- | ------------------------------------------ |
| Signer 1 | 0x5c0125c76066215666DFe4751Dd38e484226BCc2 |
| Signer 2 | 0x2312255e6D97D29F9CC623cB2fF7356318E37108 |
| Signer 3 | 0x0079466ED382CC6C60E8a8380d1E8c1b2Cf47A71 |
## 8. Cross-Chain Architecture Summary
AdventureWurld employs a hub-and-spoke bridging model. The AdventureWurld Mainnet serves as the canonical hub. All GULD tokens on external networks (Ethereum, BSC, Base) are backed 1:1 by assets locked in the corresponding Token Vault on each chain.
Key architectural properties include:
• Unified token contract address across BSC and Base deployments
• Shared bridge fee receiver address across all three public chains
• Consistent 3-signer multisig governance on all public bridges
• Separate Multisig SAFE per public chain for isolation and security
• PrivateChainBridge contract manages the Mainnet side of all cross-chain transfers
## 9. Governance Framework
AdventureWurld governance is managed through the Decentralized Governance Framework (DGF), consisting of two on-chain contracts: the NodeOwnership Contract and the GlobalVoting Contract. These enable weighted governance participation based on node ownership.
### 9.1 DGF Roles
| Role | Contract / Address | Notes |
| -------------- | ------------------------------------------ | --------------------------------------------------- |
| Node Ownership | 0xD5ba686D221d11AC765fFb916Ddf679066eC4e8d | Manages DGF node registration and ownership records |
| Global Voting | 0xBe6BA981BcE5f22923F930acdA824Afae3B72335 | Facilitates network-wide governance votes |
| DGF Approver | 0x04Dd1C24e89a34D1373e147Ff3FAd3E4Fe7cCCC1 | Admin role held by Blockade |
The DGF Approver address is held on a Ledger hardware device, ensuring that the most privileged governance action remains air-gapped from hot wallet risk. All proposals that are submitted must be reviewed and approved by the Approver role prior to going live for a vote. The Approver will also set the start and end dates of the vote.
## 10. Security & Custody Model
AdventureWurld employs a layered custody model across all critical protocol functions. The following principles underpin the security architecture:
### 10.1 Multi-Signature Controls
All bridge and token ownership on public chains is managed through Gnosis SAFE multisig contracts. The current signing quorum requires 2 of 3 designated signers to authorize any transaction affecting bridge contracts, token ownership, or vault withdrawals. This prevents single points of failure and requires collusion of multiple custodians to execute sensitive operations.
### 10.2 Hardware Wallet Custody
The DGF Approver role — the highest-privilege governance function on the AdventureWurld network — is held exclusively on a Ledger hardware wallet. This ensures the key never exists in memory on a networked device, and all DGF approval transactions must be physically confirmed on the device.
### 10.3 Separation of Concerns
Bridge fee collection, token vault management, distribution issuance, and governance approval are held by distinct addresses. This limits the blast radius of any single key compromise and provides a clear audit trail of on-chain activity by function.
### 10.4 Testnet Isolation
All protocol components have corresponding testnet deployments on Sepolia (Ethereum), BSC Testnet, and Base Sepolia. Production contracts are never used for testing, and testnet deployments use equivalent contract logic to enable safe pre-production validation.
## 11. Related Resources
| Resource | URL / Reference |
| -------------------------- | ---------------------------------------------------- |
| AdventureWurld Mainnet RPC | |
| AdventureWurld Testnet RPC | |
| Block Explorer | |
| DGF Website | |
| | |
## 12. Disclaimer
This document is provided for informational and technical reference purposes only. All contract addresses, network parameters, and governance configurations were accurate as of the Distribution Start Date of October 1, 2025. Recipients are advised to verify all on-chain data independently. This document does not constitute financial, legal, or investment advice. Unauthorized distribution is prohibited.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://adventurewurld.gitbook.io/adventurewurld-docs/adventurewurld-litepaper/how-it-works/technical-whitepaper.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.