@layerzerolabs/framework-solana-anchor-trait 0.2.100 → 0.2.102
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +30 -0
- package/package.json +5 -5
package/README.md
CHANGED
|
@@ -66,6 +66,36 @@ For required instructions, no default exists. The implementor must provide a han
|
|
|
66
66
|
|
|
67
67
|
Unannotated functions whose identifiers collide with managed instruction names are rejected at compile time. Such functions must be annotated with the override attribute (e.g. `#[oapp_instruction]`) to disambiguate intent.
|
|
68
68
|
|
|
69
|
+
## When to Define a Trait
|
|
70
|
+
|
|
71
|
+
A trait built on `anchor-trait` exists to serve one or both of two motivations. Use this section to decide whether your work warrants a new trait, or whether a lighter mechanism (program-local handlers, plain macros, a direct dependency) would suffice.
|
|
72
|
+
|
|
73
|
+
### Motivation 1: Shared Default Behavior with Override
|
|
74
|
+
|
|
75
|
+
> Analogous to Solidity's `abstract contract` — a partial implementation that downstream contracts inherit and selectively override.
|
|
76
|
+
|
|
77
|
+
Multiple programs are expected to implement the same set of instructions, and the trait author wants to ship a default implementation that each program can adopt as-is or override per-instruction. Without a trait, every program copies the same handlers; as the standard evolves, the copies drift silently because no central authority enforces signature consistency.
|
|
78
|
+
|
|
79
|
+
A trait satisfies this motivation by exposing default implementations (provided instructions) that implementors consume through the override resolution algorithm. The framework enforces at compile time that every implementor either accepts the default or supplies a handler whose signature matches the trait declaration — drift can no longer happen silently.
|
|
80
|
+
|
|
81
|
+
### Motivation 2: Compile-Time-Enforced Surface for External Callers
|
|
82
|
+
|
|
83
|
+
> Analogous to Solidity's `interface` — a signature-only contract that every implementation must conform to.
|
|
84
|
+
|
|
85
|
+
External callers — off-chain clients such as generic SDKs, wallets, indexers, and explorers, or other on-chain programs invoking via CPI — require a stable and predictable surface across all implementations of the standard. Every implementor must honour the same instruction signatures, account layouts, and PDA seed conventions so that one generic caller can target any deployment.
|
|
86
|
+
|
|
87
|
+
A trait satisfies this motivation by publishing a canonical instruction surface — parameter types, return types, account layouts, view-ness, and seed constants — that the framework enforces at compile time. A non-conforming implementor produces a build-time error rather than a runtime CPI failure or a silently-broken SDK call.
|
|
88
|
+
|
|
89
|
+
### Three Combination Scenarios
|
|
90
|
+
|
|
91
|
+
| Reusability | Composability | Recommendation |
|
|
92
|
+
| ----------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
93
|
+
| Yes | Yes | Define a trait. Default implementations and the published interface come from a single source of truth. Most traits in this codebase fall here. |
|
|
94
|
+
| Yes | No | Define a trait. Provided instructions and override resolution still apply; the published interface is consumed by implementors themselves rather than by external callers. |
|
|
95
|
+
| No | Yes | Define a trait with all instructions marked required (`default_impl: None`). The value lies in compile-time enforcement of signatures and account layouts; no default behaviour needs to be shared. |
|
|
96
|
+
|
|
97
|
+
If neither motivation applies, do not define a trait. There is no reuse to factor out and no interface to standardise; use program-local code or macros directly.
|
|
98
|
+
|
|
69
99
|
## Defining a Trait
|
|
70
100
|
|
|
71
101
|
The following steps describe how to create a new instruction trait using the framework.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@layerzerolabs/framework-solana-anchor-trait",
|
|
3
|
-
"version": "0.2.
|
|
3
|
+
"version": "0.2.102",
|
|
4
4
|
"private": false,
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|
|
@@ -14,10 +14,10 @@
|
|
|
14
14
|
"rustfmt.toml"
|
|
15
15
|
],
|
|
16
16
|
"devDependencies": {
|
|
17
|
-
"@layerzerolabs/build-utils-solana": "0.2.
|
|
18
|
-
"@layerzerolabs/typescript-configuration": "0.2.
|
|
19
|
-
"@layerzerolabs/tsup-configuration": "0.2.
|
|
20
|
-
"@layerzerolabs/vm-tooling-solana": "0.2.
|
|
17
|
+
"@layerzerolabs/build-utils-solana": "0.2.102",
|
|
18
|
+
"@layerzerolabs/typescript-configuration": "0.2.102",
|
|
19
|
+
"@layerzerolabs/tsup-configuration": "0.2.102",
|
|
20
|
+
"@layerzerolabs/vm-tooling-solana": "0.2.102"
|
|
21
21
|
},
|
|
22
22
|
"publishConfig": {
|
|
23
23
|
"access": "restricted",
|