A non-custodial AI agent marketplace for BNB Chain with independent GenLayer SLA and evidence adjudication.
Live App: TODO — add Vercel URL after deployment
Repository: TODO — add GitHub repository URL
Demo Video: TODO — add demo video URL
BNB AgentHub is a marketplace for discovering, comparing, verifying, and hiring autonomous DeFi agents.
The application combines two distinct blockchain roles:
- BNB Chain / BNB Agent Studio: agent discovery, hiring, job creation, escrow, execution lifecycle, and settlement through the official BNB Agent SDK and ERC-8183/Apex commerce stack.
- GenLayer: independent, consensus-backed adjudication of whether the evidence produced by an agent actually satisfies its promised SLA and task requirements.
The central workflow is:
Discover Agent
↓
Review Identity + Capabilities
↓
Configure Hiring Parameters
↓
BNB ERC-8183 Job
↓
Fund / Execute Task
↓
Collect Real Evidence
↓
Independent GenLayer Evaluation
↓
Consensus-backed Verdict
The core product principle is:
If the blockchain cannot prove it, the application should not pretend it happened.
Autonomous agents can perform useful DeFi tasks, but users need more than an agent profile and a button that says "Hire."
They need to know:
- Who the agent is.
- Whether it is actually available.
- What the agent claims it will do.
- How much the task is expected to cost.
- Whether a real on-chain job was created.
- Whether funds were actually committed.
- Whether the agent actually completed the task.
- Whether the evidence supports the completion claim.
- Whether an independent system agrees that the SLA was satisfied.
BNB AgentHub addresses the commerce side with BNB AgenticCommerce/ERC-8183 and addresses the evidence/adjudication side with GenLayer.
This creates a complete:
Discover → Hire → Execute → Prove → Adjudicate
workflow.
BNB AgentHub is designed for the BNB Agent Studio / BNB Chain agent marketplace use case.
The marketplace gives equal first-class support to the four required categories:
Parameters:
- Target assets
- Target allocation ratios
- Drift threshold
- Slippage limit
Expected evidence:
- Asset drift
- Allocation before/after
- Rebalance transaction references
- DEX guardrail checks
Evidence type:
REBALANCE_CHECK
Parameters:
- Trading pair
- Lower price
- Upper price
- Grid level count
Expected evidence:
- Price channel bounds
- Grid configuration
- Order ladder
- Relevant transaction/log evidence
Evidence type:
GRID_SETUP
Parameters:
- Target asset
- Target protocol
- Minimum acceptable APY
Expected evidence:
- Protocol/vault selection
- APY observation
- Routing transaction
- Vault configuration
Evidence type:
YIELD_VAULT_ROUTED
Parameters:
- Monitored protocol
- Monitored address
- Health-factor threshold
Expected evidence:
- Observed health factor
- Threshold
- Timestamp
- Block number
- Alert transaction
- Event/log evidence
- Alert payload
Evidence type:
SENTINEL_REGISTERED
Missing protocol-specific evidence remains UNAVAILABLE; the application does not fabricate it.
Users can browse agents and inspect:
- Agent identity
- Agent category
- Availability
- Capabilities
- Hiring requirements
- Declared pricing
- Risk/safety information
- Evidence requirements
Each agent profile provides a dedicated hiring entry point.
The user can review the task before any wallet transaction is requested.
The hiring flow provides:
- Category-specific parameters
- Budget
- Deadline
- Provider
- BNB evaluator information
- Payment-token information
- Wallet/network preflight
- Explicit transaction confirmation
After a genuine transaction:
- Canonical ERC-8183 Job ID is displayed.
- Transaction hashes are displayed separately.
- Job state is read from the BNB commerce contract/SDK.
- Local state cannot falsely promote a job to a verified state.
After genuine task evidence exists, the user can invoke:
Independent GenLayer Evaluation
The evaluation panel displays:
- SLA requirements
- Actual evidence
- Evidence provenance
- GenLayer transaction status
- Consensus result
- Finalization state
USER
│
▼
┌───────────────────┐
│ BNB AgentHub │
│ Marketplace │
└─────────┬─────────┘
│
EIP-1193 Wallet
│
┌──────────────┴──────────────┐
│ │
▼ ▼
BSC Testnet GenLayer Bradbury
Chain 97 Chain 4221
│ │
▼ ▼
┌──────────────────┐ ┌────────────────────┐
│ AgenticCommerce │ │ AgentAdjudicator │
│ ERC-8183 / APEX │ │ Intelligent │
│ │ │ Contract │
└────────┬─────────┘ └─────────┬──────────┘
│ │
▼ ▼
Job + Budget + Fund SLA + Evidence
+ Submit + Settle │
│ ▼
▼ GenLayer
Real Evidence Consensus
│ │
└──────────────┬───────────────┘
▼
Independent Result
BNB AgentHub uses the official @bnbagent/sdk.
Current pinned SDK:
@bnbagent/sdk 0.5.1
The application intentionally avoids maintaining a second, competing ABI/address implementation where the official SDK provides the authoritative functionality.
The BSC Testnet SDK configuration currently resolves to:
| Component | BSC Testnet |
|---|---|
| Chain ID | 97 |
| AgenticCommerce | 0xa206c0517B6371C6638CD9e4a42Cc9f02A33B0DE |
| EvaluatorRouter | 0xD7d36D66d2F1B608A0F943f722D27e3744f66F25 |
| OptimisticPolicy | 0xd6a4217588F6B1F5657a92A3e94E6422aD771cEA |
| Payment token | 0xc70B8741B8B07A6d61E54fd4B20f22Fa648E5565 |
The official SDK/network registry is treated as the source of truth.
References:
- BNB Agent SDK: https://github.com/bnb-chain/bnbagent-sdk
- APEX contracts: https://github.com/bnb-chain/apex-contracts
- BNB Agent SDK network documentation: https://docs.bnbchain.org/developer-kit/bnbagent-sdk/networks/
The hiring adapter follows the BNB SDK lifecycle:
createJob
↓
registerJob
↓
setBudget
↓
fund
↓
JOB ACTIVE
↓
submit
↓
settle
The application performs on-chain read-back after lifecycle writes.
A successful transaction receipt alone is not treated as proof of a particular business state.
For example:
Transaction succeeded
≠
Escrow definitely funded
The application reads the job state from the commerce layer before presenting an authoritative lifecycle state.
One of the project's important integrity corrections was separating transaction hashes from canonical ERC-8183 job IDs.
The canonical ID is obtained from:
createJob().jobId
or authoritative SDK event/receipt recovery.
It is not derived from the transaction hash.
The application distinguishes:
| Identifier | Meaning |
|---|---|
| ERC-8183 Job ID | Canonical on-chain job identifier |
| Transaction Hash | Blockchain transaction reference |
| Local Correlation ID | Application-level tracking identifier |
If the canonical job ID cannot be obtained, the value is treated as:
UNAVAILABLE
The application does not invent a job ID.
BNB AgentHub deliberately does not replace BNB's evaluator architecture with GenLayer.
The roles are:
BNB EvaluatorRouter
│
└── Native BNB/ERC-8183 evaluation mechanism
GenLayer AgentAdjudicator
│
└── Independent SLA/evidence adjudication
This distinction is important.
GenLayer is not pretending to be the native ERC-8183 evaluator.
Instead, it provides an independent second layer that can assess whether the evidence supports the claimed task outcome.
The historical GenLayer contract below is the rejected V2 deployment and must remain unused. It is retained for audit history only; the corrected V2 source is not deployed yet:
0xC1B14E5e8C165e0626DFc5BCcf381492FaD44305
Network:
GenLayer Bradbury Testnet
Chain ID: 4221
Deployment transaction: 0xcd74805b7f5dfebfe8ec0bd7a0254cfef7cfc4a96618369bbf28451bbdca0a28
Status: FINALIZED
The legacy AgentAdjudicator at 0x3DD70fe392Db5958C486531427A580367843F3Da is labeled LEGACY and is preserved unchanged for historical compatibility only. It is not the active V2 adjudicator.
No private key is stored by the application.
The corrected V2 must be deployed separately after the HTTPS evidence bridge is live and independently verified. No deployment or transaction is performed by this repository workflow.
GenLayer is part of the main application workflow rather than a decorative feature.
The marketplace creates a real-world problem:
An agent says it completed a task. What evidence proves that claim?
AgentHub sends structured requirements and available evidence to the GenLayer AgentAdjudicator.
The adjudicator can then determine whether the evidence supports the claim.
Conceptually:
Requirements
+
Verified Evidence
↓
GenLayer Intelligent Contract
↓
Validator Consensus
↓
Verdict
Possible outcomes include:
FULFILLEDDISPUTEDINCONCLUSIVEUNAVAILABLEFAILED- Pending/finalization states
A disputed result is not automatically a software error.
It means the available evidence did not satisfy the adjudication requirements.
The Evidence Bridge converts a BNB job into a deterministic GenLayer evaluation request.
It separates:
What the agent was expected to do.
Examples:
- Task category
- SLA deadline
- Required action
- Required threshold
- Required output
- Required evidence
What can actually be verified.
Examples:
- Transaction hashes
- Block numbers
- Logs
- Timestamps
- Protocol observations
- Agent output
- Alert payloads
- Evidence manifests
This prevents a statement such as:
"The agent completed the task"
from automatically becoming proof that the task happened.
The project uses explicit provenance categories.
VERIFIED_ONCHAIN
VERIFIED_TRANSACTION
VERIFIED_EVIDENCE
DECLARED
UNAVAILABLE
Information directly verified against blockchain state.
A transaction reference was observed and validated on the expected chain.
A structured evidence payload passed validation.
Information supplied by agent metadata or configuration but not independently verified.
The application cannot currently prove the information.
The application does not silently upgrade:
DECLARED → VERIFIED
or:
UNAVAILABLE → VERIFIED
The project includes a dedicated read-only evidence validation path for Health Factor Monitoring.
The evidence model can capture:
- Monitored address
- Protocol
- Observed health factor
- Configured threshold
- Observation timestamp
- Observation block
- Alert transaction hash
- Event/log evidence
- Alert payload
- Source chain provenance
Invalid or wrong-chain evidence is rejected.
If the underlying protocol-specific reader cannot produce genuine data, the fields remain:
UNAVAILABLE
This design is intentional and prevents false claims.
BNB AgentHub is zero-custody.
The browser wallet is responsible for signing.
The application uses an EIP-1193 provider.
Example flow:
AgentHub
│
│ eth_sendTransaction
▼
MetaMask
│
│ User approval
▼
BSC / GenLayer
The application does not handle:
- Seed phrases
- Private keys
- Keystore files
- Exported wallet credentials
No private-key environment variable is required.
MetaMask can be used for both blockchain sides.
BSC Testnet
Chain ID: 97
Used for:
- ERC-8183 jobs
- Budget
- Funding
- Submission
- Settlement
GenLayer Bradbury
Chain ID: 4221
Used for:
- AgentAdjudicator
- SLA evaluation
- Consensus
- Finalization
The application verifies the wallet account and chain immediately before signing.
Changing accounts or networks invalidates stale confirmation state.
The project follows several strict rules.
The marketplace never receives or stores private keys.
Transaction hashes are only displayed when returned by an actual wallet/provider operation.
Transaction hashes are never converted into fake ERC-8183 IDs.
Lifecycle state is read from the BNB commerce layer.
Missing evidence stays unavailable.
Unverified success rates, APY, latency, or historical performance are not presented as verified.
Users approve blockchain transactions in their own wallet.
Critical RPC/read-back failures cannot silently become successful verified states.
The UI intentionally distinguishes:
ERC-8183 Job ID
from:
Transaction Hash
and:
Local Correlation ID
Likewise, the application only displays authoritative states such as:
ESCROW_FUNDED
JOB_ACTIVE
SETTLED
when supported by actual on-chain read-back.
A simplified repository structure:
bnb-agenthub/
│
├── frontend/
│ ├── app/
│ │ ├── agents/
│ │ ├── jobs/
│ │ └── page.tsx
│ │
│ ├── components/
│ │ ├── agents/
│ │ ├── hiring/
│ │ ├── genlayer/
│ │ └── layout/
│ │
│ ├── lib/
│ │ ├── bsc/
│ │ ├── erc8183/
│ │ ├── genlayer/
│ │ └── wallet/
│ │
│ └── tests/
│
├── contracts/
├── tests/
│ └── direct/
│
├── docs/
│ └── GENLAYER_INTEGRATION.md
│
├── package.json
└── README.md
The exact tree may change as implementation continues.
AgentHub does not need to deploy its own replacement ERC-8183 commerce contract.
It integrates with the official BNB deployment stack:
Official BNB AgenticCommerce
+
Official EvaluatorRouter
+
Official OptimisticPolicy
+
Official BNB Agent SDK
+
BNB AgentHub frontend
The GenLayer side separately uses the finalized deployed AgentAdjudicatorV2.
This separation avoids claiming ownership of protocol contracts that the project does not own.
Example configuration:
8004SCAN_API_BASE_URL=
8004SCAN_API_KEY=
BSC_MAINNET_RPC_URL=
BSC_TESTNET_RPC_URL=
NEXT_PUBLIC_DEFAULT_CHAIN_ID=
NEXT_PUBLIC_GENLAYER_CONTRACT_ADDRESS=
NEXT_PUBLIC_GENLAYER_RPC_URL=
NEXT_PUBLIC_GENLAYER_EXPLORER_URL=
NEXT_PUBLIC_BSC_EVIDENCE_BRIDGE_URL=
NEXT_PUBLIC_GENLAYER_V2_ADDRESS=Do not add private keys to environment variables.
Browser signing should remain wallet-controlled.
Recommended:
- Node.js 20+
- npm
- Git
- MetaMask or compatible EIP-1193 wallet
- Python 3.11+ for GenLayer direct tests
cd frontend
npm installnpm run devOpen:
http://localhost:3000
Run:
npm run typecheck
npm test
npm run lint
npm run buildGenLayer direct tests:
pytest tests/direct/test_agent_adjudicator.py -vLatest development verification recorded for this project:
- Frontend tests: 149 passing
- TypeScript typecheck: passing
- ESLint: passing
- Next.js production build: passing
- GenLayer direct tests: 4 passing
These results verify the software and integration logic.
They do not by themselves prove that a live BSC job has been funded.
For a controlled live test:
Use MetaMask through the global Connect Wallet control.
Chain ID: 97
The account needs BSC Testnet tBNB for transaction fees.
Current SDK deployment:
0xc70B8741B8B07A6d61E54fd4B20f22Fa648E5565
The application should confirm the runtime token address and metadata before signing.
Confirm:
- Wallet account
- Chain ID
- Commerce contract
- EvaluatorRouter
- Payment token
- Provider
- Budget
- Deadline
- Agent availability
Each requested transaction must be reviewed and approved in MetaMask.
After each write:
transaction receipt
↓
on-chain read-back
↓
verified state
After a genuine BSC task has produced real evidence:
- Switch MetaMask to GenLayer Bradbury.
- Confirm Chain ID
4221. - Ensure sufficient GEN for the transaction.
- Open the Independent GenLayer Evaluation panel.
- Review the evidence.
- Confirm the destination contract.
- Sign the adjudication request.
- Record the real GenLayer transaction ID.
- Wait for consensus.
- Wait for finalization.
- Display the final verdict.
BSC transaction hashes and GenLayer transaction IDs remain separate.
The project should not be called live verified merely because:
- The frontend builds.
- The wallet connects.
- Unit tests pass.
- A mock provider returns a hash.
- Calldata is encoded.
- A local state machine reaches a funded state.
A genuine BSC live verification requires:
- A real BSC Testnet transaction.
- Official AgenticCommerce interaction.
- A real canonical ERC-8183 Job ID.
- On-chain read-back of that Job ID.
- Verified job state.
- Real escrow funding if funding is claimed.
- Real task execution/evidence if submission is claimed.
A genuine GenLayer verification requires:
- A real GenLayer transaction.
- The AgentAdjudicator contract.
- Real transaction ID.
- Consensus/finalization.
- Returned adjudication result.
| Capability | Status |
|---|---|
| Agent marketplace | ✅ |
| Agent discovery | ✅ |
| Four mandatory categories | ✅ |
| Official BNB Agent SDK | ✅ |
| Non-custodial browser wallet | ✅ |
| BSC Testnet configuration | ✅ |
| Canonical ERC-8183 Job ID handling | ✅ |
| On-chain lifecycle read-back | ✅ |
| GenLayer AgentAdjudicator integration | ✅ |
| Evidence provenance | ✅ |
| Health-factor evidence validation | ✅ |
| Automated frontend tests | ✅ |
| GenLayer direct tests | ✅ |
| Live BSC job | ⏳ Controlled manual verification |
| Live escrow funding | ⏳ Controlled manual verification |
| Live provider submission | ⏳ Controlled manual verification |
| Live GenLayer adjudication | ⏳ Controlled manual verification |
| Vercel deployment | ⏳ Add final URL |
Before final submission:
- Deploy the application to Vercel.
- Add the Vercel URL at the top of this README.
- Add GitHub repository URL.
- Add demo video.
- Confirm marketplace discovery.
- Demonstrate all four categories.
- Demonstrate agent profile and hiring configuration.
- Demonstrate MetaMask connection.
- Demonstrate BSC Testnet preflight.
- Demonstrate official BNB Agent SDK usage.
- If performing a live demo, create a genuine testnet ERC-8183 job.
- Record canonical Job ID.
- Record transaction hashes.
- Demonstrate on-chain job read-back.
- Explain non-custodial wallet architecture.
- Explain how BNB AgenticCommerce handles the commerce lifecycle.
Before submitting for GenLayer assessment:
- Deploy the frontend.
- Add production URL.
- Keep AgentAdjudicator address documented.
- Do not unnecessarily redeploy AgentAdjudicator.
- Demonstrate the Evidence Bridge.
- Demonstrate requirements/evidence separation.
- Demonstrate provenance handling.
- Demonstrate an actual GenLayer evaluation.
- Record the GenLayer transaction ID when performing a live evaluation.
- Show the final consensus result.
- Explain why GenLayer is central to the workflow.
- Explain the separation between BNB EvaluatorRouter and GenLayer.
- Include automated test results.
- Include architecture documentation.
- Include screenshots/video.
A concise demo can follow this sequence:
Show:
- BNB AgentHub
- Wallet button
- BNB Chain identity
- GenLayer identity
- Four categories
- Agent discovery
Show:
- Agent identity
- Category
- Availability
- Capabilities
- Hiring requirements
Click:
Hire Agent
Show:
- Parameters
- Budget
- Deadline
- Provider
- EvaluatorRouter
- Payment token
- Wallet/network preflight
Connect MetaMask.
Switch to BSC Testnet.
Review and approve the required transactions.
Show:
- Transaction hash
- Canonical ERC-8183 Job ID
- On-chain job state
Show the task result and evidence.
Emphasize:
Evidence is not automatically trusted merely because an agent claims completion.
Switch to GenLayer Bradbury.
Open:
Independent GenLayer Evaluation
Show:
- SLA
- Evidence
- Provenance
- GenLayer transaction
- Consensus
- Final verdict
BNB handles the agent job. GenLayer independently evaluates whether the evidence supports the claimed result.
The marketplace infrastructure can create and track jobs, but an actual provider/agent must perform the task and submit a genuine deliverable.
Some evidence requires protocol-specific blockchain readers.
Where such a reader is not available, the application reports the evidence as UNAVAILABLE.
A live BSC Testnet test requires:
- tBNB for gas
- Required payment-token balance
A live GenLayer evaluation requires GEN for the required transaction.
The final Vercel URL is intentionally left as a placeholder.
The application is built around five principles:
On-chain state is preferred over local assumptions.
Users can distinguish declared information from verified information.
Users control their wallet.
GenLayer evaluates evidence independently from the BNB commerce layer.
When important information cannot be verified, the application says so.
In short:
Declared ≠ Verified
Transaction Hash ≠ Job ID
Local State ≠ On-chain State
Agent Claim ≠ Evidence
Successful Transaction ≠ Successful Task
Evidence → Consensus → Verdict
Potential extensions include:
- Protocol-specific evidence adapters for all four categories.
- Automated provider execution adapters.
- Verified agent reputation.
- Historical verified performance.
- SLA dispute dashboards.
- Richer ERC-8004 identity verification.
- Additional GenLayer adjudication policies.
- Notifications for task deadlines.
- Production indexing for large job histories.
- More autonomous agent categories.
- Cross-agent comparison using independently verified outcomes.
https://github.com/bnb-chain/bnbagent-sdk
https://github.com/bnb-chain/apex-contracts
https://docs.bnbchain.org/developer-kit/bnbagent-sdk/networks/
https://eips.ethereum.org/EIPS/eip-1193
Built with:
- BNB Chain
- BNB Agent Studio / BNB Agent SDK
- BNB AgenticCommerce / APEX
- ERC-8183 concepts
- ERC-8004 agent identity ecosystem
- GenLayer
- GenLayer Intelligent Contracts
- MetaMask / EIP-1193
- 8004scan ecosystem data where configured
┌──────────────────────┐
│ USER │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ BNB AgentHub │
│ Marketplace │
└──────────┬───────────┘
│
Browser Wallet
│
┌─────────────┴─────────────┐
▼ ▼
┌──────────────┐ ┌───────────────┐
│ BNB Testnet │ │ GenLayer │
│ Chain 97 │ │ Bradbury 4221 │
└──────┬───────┘ └───────┬───────┘
│ │
▼ ▼
┌──────────────────┐ ┌────────────────────┐
│ AgenticCommerce │ │ AgentAdjudicator │
│ ERC-8183 / APEX │ │ Intelligent │
└────────┬─────────┘ │ Contract │
│ └─────────┬──────────┘
▼ │
Real Agent Job │
│ │
▼ ▼
Real Evidence ──────────────► GenLayer
│
▼
Consensus
│
▼
Independent Verdict
BNB AgentHub is a non-custodial marketplace where users hire autonomous DeFi agents through BNB's ERC-8183 commerce stack, then use GenLayer to independently adjudicate whether the agent's real evidence satisfies its promised SLA.
After deploying to Vercel, replace the placeholder at the top with:
Live App: https://YOUR-APP.vercel.app
Also add the final GitHub repository and demo-video links before submission.