XInclude template composition, including web3:// contract fragments
Version 2.3.0 of representable-contract-state adds XInclude-based template composition for HTTP(S), IPFS, and ERC-4804/ERC-6860 web3:// / w3:// resources.
On Ethereum, deployed contract runtime bytecode is constrained to about 24 KB (EIP-170). At first glance, this may look like a limitation for representable-contract-state (ERC-8100), because the approach relies on an XML template exposed by the contract, often implemented as a string literal.
In practice, the 24 KB limit is rarely a problem for program logic, since code can be factored into multiple deployed components. For document-style representations, however, a single monolithic XML template can become large.
The latest ERC-8100 update introduces a profile for external template includes based on W3C XInclude (XInclude 1.0). XML templates can now be split into smaller fragments and, where desired, hosted externally or served by another contract. To preserve immutability guarantees, each included resource is fetched off-chain and validated against the keccak256 digest declared in evmstate:integrity before it is merged into the expanded template.
The current reference implementation of the ERC-8100 renderer supports:
http:// and https:// resources,
ipfs:// resources through a configured gateway, and
address-based, same-chain ERC-4804/ERC-6860 web3:// and w3:// resources.
This makes it possible to keep the main ERC-8100 template small while still producing a full canonical XML representation. A contract can expose the root template, and larger reusable XML fragments can be fetched from HTTP(S), IPFS, or another contract.
IPFS, the InterPlanetary File System, is a content-addressed peer-to-peer storage network: content is referenced by a CID (content identifier) derived from the bytes of the resource. If the content changes, the CID changes as well. This makes IPFS a natural distribution mechanism for immutable template fragments. In ERC-8100, the trust boundary remains explicit because renderers still verify the fetched bytes against the evmstate:integrity value; the transport, gateway, or hosting provider does not need to be trusted. Availability, as usual, depends on pinning and hosting policies.
The mechanism is recursive: an included XML fragment may itself contain further xi:include elements. Renderers resolve the includes recursively, with loop detection, before evaluating any evmstate bindings.
The following example shows a template that has been split into two XML fragments fetched from another contract. On a local Anvil chain with chain ID 31337, the URL
web3://0x5fbdb2315678afecb367f032d93f642f64180aa3:31337/xml/0
is resolved as an eth_call to xml(uint256) with argument 0 on the target contract.
<?xml version="1.0" encoding="UTF-8"?>
<demo xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:evmstate="urn:evm:state:1.0">
<xi:include href="web3://0x5fbdb2315678afecb367f032d93f642f64180aa3:31337/xml/0" parse="xml" evmstate:integrity="keccak256-0x5dccfb297e88f25275d613b21fe9b77f395bf5f05e0e2155a688d412243f6958"/>
<xi:include href="web3://0x5fbdb2315678afecb367f032d93f642f64180aa3:31337/xml/1" parse="xml" evmstate:integrity="keccak256-0xee6ec1deeeb33b477b7dcd8e3dcf88b31d027af778697266787bc5bed4057e0f"/>
</demo>
The parse="xml" attribute means that the included resource is interpreted as XML. This allows nested xi:include elements and evmstate directives inside the included fragment to be processed as part of the expanded template.
The same template-composition mechanism can also be used with ordinary web resources, for example with XML fragments stored in a GitLab repository or on IPFS. The following example shows a small root template that includes an external bonddata.xml fragment:
/// @inheritdoc IXMLRepresentableState
function stateXmlTemplate() external pure override returns (string memory) {
// The root template is small and includes an externally hosted BDT fragment.
return
"<Contract xmlns='urn:example:contract'"
" xmlns:evmstate='urn:evm:state:1.0'"
" xmlns:xi='http://www.w3.org/2001/XInclude'"
" evmstate:chain-id=''"
" evmstate:contract-address=''"
" evmstate:block-number=''>"
"<xi:include"
" href='https://gitlab.com/finmath/representable-contract-state/-/raw/2d15bc6620960d968b6d1c4cf97db76169c89aa7/representable-contract-state-web/src/test/resources/xincludes/bdt/bonddata.xml'"
" evmstate:integrity='keccak256-0x3d753a9b2ada199123802385e81e40b8a5956f5a311f9b115e7a68b199b3c56f'/>"
"</Contract>";
}
Here, bonddata.xml may itself include several other XML fragments:
<?xml version="1.0" encoding="UTF-8"?>
<BondData xmlns="urn:icma:bdt:1.0"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:evmstate="urn:evm:state:1.0">
<xi:include href="https://gitlab.com/finmath/representable-contract-state/-/raw/2d15bc6620960d968b6d1c4cf97db76169c89aa7/representable-contract-state-web/src/test/resources/xincludes/bdt/security.xml" evmstate:integrity="keccak256-0x845ade82c201ba8f4b8caf7e8ef7ceeac36ea80661ad7ab591c289949efda135"/>
<xi:include href="https://gitlab.com/finmath/representable-contract-state/-/raw/2d15bc6620960d968b6d1c4cf97db76169c89aa7/representable-contract-state-web/src/test/resources/xincludes/bdt/issuer.xml" evmstate:integrity="keccak256-0x4ed783b3cee9aa0127290b5d26428011e57a12a0a23a17440a0ce4af8b35c85b"/>
<xi:include href="https://gitlab.com/finmath/representable-contract-state/-/raw/2d15bc6620960d968b6d1c4cf97db76169c89aa7/representable-contract-state-web/src/test/resources/xincludes/bdt/economic-terms.xml" evmstate:integrity="keccak256-0x04416b0376f86ba86c2e58c7752900baf83fdf3f9d91b864c89c1f1fc11891c9"/>
<xi:include href="https://gitlab.com/finmath/representable-contract-state/-/raw/2d15bc6620960d968b6d1c4cf97db76169c89aa7/representable-contract-state-web/src/test/resources/xincludes/bdt/governing-law.xml" evmstate:integrity="keccak256-0x1e3adb93b4b7de530130dd36342c9e0f09e42f2382e9c2a3589b6dc45943f1f0"/>
</BondData>
In this model, renderers first resolve all xi:include elements, verify the integrity of every fetched fragment, and then evaluate evmstate bindings against one fixed block snapshot.
The rendered output of the above bonddata.xml template, after resolving its four includes, is then of the following form:
<Contract xmlns="urn:example:contract" xmlns:evmstate="urn:evm:state:1.0" xmlns:xi="http://www.w3.org/2001/XInclude" evmstate:block-number="8" evmstate:chain-id="31337" evmstate:contract-address="0x1275D096B9DBf2347bD2a131Fb6BDaB0B4882487" evmstate:renderer-id="net.finmath.smartcontracts.representablestate.xml.EvmXmlRenderer" evmstate:renderer-url="http://finmath.gitlab.io/representable-contract-state" evmstate:renderer-version="2.3.0">
<BondData xmlns="urn:icma:bdt:1.0">
<Security>
<Identifier>
<ISIN>XS1234567890</ISIN>
</Identifier>
<Name>Example 2.50% 2030</Name>
<Status>Issued</Status>
</Security>
<Issuer>
<Name>Example Issuer SA</Name>
<LEI>5493001KJTIIGC8Y1R12</LEI>
</Issuer>
<EconomicTerms>
<Notional>
<Amount>500000000.00</Amount>
<Currency>EUR</Currency>
</Notional>
<IssueDate>
<UnadjustedDate>2025-01-15</UnadjustedDate>
</IssueDate>
<MaturityDate>
<UnadjustedDate>2030-01-17</UnadjustedDate>
</MaturityDate>
<Coupon>
<Type>Fixed</Type>
<Rate>2.5000</Rate>
<DayCountFraction>30E/360</DayCountFraction>
<Frequency>
<PeriodMultiplier>12</PeriodMultiplier>
<Period>M</Period>
</Frequency>
</Coupon>
</EconomicTerms>
<GoverningLaw>DE</GoverningLaw>
</BondData>
</Contract>
For a more detailed description of the concept, see the ERC-8100 concept page http://finmath.gitlab.io/representable-contract-state/concept .
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | ERC-8335: Account-Level Transfer With Authorization | 0 | 7 | 10-07-2026 |
| 2 | ERC-8240: Trust Infrastructure for Agents and Assets | 0 | 5 | 08-07-2026 |
| 3 | EIP-8146: Block Access List Sidecars | 0 | 6 | 10-07-2026 |
| 4 | ERC-8313: Protocol Interaction Manifest | 0 | 7 | 08-07-2026 |
| 5 | EIP-7906: Transaction Assertions via State Diff Opcode | 0 | 3 | 08-07-2026 |
| 6 | EIPIP Meeting #128, July 08, 2026 | 0 | 7 | 08-07-2026 |
| 7 | EIP-7730: Proposal for a clear signing standard format for wallets | 0 | 7 | 08-07-2026 |
| 8 | Add ERC 8217: Agent NFT Identity Bindings | 7 | 8 | 08-07-2026 |
| 9 | Compose Whitepaper: A Composition Layer for On-Chain Applications | 0 | 5 | 08-07-2026 |