Axeline Bridge research programme.
Programme paused. Paused while remediation of the research assessment is reviewed. Submissions about the new code are welcome after the programme reopens.
Programme overview
- Protocol category
- Interoperability
- Ecosystems in scope
- OptimismAvalanche
- In-scope components
- 6 (5 contracts, 1 other)
- Languages
- Solidity
Focus areas
Where research is most wanted.
- 01
Message replay and nonce handling
- 02
Verifier configuration per application
- 03
Executor retries and ordering
- 04
Attester key rotation
Scope
In scope.
| Component | Type | Identifier | Notes |
|---|---|---|---|
| EndpointOptimism | Smart contracts | 0xc6194cbc9f86702426a8ae052f6e5a825b7fd0e1 | Sends and receives messages with nonces |
| VerifierRegistryOptimism | Smart contracts | 0x0553d0e89ebfd60b2ba445c7b9456c3f95fd451b | Per-application verifier configuration |
| AttestationVerifierOptimism | Smart contracts | 0xb59e9e47f821f6484524de85c76be759aeda46c1 | Threshold signatures from attesters |
| ExecutorOptimism | Smart contracts | 0xbd2834cca9f7a0e9f7cf9b9cc3700564dede5177 | Delivers verified messages and retries failures |
| EndpointAvalanche | Smart contracts | 0xfaef84c74a6b93da9ce0524d6f3106bcd94900ac | Endpoint deployment on Avalanche C-Chain |
| Executor service | Infrastructure | executor.axeline-bridge.example | Off-chain delivery service (test deployment) |
Out of scope
- Underlying chains and their bridges
- Applications built on Axeline
- Issues already reported in the research assessment
- Findings that require compromised keys or privileged access the attacker could not obtain
Severity
How findings in this programme are rated.
- Critical
- Delivering a message that was never sent
- Replaying a delivered message
- High
- Changing an application’s verifier without its authorisation
- Medium
- Permanently blocking message delivery for an application
- Low
- Incorrect events that mislead monitoring
Rules of engagement
Research within these rules.
- 01Test only against a local fork or the programme’s test deployment. Never interact with production systems or other users’ funds.
- 02Do not run denial-of-service, spam or social-engineering tests, and do not access data that is not yours.
- 03Report privately through the submission form. Keep details confidential until a disclosure date is agreed.
- 04One finding per submission, with a reproducible proof of concept where code is involved.
- 05Issues already listed in the protocol’s research assessment as acknowledged or open are not eligible for recognition.
These rules, together with the disclosure policy, define what the programme authorises. Testing outside them is not authorised.
Recognition
Validated findings receive recognition. This programme offers no monetary reward.
Acknowledgement in the report
Validated findings are credited in the protocol’s research assessment or advisory, by name or handle, with your consent.
Recognition ledger
Each validated finding becomes a ledger entry recording programme, vulnerability class, severity and validation date. Entries are published only with the researcher’s consent.
Researcher standing
Standing reflects validated findings over time: Contributor after the first, Recognised after three, Distinguished after a validated critical or high finding with a published write-up.
Research collaboration
Researchers with standing are invited to closed challenge rounds and to co-author research on the vulnerability classes they reported.
This programme is not accepting submissions yet.
Paused while remediation of the research assessment is reviewed. Submissions about the new code are welcome after the programme reopens.