Suppose a judging room has 180 submissions, 40 demo links, and one afternoon. Every team says its wallet flow works. Several links are dead, some demos use the wrong test network, and the strongest integration is hidden in a repository nobody has time to understand.
A crypto hackathon platform should require a source difference, test output, browser run, and versioned artifact for each technical result. It should give builders a versioned starter repository and environment contract, give sponsors code-checkable behavior, and give judges a standard submission packet.
The judges still make the prize decision. Standardized reruns and the submission packet let judges inspect behavior before weighing the presentation.
Blueprint Agent is Tangle’s browser-based coding workspace. Its public documentation describes a workflow in which a developer gives an agent a brief, edits and runs a real project, reviews the result, and takes it to a repository or deployment. That makes it a useful build surface for a sponsor who wants a hackathon challenge to end in running software. An SDK, or software development kit, is the package and documentation a sponsor expects teams to use when integrating with its product. An API, or application programming interface, is the documented boundary through which one program requests data or actions from another. For how repeated quest failures expose onboarding friction, read Developer Onboarding Platform With Code-Verified Quests. For the task and verifier design itself, read Developer Quest Platform With Code Verification.
Start with the submission a judge must inspect
A submission should answer five questions before a judge opens the code.
- What did the team attempt?
- Which files and dependencies changed?
- Which product behavior ran successfully?
- Where can the result be inspected?
- What remains broken or untested?
The submission packet should make those answers visible.
| Artifact | What a judge can learn | Boundary |
|---|---|---|
| Brief and scope | The intended product behavior | It does not prove implementation |
| Source diff | What the team changed | It does not prove the code ran |
| Build and test output | Whether named checks passed | It covers only the checks that exist |
| Wallet or browser run | Whether a user-facing path reached a state | It may miss backend or security failures |
| Testnet transaction or service result | Whether the integration reached the target network | It does not make a production-network deployment safe |
| Preview or artifact | A judge can inspect the result | The target may expire or drift |
| Trace | How the work and failures unfolded | It is evidence of process, not correctness |
The packet should record skipped checks as skipped. Silence around a missing browser run is more misleading than a visible failure.
Give every team the same starting conditions
A team may need a package registry, a wallet provider, a remote procedure call (RPC) endpoint, a testnet account on a network reserved for testing, test tokens from a faucet, a contract address, an indexer that makes blockchain data searchable, and a browser. Those boundaries can fail through version drift, a wrong network, missing funds, malformed provider responses, or an upstream outage. An RPC endpoint is a network address that accepts remote procedure calls, such as requests to a blockchain node.
Sponsors should publish a starter project and a short environment contract. The contract should state the expected Node.js or Rust version, package versions, network identifier, test accounts, faucet limits, contract addresses, and cleanup rules.
GitHub Codespaces is a useful public reference for the idea of a cloud development environment configured from repository files. An agent workspace follows the same principle while adding an assistant, task instructions, and evidence collection.
An agent profile is the saved configuration for an agent run, including its model, instructions, tools, permissions, and budget. A runtime is the environment that starts the agent and provides its files, processes, network policy, and resource limits. An evaluation is a repeatable check against an expected result. The starting flow can look like this.
sponsor publishes starter project and network contract
-> builder opens a bounded workspace
-> agent profile supplies model, tools, and budget
-> builder implements the required behavior
-> code and browser checks run
-> submission packet records results and known failuresThe profile and runtime should be versioned for the event so a team does not receive an invisible capability advantage from a different environment.
Run the sponsor path before opening submissions
The sponsor should complete its own challenge from a clean workspace. That rehearsal should include the starter project, the documentation links, the test account, the browser flow, the verifier, the export packet, and the judge view.
| Preflight | Failure to force | What to fix before launch |
|---|---|---|
| Fresh install | Empty cache and a clean lockfile | Missing version or package instructions |
| Wrong network | Deliberately select another chain | Network warning and recovery step |
| Wallet rejection | Deny the connection or signature | Consent copy and retry behavior |
| Missing funds | Use a test account with no balance | Faucet limits and reset instructions |
| Failed contract call | Submit an invalid fixture | Error decoding and support guidance |
| Expired preview | Open the result after its lifetime | Artifact expiry and replacement policy |
| Reviewer handoff | Give the packet to a new judge | Missing context or unclear scoring rule |
Run the preflight with the same account limits and network destinations that builders receive. If the sponsor uses a privileged account to demonstrate the path, the demo can pass while every participant fails.
Separate infrastructure health from builder behavior. If the RPC endpoint or indexer is unavailable, mark the dependency outage and preserve the submission for rerun. Do not turn an infrastructure failure into a technical score without an explicit rule. That rule should be written before the event, when no particular team is waiting on the outcome. The judge packet should also preserve the test conditions, because two submissions can appear different when one ran with a warm cache and the other started from an empty workspace. Comparable judging depends on comparable inputs, versions, network state, and time limits.
Write a challenge as a behavior
“Build something cool with our protocol” invites a pitch. “Use the SDK to request a quote, submit the accepted transaction on the test network, and show the settled result” gives a builder a technical target.
A sponsor can split that target into quests. A quest is a small task with a stated outcome. A code-verified quest is complete only when its named check succeeds. A verifier is the check or service that observes the required behavior and records whether it passed, failed, or was skipped.
For a wallet-heavy challenge, the checks might be:
| Quest | Check |
|---|---|
| Read network state | The app requests eth_chainId and displays the expected network |
| Connect wallet | The provider reports an account after an explicit user action |
| Submit request | The app sends the documented method with the required parameters |
| Handle rejection | A rejected wallet request produces an actionable state |
| Confirm result | The user interface shows the returned transaction or job identifier |
| Recover | Reloading or a failed request leaves the app in a usable state |
The provider behavior in the wallet checks should follow the public Ethereum Improvement Proposal 1193 (EIP-1193) provider API. Browser automation can use Playwright, which documents browser tests, assertions, isolation, and reports for local or continuous integration (CI) execution.
The following is a deliberately small illustrative check. It uses a standard provider boundary and leaves the event-specific contract method for the sponsor to define.
type Provider = {
request(args: { method: string; params?: unknown[] }): Promise<unknown>
}
async function checkNetwork(provider: Provider, expectedChainId: string) {
const chainId = await provider.request({ method: 'eth_chainId' })
if (chainId !== expectedChainId) {
throw new Error(`expected ${expectedChainId}, received ${String(chainId)}`)
}
return { name: 'expected-network', status: 'passed' as const }
}The event’s actual verifier should add the product-specific state transition. A chain identifier alone proves that the app asked a wallet provider about its network. It does not prove that the team integrated the sponsor’s SDK or that a transaction succeeded.
Make judging comparable without flattening the work
Standardize required behavior and evidence, not frameworks or visual design.
| Criterion | Evidence | Weighting question |
|---|---|---|
| Required integration | Product-specific check and source diff | Did the submission use the sponsor surface? |
| User path | Browser or recorded runtime result | Can a user reach the promised behavior? |
| Failure handling | Rejected request, wrong network, or missing funds | Does the app explain a normal failure? |
| Code quality | Tests, structure, and reviewer inspection | Can someone extend the result? |
| Deployment | Reproducible preview or testnet result | Can a judge inspect the same artifact? |
| Originality | Human review of the resulting idea | Does the work create a worthwhile use case? |
The platform should never decide the creative criterion from raw agent activity. Tool-call count, prompt length, and model choice are process details. They can help explain a failure, while the product result and human review should carry the award decision.
Keep an evidence trace, with privacy rules
A trace is the ordered record of a run, including prompts, tool calls, file changes, command output, evaluations, and artifacts. For a hackathon, the trace can save a judge from reconstructing every debugging step. It can also help the sponsor improve the challenge after the event.
The trace should identify the evaluation version and outcome. The submission should show whether a check passed, failed, or was skipped.
Use a redacted trace for judging. Wallet keys, private API tokens, personal information, and unpublished business logic do not belong in a public packet. Use disposable test accounts and state the account reset rules before the event. If an agent profile permits external tool connections, list those connections and the data they can receive.
The partner can use failed traces as documentation data. If most teams fail at the same RPC setting, the starter project needs a fix. If the agent repeatedly invents a method name, the docs need a runnable example. If a browser check fails after a provider update, the verifier needs a maintenance owner.
Tangle terms in a hackathon workflow
In Tangle’s protocol, a Blueprint is a reusable definition of a service. It describes jobs, inputs, outputs, artifacts, triggers, and optional protocol rules. A Service is a live instance created from that definition. A Job is one callable unit of work inside that Service. An operator is the person or team that supplies infrastructure and runs the service. The public Blueprint introduction describes those roles and their boundaries.
Blueprint Agent is a separate product surface for building with an AI coding assistant. The two can meet when a hackathon challenge asks teams to build a client for a Tangle service or to package a service as a Blueprint. The distinction keeps a builder from confusing the workbench with the protocol service being built.
In the protocol runtime, a job router maps a job identifier to its handler. If the challenge is about a Blueprint job, the verifier should call the job through the documented entrypoint so it checks the same route an eventual user will use.
For paid agent or API challenges, x402 uses Hypertext Transfer Protocol (HTTP) 402 Payment Required to communicate payment requirements and lets a client return a payment payload before retrying the request.
The x402 client and server guide describes those roles.
Payment acceptance should be one quest assertion.
The service output should be another assertion.
If the sponsor requires confidential execution, an attestation is a signed statement about the code or environment observed by trusted hardware or its verifier. It can support a claim about the execution boundary. It does not prove that the submission handles authentication, authorization, malformed input, or operational failures. It does not prove the submission’s idea or output quality. The Tangle execution confidentiality guide documents the policy boundary.
Judge the unhappy path before the stage demo
Run wrong-network, rejection, missing-funds, malformed-response, and expiry cases before launch.
Ask a fresh team to use the wrong network. Deny a wallet request. Let a test account run out of funds. Return a malformed response from a mock or fixture. Stop the preview and see whether the judge packet says why.
The platform should preserve each failure as a named outcome.
| Failure | Useful evidence | Sponsor action |
|---|---|---|
| Wrong network | Chain identifier and user-facing error | Improve network setup and reset steps |
| Wallet rejection | Provider error code and recovery state | Document consent and retry behavior |
| Missing funds | Test account balance and faucet response | Publish funding limits and a reset route |
| Contract revert | Request parameters and decoded error | Add an example for valid inputs |
| Expired preview | Target status and artifact version | Extend or replace the preview |
| Flaky verifier | Attempt history and environment | Stabilize the check before scoring it |
An external outage can wrongly remove an otherwise valid entry from consideration. If the check depends on a third-party RPC or indexer, record that dependency and offer a rerun path. Keep a reviewer override for cases where the evidence and the automated result disagree.
What the checks leave for human judges
A passing check proves that a defined behavior passed under defined conditions. It does not prove that the code handles production authentication, authorization, malformed input, load, or operational failures. It does not make a testnet deployment safe to promote to mainnet (the production network). It does not prove that generated code was understood by every team member.
Sponsors should state those limits in the rules. Use code evidence to establish technical eligibility, then use human review for architecture, product judgment, originality, and risk.
Open the event only when judges can rerun it
Choose a crypto hackathon platform with code verification when the sponsor wants integrations that can be run and inspected after the event. Keep a form and demo video for lightweight community challenges where implementation evidence is outside the scope. For protocol or SDK challenges, publish the starter environment, define the behavior, test the unhappy path, and give judges a packet that names every check.
The event is ready when a fresh builder can reach the first product-specific check and a fresh judge can understand the result without opening ten unrelated tabs.
What is a crypto hackathon platform?
It is software and workflow for giving crypto builders a challenge, environment, support path, submission format, and judging process.
Why use code verification?
Code verification shows whether a named integration builds, runs, or reaches a required state under documented conditions.
Does a wallet connection prove a crypto integration?
No. A wallet connection proves that a provider exposed an account or accepted a request. The sponsor still needs a check for its SDK, contract, API, or user-facing behavior.
How does Blueprint Agent help a hackathon?
It gives builders an in-browser coding workspace where an agent can edit and run a real project while the builder reviews the result. The sponsor still owns the challenge rules and verifiers.
Should judges see the full agent trace?
Usually no. Give judges a redacted, relevant trace and the source, checks, runtime result, and known failures needed for the decision.